minimal controller code to assign IDs to nodes
I want to implement a bare minimum controller that assigns IDs to devices, enabling them to join the network.
I'm trying to understand this process better and hoping there are some example snippets of code demonstrating this? I couldn't find anything directly on the forum, but perhaps I wasn't searching for the right terms?
I've looked at the API descriptions and see that a device presents itself first. From my current understanding, if the device is new (and ID is not hard-coded, so assigned under auto scheme) it will have the default ID of 255? Is this therefore what the controller looks out for, and if it should see this 255 ID upon presentation, then it sends out an internal I_ID_RESPONSE type message to overwrite the node ID with an assigned ID of its choosing? Or does the MySensors library take care of this, sending out an I_ID_REQUEST message to request an ID from the controller? The controller will see that request and then responds with the I_ID_RESPONSE message, with the ID in the payload?
@phil2020 Seems like a good idea, but how do you handle automatic removal of nodeID's from the ledger for nodes that are no longer active? Or do you just let them accumulate?
Why don't you simply use the MySController sw that does auto-id assign?
@neverdie thanks for the reply. This is the first step. Yes I’ll also need to be able to update and remove IDs, I’ll look at that after I have the assign ID function working.
I want to have a lightweight controller that sits on a RPi Zero, so planning on writing something on node.js. Interface for admin would then be via web app.
according to the controllers page https://www.mysensors.org/controller many controllers should support Node ID generation. If you want to go for a simple one look at MyController
@gohan I really need a custom implementation for my needs, with a separate admin front-end from the ID assignment feature. I’m splitting up the controller functions between a RPi and web app.
I am missing the point, but let us know your findings
I seem to be falling at the first hurdle here. I am using the example serial gateway code and the example dust sensor code for the sensor, on NRF24 radios. I have the hardware tested and working fine with other code.
So I enable debug output with #define MY_DEBUG lines in the serial gateway and dust sensor code. I haven't defined any NODE_ID value in my dust sensor code, so it should be going to automatic mode where it should request the assignment of an ID. Note that I also erased the EEPROM to wipe out any existing ID, so it should behave just like it's a first time device. But I don't see any presentation/registration messages at the output of the gateway serial port. I only get the below output, and nothing else after that.
0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RNNGA---,VER=2.2.0
0;255;3;0;9;14 TSM:INIT:TSP OK
0;255;3;0;9;17 TSM:INIT:GW MODE
0;255;3;0;9;23 MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;3;0;9;34 MCO:BGN:INIT OK,TSP=1
For my dust sensor I get the below output on the serial port, which looks like it's attempting to present but not getting any response back from the gateway, as expected, since there is no controller at present. But if I can't see any output at the gateway serial output, I can't interact with the gateway with my controller to send back the ID response.
| / |_ / | ___ _ __ ___ ___ _ __ ___
| |/| | | | _ \ / _ \
_ \/ __|/ _ \|/ |
| | | | || || | / | | _ \ _ | | _
|| ||_, |/ _|| ||/_/|| |/
16 MCO:BGN:INIT NODE,CP=RNNNA---,VER=2.2.0
34 TSM:INIT:TSP OK
10055 TSM:INIT:TSP OK
I suppose I need to enable some other setting somewhere? I saw #define MY_REGISTRATION_CONTROLLER and included that in the serial gateway sketch, but it didn't seem to make any difference.
Can you point me towards what I'm overlooking to get the presentation/registration messages output at the gateway's serial port?
Tsm fail usually it is a problem in communication with the radio module, so you either have a bad wiring or you broke something in the code
OK, my problem in getting the I_ID_REQUEST messages to appear at the serial gateway was due to my use of the Arduino supplied eeprom_clear sketch on my node device. That sketch clears EEPROM values to 0x00.
I needed instead to use the MySensors supplied ClearEepromConfig sketch which sets the EEPROM values to 0xFF (and then copy over the example dust sensor sketch).
Now the default MY_NODE_ID AUTO kicks in and pumps out the I_ID_REQUEST messages and they appear at the gateway's serial port output.
Did that solved the tsm fail message???
For those interested in the final steps to assign the node ID...
So now I have the node in auto mode pumping out the requests to the gateway. I have also disabled the debug mode for the serial gateway sketch and see the following info at the serial output on Arduino's Serial Monitor output.
0;255;3;0;14;Gateway startup complete.
The first two lines are just the gateway telling it's alive and ready to go. The following 4 lines are showing the I_ID_REQUEST messages from the node. you need to respond with the following message 255;255;3;0;4;node_id where node_id can be any value you choose between 0-254 (but obviously should be unique for your population of nodes).
Looking at the I_ID_REQUEST messages, the first field with value 255 is the special node ID which indicates it is unassigned, and why it is important (as discussed above) that you erase EEPROM to 0xFF state using the MySensors supplied ClearEepromConfig sketch.
But it is not mentioned anywhere I could find on the forum or documentation, about the value of the second field, which seems to be changed continually for each I_ID_REQUEST message. 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.
e.g. request 255;70;3;0;3; response to send would be 255;70;3;0;4;22 if want to assign node ID of 22.
I can confirm that if you respond quickly (i.e. before the next I_ID_REQUEST is sent out), mirroring that second field value, then you can update the node ID for the requesting device. If you wait until the next I_ID_REQUEST message is broadcast, then it expires and won't accept that previous ID.
Note that you can alternatively use the special value of 255 for the second field in the response, 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.
Since the I_ID_REQUEST is happening too quick to read the random generated ID and then manually enter that into the Serial Monitor prompt, for testing purposes we can use the approach of using 255 as the second field value and ignore the random ID value.
So at the Arduino Serial Monitor window, first select the drop down at the bottom to add a Newline character at the end of the commands being sent, and then enter the following string in the send command input at the top of the Serial Monitor window, which requests that the new node ID should be 10.
Note that you need to click on the send button when actively receiving the I_ID_REQUEST messages, if you try sending during the long pause between the request pulses, the message will be ignored and nothing will happen.
So now you should have registered the device and start being able to see the registered node's output to the Serial Monitor. My sketch is just a simple toggling output of a binary value. The message meaning, as per the Serial API definitions is: node ID 10, outputting sensor ID 88, sending a set type message, with no acknowledgement required, message type 16 (V_TRIPPED), payload is binary on/off.
Hope that is useful for other's understanding.