yesterday, i forced a temperature sensor to re-join by manually powering it off and on again. this worked, but something went wrong – very few uplinks were coming in (the sensor is configured to send every 5 minutes).
looking at the two join events with different DevAddr, did the sensor maybe join twice in parallel?
(in the end, i sent a reboot command via downlink to the sensor, and now it’s working fine.)
It’s hard to tell with only the screenshot you provided, but do you have the content of the JoinAccept messages and downlinks that were sent to the device ?
Apart from radio signal strength, what could also explain receiving a few uplinks is that the device was sending on channels that are not activated on you gateway.
i do have the content of the two join messages, which are more or less identical except for the different DevAddr, but unfortunately i haven’t saved any downlink messages.
i think i can rule out radio signal strength or mismatched channels, as the same sensor was reporting every 5 minutes until the hard reboot, and again later after the soft reboot. so i still think the join went somehow wrong.
Have you checked for firmware updates for your device? The device chooses to send uplinks and also the channels.
Upon joining, the LNS may inform the device of applicable channel(s). The content of every join accept basically (excluding the cryptographic values) the same each time. So I don’t think it’s possible for a join to “go wrong”. In fact, since the device could communicate, it did join successfully.
Have you inspected the FCntUp values? Normally, there would be no gaps. If the device somehow uses unsupported channels, some uplinks will be sent to nowhere and gaps in FCntUp will be observed.
I believe that good devices would be designed to continue working. So you got two joins because the first one wasn’t successfully received and the device tried to join again.
