Hi,
I had a couple of devices setup and working in the past. After a few months I went back to them, and it looks like they are not updating information. The strange thing is that if I go to https://console.thethingsnetwork.org/gateways/{name}/traffic I see downlink traffic coming from a specific device.
The counters are totally out of sync. You will probably need to restart the device to get it back in working order.
Then monitor if it keeps sending data to the application when the counter reaches 64k. I suspect it will not (device on TTN is probably set to 16 bit counters when the node is using 32 bits).
BTW, keep in mind TTN fair access policy allows for 30 seconds airtime for a node per day. You seem to be sending 100 packets in < 2 hours which will result in a lot more airtime.
To see/confirm that the device has exceeded the limits of a 16 bits uplink frame count (65,536), one can paste a Base-64 encoded payload from the gateway’s Traffic page into an online decoder, and then also specify the AppSKey and NwkSKey. Using those secrets, the decoder will show the MSB of the frame count (which is not in the packet itself, but needs to be determined by the server, for which a real LoRaWAN server then assumes the counters are not too far out of sync).
We are experiencing the same problem.
We have a Things Indoor Gateway. We set up this gateway in the things network console and it’s working, its status is connected and in the traffic page we see join and uplink trames.
We created an application and set up 7 devices with their deveui and AppKEY (OTAA ), but we are not able to see their status, for any of the 7 devices.
We have already used these devices with another gateway without thethingsnetwork platform and it’s worked well.
But with the Things Indoor Gateway and the Things network console even when we reset the devices (they send a join command after restart) their status are still never seen.
Do you have any idea to understand and fix this problem ?
For those 7 devices? So, the OTAA joins succeeded and the devices are transmitting data uplinks, with a 0x26/0x27 TTN DevAddr? (Just to make sure they did not join the previous network.)
What about their AppEUIs?
Any cross-region involved? Are you seeing data through some integration, or when using the MQTT API?
Not for the 7, for some devices I don’t see any traffic (join or uplink), for the devices appearing in the console their DevAddr are not prefixed with 0x26 or 0x27. See below the trafic.
Now I received data with a device, but I updated the device to set the AppEUI with the same AppEUI defined by TheThingsNetwork.
I’m little bit confused because I thought that the devEUI and appKey was enough. Does this mean we have to register all our devices in the TheThingsNetwork (we will deploy 300 devices), read the AppEUIs and set up each device with this AppEUI ?
Regarding the MQTT, for now we just want to test the reception of data. After that we want to send the data to AWS IOT (we already use that with Multitech gateway for MQTT broker)
If you are sure your’re seeing data from your devices (and not some other devices in your neighbourhood), then apparently they (re-)joined to the other network. If two networks know the same device, then both might receive the Join Request and might create a Join Accept, in which case it will be a roulette game as to which Join Accept is handled by the device, if any. So, make sure they’re no longer registered with the other network (at least not with the very same values for DevEUI, AppKey and AppEUI).
Indeed, you will need the DevEUI and AppKey (in the device’s settings) and the AppEUI (in the application’s settings; in V2 make sure to select the right AppEUI in the device’s settings, in V3 you will also be able to set this in the device directly). If the devices already have those assigned/programmed, then you can also copy these existing values from the device into TTN. For the AppEUI you can add one or more AppEUIs to an application, using either TTN Console or the command line ttnctl.
(Like written above: when not using a TTN-generated AppEUI then make sure the other network does not know the device with the very same values.)
I asked as sometimes TTN Console does not show data, while the other interfaces work just fine. Something to remember when troubleshooting. Also note that the MQTT API has an error topic, which (sometimes) can help during debugging. So even a command line MQTT client can be very helpful.
In TTN Console just go into Settings, and then EUIs, and click “add EUI”.
But you’re right, it seems ttnctl might not support that? I don’t have it installed on the machine I’m using right now; maybe its help shows more options?
Also note that the MQTT API has 