Sensor IDs, best practices?

[maghac]

At first I though it was a smart move to use auto-assigned IDs, as I didn't have to record the IDs anywhere and I could use the same sketch for e.g 10 identical temperature sensors. I can always rename my sensors in the controller software (Home Assistant in my case).

But then I realised that the mapping could change, if I ever need to replace my sensor or if the gateway suddenly starts giving out a different ID. The drawback is that I need to maintain multiple, nearly identical, copies of the sketches. Is this the recommended way to do it, or is there a smarter way to make it more "dynamic"? What is the simplest way to ensure that I don't unintentionally create a sensor with a duplicate ID? Keeping my sensors documented in a text file somewhere?

[Fabien]

I think (note tested) it is possible with platformio with multiple environment
Like this :

[common]
lib_deps_builtin = MySensors

[env:uno_room1]
platform = atmelavr
framework = arduino
board = uno
build_flags = -DMY_NODE_ID=10

[env:uno_room2]
platform = atmelavr
framework = arduino
board = uno
build_flags = -DMY_NODE_ID=20

[maghac]

Thanks for the tip, I'll look into it.

I didn't even know that there was an alternative to the Arduino IDE :)

[mfalkvidd]

I would use AUTO for everything until the day I need to replace a sensor. That day I would set the ID of the failing sensor in the sketch and upload it and not worry about it again (no need to save that specific sketch).

An alternative could be to upload a sketch that saves the selected ID to eeprom and then upload the "standard" sketch with AUTO. Since a previous ID is saved in eeprom, the sensor will use that ID once it starts.

[maghac]

Ok, so there's no risk that once an ID has been assigned, the node will get a different ID as long as I keep using AUTO? Even if I upload a new sketch (also using AUTO of course)?

[mfalkvidd]

@maghac the sensor will keep the id between uploads, unless you erase the eeprom where the auto-assigned id was stored when it was first assigned.

[lafleur]

I solved the issue by using extra I/O pins and assign a static node address from a base address + ID bits... In my case below, I used 3 ID pin's.

/* **************************************************************************** */
/*                                Before                                        */
/* **************************************************************************** */

 // Before is part of MySensor core 
void before() 
{ 

 
 // need to set up pins prior to reading them...
     pinMode(ID0, INPUT_PULLUP);
     pinMode(ID1, INPUT_PULLUP);
     pinMode(ID2, INPUT_PULLUP);
     
     myNodeID  = !digitalRead (ID0);                     // ID bit are 0 = on, so we invert them
     myNodeID |= (!digitalRead(ID1) << 1);           
     myNodeID |= (!digitalRead(ID2) << 2);

     myNodeID += NodeID_Base;                            // set our node ID

     // We no longer need these pins, so remove pullups to save power
     pinMode(ID0, INPUT);
     pinMode(ID1, INPUT);
     pinMode(ID2, INPUT);
}

[napo7]

I address this issue with keeping AUTO ID.

When I need to change a node ID, I use an USBASP programmer which can directly dump and write the EEPROM memory.
When I dump the EEPROM I get a binary file which is a 1:1 copy of the EEPROM memory.

I then use a hex editor to change the node ID and then write back the EEPROM file to the node.

This way, I can keep AUTO ID feature, the controller always give me new ID when needed, and I can easily replace a failing node with the same board, just changing his ID after uploading his firmware !

[marceltrapman]

@napo7 said in Sensor IDs, best practices?:

This way, I can keep AUTO ID feature, the controller always give me new ID when needed, and I can easily replace a failing node with the same board, just changing his ID after uploading his firmware !

But when your controller/plugin/binding 'remembers' the id's it assigned you will end up with id's assigned without a sensor attached.