GUI implies it is optional, but forces entry.
Gen Application Key aligns with what aspect of the LoRaWAN specs?
GUI implies it is optional, but forces entry.
Gen Application Key aligns with what aspect of the LoRaWAN specs?
This is to support FUOTA devices, see also the following section from the “Remote Multicast Setup over LoRaWAN specification”:
Why the deviation from the terminology used in the LoRaWAN specs?
And why is supply of this key mandatory if I don’t care about FUOTA?
I can’t say about it being mandatory, but the naming surely it doesn’t deviate from the spec:
Derived from a new root key (GenAppKey) provisioned in the end-device at any time before the deployment of the end-device in the field.
So, as the placeholder says, you’re entering the Gen Application key
(or GenAppKey
), which is used to derive McRootKey
and then in turn McKEKey
for LoRaWAN 1.0.x devices.
There will be a fix related to this field in the next release as it was set to required
by error:
Hello Brocaar,
How do I fix this today so I am not stuck with a dead network and sensors?
Regards, Richard
How is this making your network or sensors dead? Other than the (temporary?) inconvenience of having to send in a random gen application key, I don’t see how it adversely affects operation.
Ah, now that is an enlightening question. I had been under the impression that my end nodes were unable to accommodate reception of some random data, thus they would not work.
Is that not the case?
If so, then I shall continue to work the problem. I was totally frustrated and had landed on this as a show stopper.
If you’re pretty sure I can set a random key and continue, then I’l keep working teh problem.
Brian is right, you may generate any random gen application key and everything will work fine. So rest assured that everything will work as usual.
I must set the record straight.
Troubleshooting now goes back to,