API Change: Moving to 64-bit IDs in v3 Firmware

[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.

Details on github here:

Special attn: @alanchow @alexbk66 @aarons22 @danmandle

1 Like

Thanks Chris for letting us know.

I already append bridge ID to device ID to make IDs unique, i.e. ZZCC63031.47cc0984

@merck Richard and I checked Control4, ELAN, RTI and URC codebases and we are storing all of them as strings. As such the change will not break any of the drivers.

Just to be sure we’ll test it out when the beta comes out as well.

1 Like

Home Assistant should be fine as its doing strings for the unique id as well.

1 Like

Homebridge-bond plugin stores IDs as string (and creates a uniqueID property by appending the bondID to the deviceID), so it should be good :+1:

1 Like

The API docs state that v3 firmware will utilize 64-bit device IDs. I would like some clarifications for the 64-bit device ID change in order to update the API calls in my ISY/Polyglot integration:

  1. If I continue to call v2 endpoints in the API, will I continue to get 32-bit device IDs?
  2. What are the chances of the trailing 8 digits of the new 64-bit device IDs not being unique per bridge?

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.