DEconz - Problem 'Not Unique Entity ID'

Hi all,
my problem is a bunch of error messages in the HA Log File.
I assume these errors are present due to reconnection of the sensors to DEconz Conbee II Stick.

I have actually
approx 32 error messages at
installed 9 Aqara Sensors / 3 Plug Units / 3 Lights handled by actually approx 30 Automations.

The messages appears like that:

2020-04-23 23:18:46 ERROR (MainThread) [homeassistant.components.sensor] Entity id already exists - ignoring: sensor.openclose_6_battery_level. Platform deconz does not generate unique IDs
2020-04-23 23:18:46 ERROR (MainThread) [homeassistant.components.sensor] Entity id already exists - ignoring: sensor.openclose_22_battery_level. Platform deconz does not generate unique IDs
2020-04-23 23:18:46 ERROR (MainThread) [homeassistant.components.sensor] Entity id already exists - ignoring: sensor.openclose_21_battery_level. Platform deconz does not generate unique IDs

I found following thread , which handles imo the same issue, but I do not really understand the solution.

I read it, that ‘a’ solution would be to DELETE the integration DEconz completely.
But I guess , that I have to redo all 30 automation incl. all sensor registrations at DEconz…is that right?

Is there any other way to shutdown the system and open the Database, deleting some IDs/Devices completely?

I hope, that some guys here can bring some light in, on how I get rid of these errors…

Best regards,
Jörg

1 Like

This is exactly why I was asking about this in the thread you posted before I started doing any automations. I am used to having some static ID from my experience with SQL databases (if you are linking to something, you should always have static, unique identifier), so I wanted to acomplish something like this here and not using the “generated” id like binary_sensor.openclose_6. If you leave it like this, the problem now is that if you remove and readd the integration, those entity ids will change. This is because when you add a sensor, it will get added to HA right away, with default name, before you get a chance to rename it in Deconz UI. Now if you remove the integration and add it again, the previous entity “binary_sensor.openclose_6” will not be named like this if you changed the name in the Deconz, but it will be actually snake-case version of the name you put in. For that reason I started doing this procedure, where I add a sensor to Deconz, let’s say an window/door contact sensor, this will get added to Deconz and to HA aswell as for example “binary_sensor.openclose_10”, now I rename the node in Deconz UI to “Living Room Window Contact”, then I go to HA integration and I manually change the entity_id to “binary_sensor.living_room_window_contact” and then I base my automations on this entity_id, because now if for some reason I have to remove the integration and then re-add it again, the name will stay the same. Only problem I found is with multi-sensors - like temperature, humidity and pressure in one sensor, I have one for example called “Living Room Ambiance”, I renamed the entity_id to “sensor.living_room_ambiance”, but since there are actually 3 sensors for one node with one name, the entity_ids will become “sensor.living_room_ambiance_1”, “sensor.living_room_ambiance_2”, “sensor.living_room_ambiance_3”, and sometimes after readding they will mix up, so if temperature used to be _1, now it might be _2, and so on. Otherwise I’m quite happy with that, I even successfully migrated from using the Conbee localy, to created Raspbee on a separate Raspberry PI, connected via network, and I just restored the Deconz backup, readded integration and nothing broke.

Ok,
but with already these bunch of errors and with both (Hassio and Conbee II) connected to one Raspi, will the database be automatically clean after removal of Phoscon and reconnection?
Or is there some wrong database stored on the Conbee, which will be re-synchronized causing the same errors?

What would be a solution for this setup?
Has this been posted as Issue or even Feature request at deCONZ Github (I didn’t see anything like this?)…
Couldn’t that be done by a software switch/flag, which need to be activated to start synchronizing with Hassio?

Regards
Jörg

I have found a low impact solution to this problem. So what happens here is that a device get’s a new ID in Phoscon/deCONZ internal database while maintaining the MAC address. So for example MAC aa:bb::cc was ID 5 on first connect and becomes ID 7 on second connect.

However, somehow in Home Assistant internal data, ID 5 is stored and kept, whatever happens in Phoscon. Home Assistant Log tells you which ID it expects in it’s log:

Platform deconz does not generate unique IDs. ID aa:bb::cc-01 already exists - ignoring light.dimmable_light_5 (5 is the expected ID here)

My simple solution to that (for a light):

  1. Log into Phoscon Web interface.
  2. Go to gateway => Backup
  3. Create and Download that backup. Rename file.dat to file.tar.gz and extract via tar xzvf file.tar.gz
  4. In the extracted files you find a zll.db. Open that file with an SQLite database browser like for example sqlitebrowser
  5. In nodes, you’ll find the device with it’s mac address and ID. Change the ID to the one desired by Home assistant and write the changes to the database file
  6. tar the file again: tar cvf blabla.tar deCONZ.conf zll.db session.default
  7. Rename blabla.tar to blabla
  8. gz blabla
  9. Rename blabla.gz to blabla.dat
  10. Restore blabla.dat via Phoscon Web Interface

I haven’t tested, but I’d guess for sensors you would have to do the same in the sensors table, but as said that’s just a guess.

Issue still present as of today…

Copy that. Annoying. Only “solution” (ugly workaround) is to restart Home Assistant.