htdvisser
commented
5 years ago Although I think this might be useful in some cases, I don't think that this is a very common situation. A proper device commissioning process should generate random keys, register the device in the Join Server and then provision the hardware. Situations like these can then simply not occur.
The process described in this issue -- where keys aren't securely stored and might be accidentally flashed to a completely random device -- may be used for development devices, but for production devices we should really strive toward more mature processes.
With the upcoming v3 stack there will be a "workaround" to accomplish this "checkbox": have the application delete the device registration from the Join Server when the device isn't supposed to join.
If there's a lot of demand for a real checkbox, we can reconsider this later.
This is a feature request for the backend.
Prevent a second device to perform a join while a first devices is already joined using the same keys and ids.
Create a new device on the console, program the keys into a physical device, let the device join the network and deploy it. A few months later the same code base was used and the same keys were accidentally programmed into another physical devices.
The second device joined the network and in the process kicked the first device which is in production from the network.
Yes, but it means I need to go out into the field to find the first device and perform a restart to make it rejoin.
Have the option to ignore any join requests. This should be a tick box which one can tick after a device already performed a successful join. One can untick this box if you know you are doing a rejoin.