inigo fernandezThanks for both clarifications
inigo fernandezThanks for the quick reply.
Devices implement the LoRaWAN 1.0 protocol, and they join the network via OTAA, using each their HardwareEUI as DevEUI, and common AppEUI and AppKey (shared, same for all end-devices). I’ve seen that sharing AppKey is not good practise, I’ll change it.
The OTAA join was working well with firmware 1.2.2; whitelist was active but empty. After updating to 1.4.6, the end-devices (the code on them didn’t change) were having trouble joining the network (the module said “denied”). I think the reason is the code they were using was trying to OTAA too often, without checking if they were already logged in (if there’s any LoRaWAN error, login again). It was not a good practice, but it worked: firmware 1.2.2 accepted the login if the network server already had a session tied to them. Apparently 1.4.6 is more strict, and it doesn’t always accept the logins of the devices when they already have an active session.
Making less join requests with an empty whitelist solved my issue. I guess sometimes devices don’t get accepted on the network because they’re using the same AppKey.
By the way, just for your information, the command you suggested doesn’t work either:
admin@mtcdt:~# curl 127.0.0.1/api/loraNetwork/whitelist -X PUT -d '{"enabled":false}' -H 'ContentType: application/json'
{
"code" : 400,
"error" : "path [loraNetwork/whitelist] leads to an incompatible element. Path Element Type [OBJECT] Update Data Element Type [NULL]",
"status" : "fail"
}
admin@mtcdt:~#
