Why does the value of second field of I_ID_REQUEST message change for each request?
-
Hello,
I'm trying to understand the auto assignment of ID better for controller development. Here is an example of my output at the serial port of my serial gateway. The four bottom messages of the output are the I_ID_REQUEST from the node.
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.2.0
255;110;3;0;3;
255;63;3;0;3;
255;16;3;0;3;
255;225;3;0;3;Can I ask why the second field of those I_ID_REQUEST messages are always changing? Is that for purposes of helping to uniquely identify requests when multiple nodes may be requesting auto assignment at the same time?
If a controller responds immediately to the I_ID_REQUEST of 255;110;3;0;3; with 255;110;3;0;4;55 for example, will it accept the response, or does it need to be 255;255;3;0;4;55 to work, i.e. the second field always needs to be 255 also?
Thanks,
-
From my testing, it appears that the second field is a way to enable nodes requesting an update to be individually targeted with an ID assignment response. So potentially useful if you have two or more nodes requesting a node assignment at the same time. Note that the node ID you assign (i.e. the payload value for the message) doesn't have to match the random value in the request, but you do have to use it in the response, before the next request comes, otherwise it expires.
e.g. request 255;70;3;0;3; response to send 255;70;3;0;4;22 if want to assign node ID of 22.
Note that you can alternatively use 255 for the second field value and it will accept the node update request, but that may have issues if you have more than one device requesting an ID at the same time.
-
From my testing, it appears that the second field is a way to enable nodes requesting an update to be individually targeted with an ID assignment response. So potentially useful if you have two or more nodes requesting a node assignment at the same time. Note that the node ID you assign (i.e. the payload value for the message) doesn't have to match the random value in the request, but you do have to use it in the response, before the next request comes, otherwise it expires.
e.g. request 255;70;3;0;3; response to send 255;70;3;0;4;22 if want to assign node ID of 22.
Note that you can alternatively use 255 for the second field value and it will accept the node update request, but that may have issues if you have more than one device requesting an ID at the same time.
@phil2020 That's correct - the purpose of this field is to uniquely identify ID requests when several nodes are requesting an ID at the same time (and thus, preventing nodes with same ID assignments). Nodes accept I_ID_RESPONSE messages with either 255 (for backwards compatibility) or the random "token" sent with the I_ID_REQUEST message.
-
@phil2020 That's correct - the purpose of this field is to uniquely identify ID requests when several nodes are requesting an ID at the same time (and thus, preventing nodes with same ID assignments). Nodes accept I_ID_RESPONSE messages with either 255 (for backwards compatibility) or the random "token" sent with the I_ID_REQUEST message.
@tekka I'm wondering if there have been any changes in the ability to update the node ID via I_ID_REQUEST? In the past I am sure I was able to send a message to devices which had the same clashing node IDs and tell them to take on the ID 255. This would then put them into the mode, as if they were new devices, and they would automatically request their new ID. But if I try to do this now, they seem to get the node 255, but they don't emit the automatic messages to request new IDs e.g. successive messages like below
255;110;3;0;3;
255;63;3;0;3;
255;16;3;0;3;
255;225;3;0;3;I was intending to use the approach of assigning the 255 address to enable me to handle the re-assignment of new node IDs where multiple devices were reporting the same node ID (e.g. more than 1 device on the channel reports that it has the same node ID "1").
I note that erasing the device completely (including EEPROM) does trigger the appropriate automatic requests, but once programmed and I try to set the clashing node IDs to 255, doesn't trigger the same behaviour of automatic ID request.
Is there an issue with how it works in the current library version, or is there another way to do it?
Thanks,
-
@tekka I'm wondering if there have been any changes in the ability to update the node ID via I_ID_REQUEST? In the past I am sure I was able to send a message to devices which had the same clashing node IDs and tell them to take on the ID 255. This would then put them into the mode, as if they were new devices, and they would automatically request their new ID. But if I try to do this now, they seem to get the node 255, but they don't emit the automatic messages to request new IDs e.g. successive messages like below
255;110;3;0;3;
255;63;3;0;3;
255;16;3;0;3;
255;225;3;0;3;I was intending to use the approach of assigning the 255 address to enable me to handle the re-assignment of new node IDs where multiple devices were reporting the same node ID (e.g. more than 1 device on the channel reports that it has the same node ID "1").
I note that erasing the device completely (including EEPROM) does trigger the appropriate automatic requests, but once programmed and I try to set the clashing node IDs to 255, doesn't trigger the same behaviour of automatic ID request.
Is there an issue with how it works in the current library version, or is there another way to do it?
Thanks,
-
@tekka Thanks for the pointer about the reboot. After some experimenting I found that two devices sharing the same ID and receiving the 255 node ID will receive that message simultaneously (since they are both sensitive to the same ID) and would try to send their requests at the same time, interfering with each other on the channel and only one request being received at my controller. However both devices seemed to update with the new NODE_ID value, even though I was using the random token which should only act upon the device that issued that token. To overcome this I added a random delay before the update/storage of the new ID, changing the timings of each device.
So in below code, it is essentially called twice, the first message is sent when a clashing node is detected, sending a NODE_ID value of 255, and each device then reboots at a different time. The devices will then automatically request a new node from the controller and this time they will get issued new unique NODE_ID values from the controller.
// Code snippet from void receive() delay(random(1000)); // delay up to 1000ms to de-conflict simultaneous updates hwWriteConfig(EEPROM_NODE_ID_ADDRESS, message.getByte()); // store new NODE_ID software_Reboot(); // Soft reboot in NRF5 void software_Reboot(){ wdt_enable(WDTO_15MS); while(1){} } -
@tekka Thanks for the pointer about the reboot. After some experimenting I found that two devices sharing the same ID and receiving the 255 node ID will receive that message simultaneously (since they are both sensitive to the same ID) and would try to send their requests at the same time, interfering with each other on the channel and only one request being received at my controller. However both devices seemed to update with the new NODE_ID value, even though I was using the random token which should only act upon the device that issued that token. To overcome this I added a random delay before the update/storage of the new ID, changing the timings of each device.
So in below code, it is essentially called twice, the first message is sent when a clashing node is detected, sending a NODE_ID value of 255, and each device then reboots at a different time. The devices will then automatically request a new node from the controller and this time they will get issued new unique NODE_ID values from the controller.
// Code snippet from void receive() delay(random(1000)); // delay up to 1000ms to de-conflict simultaneous updates hwWriteConfig(EEPROM_NODE_ID_ADDRESS, message.getByte()); // store new NODE_ID software_Reboot(); // Soft reboot in NRF5 void software_Reboot(){ wdt_enable(WDTO_15MS); while(1){} }@phil2020 Thanks for reporting back. Do you happen to have a full debug log of both nodes incl. GW debug log while assigning ID 255, rebooting and setting new IDs (without random delay) - I'd like to understand why the random token verification failed.
