Prior tests of ABP via both v2 & v3 gateways had downlinks working OK.
Today I’m getting “no device session; check device activation” on the v3 console for a newly setup device with Rx1 set to 5s both in the server config and having edited the appropriate entry in the source for the firmware. This is after getting a dozen or so uplinks arrive.
I’ve checked the device on v2 with a pre-existing ABP setup and the device receives downlinks just fine.
I’m getting a bit snowblind with all the combinations so I’m asking if anyone else has tried ABP downlinks of late and if anyone has any ideas about the config.
Just ran another cycle of tests - I have one ABP setup with the Rx1 window at 1 second and the one above set to 5 seconds. First one I can schedule downlinks, the second one I get the error message.
There’s something in the git repository about changing things to make it impossible to schedule downlinks when there’s no device session.
That change seems illogical to me, because a registered but never previously seen ABP device could pop up at any time, and any downlink previously queued for it should then immediately send in that opportunity.
Your issue might be with what constitutes the determination of a valid device session - but there seems to be no basis in the design for LoRaWan for the idea that a “device session” is something even applicable to an ABP device.
Thanks, ran out of time to go ferreting about in the repro or the source code, but I couldn’t figure out what it mean’t be a session - particularly as I setup two device entries today, one does allow downlinks, the other doesn’t.
Which seems rather illogical, since an ABP device could validly appear for the first time at any point, there seems no reason why it shouldn’t be possible to stage a downlink for it in advance.
If a “valid session” (whatever that is stretched to mean in the case of ABP) is required before one can be scheduled, then it would need to burn at least one extra uplink before a downlink could even be queued to be sent in response to the next, unless the entire downlink setting process is automated and fast enough in responding to that initial uplink to make the 5 second rx1 window - that it often isn’t is why queued downlinks exist.
Mostly your issue reminded me of this oddity; I’d thought there might be a connection if some quirk were making it seem as if your device didn’t have a valid session (again, strained for the term to even have meaning) but it may not actually have much to do with your issue.
I can confirm that after the v3.11.2 upgrade, some ABP devices had issues scheduling downlinks, with the symptoms described in the first post. An quickfix was deployed last evening that should fix the issue (based on the PR mentioned by @htdvisser).
Regarding the valid session requirement:
ABP devices have a session from the perspective of the Application Server, present from creation of the end-device. Since the AppSKey is known to the Application Server from the creation time, you may queue downlinks before the first uplink ever occurs. The linked issue does not affect downlink behavior for ABP devices (and if it did, most likely it would have been a bug).
OTAA devices do not require the first uplink to occur either. After the join-accept was received by the Application Server, the Application Server considers this new session to be a pending session, which would indeed become the device session once one uplink is received using this particular session key ID. But you can already schedule downlinks via this pending session, and once the first uplink is received by the Network Server, the queued downlink will be received by the device.
The requirement that we have at least one session (be it pending, or not) has always existed in the backend - it’s just that the frontend now takes it into account for better UX.
I cracked. The wife is livid, but I just had to try.
If you enter a 1 in Rx1, you get 1
If you enter a 5 in Rx1, you get 5
If you don’t enter anything in Rx1, you get 1.
When I’m allowed back in the RF workshop, I’ll check what happens with OTAA downlinks that have to be transmitted by a v2 gateway - last test it was a no which makes things tricky for keeping gateways on v2 and migrating devices to v3 OTAA …