Not save ID

[Oitzu]

Hm... if you don't want to change the lib... you could overwrite the eeprom in your sketch.

eeprom_write_byte((uint8_t*)0, 255);

Should do the trick? Overwriting eeprom position 0 with value 255.

[alfredocdmiranda]

Yeah. I think that should work! However, I think it should be an option to choose if you want to save or not the ID.

[alfredocdmiranda]

@hek would be possible implement some option that makes the node always requests a "new id"? Like DHCP.

[hek]

@alfredocdmiranda
Could you please enlighten me on what the use case is for requesting a new id each startup?

[Anticimex]

Won't a new I'd on every startup wreak havoc with the controller? That is, you will get a "new" sensor device on every startup?

[alfredocdmiranda]

@Anticimex
If you use an algorithm like DHCP, you won't get a new ID every node startup/restart. If there is few time since the node was seen on that network, the controller should give the same ID.

@hek
Well, I know that 253 nodes is a lot of nodes. However, just thinking in worst case, if you reach the limit and remove a node A, and a new node B, so will get the A id, and after that (some months later?) you remove a node C and put A on its place. So, there is a problem because A already have an ID (same B's ID). Then, you have an ID conflict. Or I am wrong?

[hek]

The problem is that we don't have any mac address or anything else unique per node that the "dhcp" can use to reassign same id.

The id IS this unique thing...

[Anticimex]

Right...

[alfredocdmiranda]

Oh...yeah...you are right! Maybe you can change ID in production? =x

[hek]

I don't know how your controller works. . But for for the vera plugin, id's is reused. If you remove a device (on the controller side) the id is free and can be handed out to a new node.

[alfredocdmiranda]

Yeah. I know that, but if you insert the old node, it would have the old ID stored. So, it would be an ID conflict.

I don't have my controller yet. I am actually creating my own and getting some ideas.