[EDIT: we will make the jump to “v3” firmware with this change.]
Bond Community Developers:
Please be advised that we are switching to 64-bit identifiers for devices, commands, skeds, etc. as of v3 firmware (scheduled to go to beta 27 SEP 2021). Existing IDs will not change. The reason for this change is to allow for universally unique ids that will be useful in an upcoming distributed groups/scenes feature.
Not sure exactly how to interpret the question. I think that’s a no.
New devices, schedules, and commands will get 64-bit IDs. Existing 32-bit IDs will be grandfathered.
If you are treating the IDs as strings then you’ll have no problem.
The probability of any two IDs conflicting is 1 in 2^32, or 1 in ~4 billion. I know that seems like an insanely low probability, so why would we bother to move to 64-bit IDs?
The reason is that, paradoxically, the probability of a conflict becomes unacceptably high when there are more than two IDs that need to be unique. With 32-bit keys, we only have an acceptable risk of conflict with up to 96 keys on a single Bridge (see image). We consume a key not only for each device, but also for commands, skeds, and later for groups, scenes, and controls.
I wasn’t asking what the mathematical probability was no, but more of the possibility of last 8 digits of IDs for devices for a given bridge being unique based on the way the device ids are calculated. I am assuming they aren’t randomly generated (thus the simple math you provided above) but instead utilize an algorithm for generation.
They are pseudo-randomly generated. I have not read into what the exact PRNG algo is on ESP32, but while it’s not truly random, it is hopefully close enough for the purposes of the birthday problem calculations to avoid conflicts!
Ah. Well that answers that question. I will have to generate my own internal IDs (addresses) and ensure they are unique I guess, since I am limited to 8 characters. It currently just accepts the device ID as the address.