Dynamic addressing
malaki86 opened this issue · 11 comments
I'm working on an ESP 32 project that will use both ESPNow and SoftwareBitBang strategies. I was looking at the dynamic addressing and it seems vital that I include this, but I can't find any sample code or examples of actually using it. Does anyone have any that they can share? It will be a single Master with multiple slaves.
This was implemented in 2016, according to this post, #94, but none of the links in that thread work (error 404, not found).
Ciao @malaki86 the dynamic addressing was discontinued in 2019 since version 12.0
I think the best solution for your use case is to include the mac address in the packet (here docs) and use that to identify devices instead of the device id. ESP32 already has one, the other devices need it, it could be written once in the EEPROM manually, or could be generated automatically using a good random seed, or they could be set manually through switches. Then you transmit packets to a certain mac address and you are sure to contact the device you are interested in.
That's definitely a problem, then. The slaves won't know the Mac address of the master, so there's no way to contact it.
@malaki86 Master can transmit cyclically a broadcast including its own mac address.
Would this work:
Master is assigned bus id 1 (never changes). Every slave is assigned 254. At initial start, the slave contacts the master for a new ID. The master then assigns a new ID, say 10 and transmits the new ID to the slave. The slave receives it, then changes to the new ID.
I just saw the master broadcasting comment.
So, no "standard" bus ID?
It depends on the application and the functionality you aim to implement, if you don't need to separate devices in groups, or to implement subnets, the bus id is not useful. Using the mac address is better than using device ids and the mechanism you described above if it is desirable to have an address that does not change and identifies a certain device, then the master just needs to advertise its presence and wait for slaves to show up and provide with a mac address that is not already present in its memory. If a device does not answer anymore can be removed from memory. So if one node fries, you can swap it with another without any manual configuration required.
Ok, I think I understand.
Next to learn is using 2 strategies as one combined network.
Thanks for the info
@malaki86 if you aim to implement the pattern described above remember to add a relatively long random delay in the node before transmitting a response to the master's broadcast, so you avoid to momentarily saturate the link (many nodes get the broadcast, they all want to answer at the same time).
Ok, I definitely will