Good question and the short answer is the device driver assigns each device a sequential “USQ” number (USQ, USQ1, USQ2, USQ3, etc).
If I add a new device with UPStart, the UPB driver discovers it and assigns it the next available number. That typically means the next highest number (USQ4, USQ5, etc).
If I use UPStart to remove a device, the UPB driver also removes it, leaving a gap in the USQ sequence. The next device I add will be assigned that ‘gap value’.
I imagine that, under the hood, whenever the driver performs a discovery, it compares the discovered device to what it already has on record (my guess is by creating a hash key using a combination of device attributes) to ensure that it doesn’t create a duplicate.
BTW, if the naming sequence sounds simplistic it’s because there’s an important architectural difference between Premise and Home Assistant.
Premise has an additional abstraction layer where you define virtual objects, representing lights, appliances, media_players, etc. The automation logic works with these virtual objects. These virtual objects have names, properties, etc but have no association with real-world devices. It’s a virtual model of your home’s devices but with no connection to physical devices. That’s a separate step.
When you install a driver, like the UPB driver, it creates device objects representing real-world devices like UPB light switches. You then ‘soft-link’ or, in Premise parlance, bind a virtual light object to a UPB device object.
If you remove one device object or even the entire driver, you simply break the bindings between itself and the bound virtual objects. All your virtual objects retain their names and properties and no automations are invalidated.
That’s why the name assigned to device objects can be so simplistic.
I added this diagram from Premise to highlight the separation between virtual and device objects.
Hardware ports are on the left, device objects are in the center, and virtual objects are on the right.
-
I have a UPB PIM connected to COM5 and its very first device object, designated USQ, is bound to the virtual object named FoyerLight.
-
Similarly, I have an ELK M1_Panel connected to a network port and it has a Zone device object called Doorbell that is bound to a virtual object with the same name.
If I no longer wished to use the M1_Panel to detect the doorbell, and use some other means, I would un-bind the virtual Doorbell from the M1_Panel and re-bind it to the new device object (whatever that might be). Any automations involving the virtual Doorbell continue to work without modification.
, I’d still look into adding to the device registry and build device triggers for this