Hi I have a device Authentication OTTA , initially all worked fine I could receive and send data from and to the device. At one stage the sending data to the device failed. When I started to investigate the problem I realized that the Device address keeps changing in the TTN back-end. Why is this happening?
See Attached file, This is the only device currently seen by the Gateway and I restart the device.
I should mention that I still receive updates from the device in my application, which is maked " retry".
Any help would be appreciated.
The device is a Draguino I/O controller which is an exceptional device for the money.
The dev address is changing because the device is sending a join request. The problem is not that the dev address is changing but why is the device sending a new join request.
The logs show that the device is sending confirmed packet. If you do that too often you will violate the TTN fair use policy.
I do not know the Draguino I/O controller, you should have a look on the device firmware why is it sending new join requests.
May be the confirmation sent by the network to the device is not handled properly.
Are you using a deep sleep function? May be on wake up, the device has lost its context and then start the association process.
Thanks for the explanation, do you know what is under the fair usage policy acceptable time between joins?
The re-joining only occurs when I reset (re-power) the device. The problem is that I can not sent data to the device, I still receive the shipped, even so its is saying that it is retrying, which it actually dose not .
The data changes so its not the same packet, I know this because the data changes. I have a voltage I’m measuring and the value changes. This device has 2 relays of which I can alter the stage but the data is not arriving on my device. This used to work and it stopped. I will check my device and re register it, maybe this helps.
Thank you very much for your help.
Hello,
I also try to setup a node with OTAA. In my case it seems that the Join Request are answered by Join Accept packets but that this packets are ignored. So I would like to know what is the solution in your case.
For my problem I already bought a second Arduino/Dragino which I still need to test.
Thank you, Tore
I was warning you that if you send confirmed packet, you might violate the policy:
At most 10 downlink messages per day, including the ACKs for confirmed uplinks
I was not talking about the number of join request.
I understand now that the different join requests were due to you resetting manualy the device, so nothing wrong about that in your logs.
At the end, I am lost about what is your problem…
You are not able to send data to your device (downlink), is that correct?
How do you send the data? What data are you sending?
What do you check on the device to know if data have been received or not?
Join accept messages should presumably be counted as downlinks, of course the fair usage policy doesn’t actually have automated software enforcement at this point.
Another reason you would want to avoid lots of rejoins is that you will use up the join nonce space - a given value of the join nonce can only be used once, so you have to have a way to make sure that each join uses a value never before used, which tends to require non-volatile memory on the node.
In terms of trying to use downlinks to control something, remember that class A nodes (which are all that are really supported) can only receive a downlink in response to an uplink. You either need to stage a downlink message and have it sit until there is an uplink it can reply to, or have code which waits for an uplink and then immediately sends the downlink request, fast enough that it can be encoded and sent to the gateway to be transmitted exactly one second after the end of the uplink packet.
Thank you for the replies, yes this is setup as class A and the message is sent via a payload from the device interface on the TTN console. In the beginning al of this worked fine and the message arrived on the end-device and I was able to change the state of relays on the device. It stopped working for no obvious reason, however I also having some trouble now communicating with the device via the TTL (USB Com adapter). I have logged a case with the vendor. I noticed in the documentation it raises this issue but the recommended solution do not work for me. LT-33222-L
It is working for me now, I’m using the AU 915 firmware. I some how managed to corrupt my config and needed to reset to factory default. This was not that simple as I could not get any response from my terminal program. It was not responding after a few seconds of running. The solution was to immediately after a button reset to enter the password and then enter AT+FDR this will factory default the unit and keep the all user keys. Here is my config obviously it is for a different frequency but the other settings should be similar.AT CFG OUTPUT X.txt (775 Bytes) Let me know how you going with it!
Hello,
so it seems that you had to start from square one with the setup of the device? And that you left the TTN setupo alone?
I have problems with an Arduino Uno, a Dragino GPS/Lora Board and OTAA so I thought I could ask about a solution. Maybe I should get a node like yours and an own Gateway to make my testing easier.
Thank you, Tore
