Hello, i spent all this week-end to understand why I did not see any data record on the device dashboard while the gateway shows activity on its log about 2 devices I just registered (one is cayenne LPP compliant and the other has a custom payload). Same issue with the same devices separately registered.
So i’m lost and a bit upset. CAn you help in solving this issue. Best regards
the gateway is home made development. The devices are based on Murata mudule based on STM32 and Semtech SX1276. I’m working for STM. All this worked before using Loriot + cayenne. any idea where the issue comes from. Br, JP
Does the dev addr shown in the gateway traffic match the device address of one of your nodes?
Are you using OTAA or ABP?
Where (which handler) is you gateway registered? (EU?) And where is the application registered?
Hello Kersing,
i’m using OTAA and the gate way is register via EU (ttn-router-eu)
The device adress seens at gateway traffic is the same at device dashboard
all seems ok but something wrong…any idea ? thanks
For OTAA, the frame counters are reset for each join, so that cannot be the issue. Is your node also using OTAA…? Please reset the node and show us the Join Request and Join Accept from TTN Console, in the application’s Data page and the gateway’s Traffic page.
If you don’t see the Join Accept, then please click the Join Request, and see if there’s any error in the “trace” part.
(My guess is that the node is using ABP even though you are using OTAA in TTN Console. Does the DevAddr in TTN Console change when you reset the node?)
Hmmm, that looks good, and proves that the keys in the node are okay too…
What LoRaWAN port are you using? You should not use port 0.
(It seems it’s port 0x63 or decimal 99, which should be fine. To be sure you can also paste a full LoRaWAN packet from the gateway’s Traffic page into an online decoder to see that.)
It seems your device is sending a DeviceTimeReq MAC Command, which is not supported yet. But I’d assume the payload would then still make it to the application.
Any error when you scroll down a bit further in the expanded uplink in TTN Console?
thanks. here is the decoder results.apparently my data are properly decoded.
I use port 99 (cayenne format for the payload).
let me know if you see something wrong.
The thing to note in that output is FCtrl, which tells you there’s 1 byte in FOpts. And that one byte in FOpts, 0x0D, is a DeviceTimeReq, which might be causing the display problems in TTN Console, like explained in the post I linked above.
Hello, i’m back and discover data now displayed in the device dashboard since 10:00AM !
did you do something ?
Then I just modified the lora stack to remove this unsupported time request as per your recommendations , and I can see the correct payload displayed. great and thank to you
Are you saying you suddenly saw the application data, before you made any changes, so before you even removed the DeviceTimeReq in the node? If so, did you see any difference after you removed DeviceTimeReq?
(Looking at the code of the TTN backend I don’t understand why it would not show, even with the DeviceTimeReq command. But that seemed to be the case… I did not change anything; I’m not part of the core team.)
I have a number of TTN applications where uplinks do NOT appear on the TTN web console. Nothing appears in application / data or application / devices / device / data. I know the uplinks are all working correctly because MQTT publishes the uplinks correctly - it’s just a no-show bug on the TTN web console.
If I change something trivial in the TTN web console application configuration, save, and then change it back and then save again then, sometimes, the uplinks all start to appear on the web console.
It may be that @luckystar13 has been experiencing the same situation.
I use mosquitto_sub and MQTT for commissioning / testing.
Yes I saw raw data in the device dashboard without doing any modification…then I remove the DeviceTimeReq on the Node side, and I saw good Cayenne LPP payload . Very strange. Same node was tested at Loriot without such problem. could it be from your side ? display seems very instable…Br, JP
.