I have a zigbee device (Lutron connected bulb remote) that was working great, but then one day just seemed to be disconnected from ha. I tried to remove the device, but that didn’t quite work as the device still shows up in the UI. When I try adding it again it automatically assumes the same device name, but does not work.
I’m running hassio in a VM and am using a Nortek zwave/zigbee stick. I’m using several other zigbee devices that are working well (bulbs and another lutron remote).
Could the database entry be corrupt and causing this behavior? How can I remove it completely?
make a backup of ‘core.device_registry’ and ‘core.entity_registry’
Both can be found in …/config/.storage
Unique ID’s are the ‘config_entries’ and the name, for example ‘light.’
Store both on a notepad and remove the complete entities from the files ‘core.device_registry’ and ‘core.entity_registry’
An entity is multiple lines long and in between brackets { },
Restart HA and they should be gone.
If you break things, just replace the files with your backups and restart again
Thanks! That seems to have taken care of it. I also had to manually delete some automations that were associated with it, but I think it’s all fixed now. Hopefully whatever happened to cause the device to fall off the zigbee network doesn’t happen again.
I have similar issue and raised issue in github. it would be fixed in several days but you can try in development branch already. Please follow this link:
The updated ZHA.remove isn’t working for removing a removed/replaced Zigbee Coordinator!
I removed the ZHA Integration and then switched from a Sonoff Zigbee Bridge (Silicon Labs EZSP) to a TI CC2531 USB stick as coordinator.
The power is pulled from the Sonoff Zigbee Bridge, but the Silicon Labs EZSP device will not go away!
With the ZHA.remove command, I used the argument: ieee: ‘60:a4:23:ff:fe:xx:xx:xx’
the result in the log: 2021-03-17 17:29:55 INFO (MainThread) [homeassistant.components.zha.api] Removing the coordinator (60:a4:23:ff:fe:xx:xx:xx) is not allowed
core-2021.3.4
Home Assistant OS 5.12
supervisor-2021.03.6
I tried the editing of the registry files as suggested:
make a backup of ‘core.device_registry’ and ‘core.entity_registry’
Both can be found in …/config/.storage
Unique ID’s are the ‘config_entries’ and the name, for example ‘light.’
Store both on a notepad and remove the complete entities from the files ‘core.device_registry’ and ‘core.entity_registry’
An entity is multiple lines long and in between brackets { },
Restart HA and they should be gone.
and the entries for the Silicon Labs EZSP device keep repopulating in the registry files!
They must be hiding somewhere else!
And see if that helps get rid of the stale entry. That said, however, bear in mind that tinkering with that sqlite database may negatively impact the rest of your ZHA deployment, so use caution and take snapshots/backups first.
It’s a sqlite database, so you could attempt to prune entries directly there, but I have no experience directly doing this. I recently switched coordinator hardware, and as part of the process, I had to rename the database after deleting ZHA before adding ZHA again to use the new hardware. The database was automatically recreated (I later deleted the old file).
I did the same this afternoon - changed Zigbee coordinators.
I removed ZHA integration (and former coordination was expected to be removed/deleted), then added ZHA integration again (which sounds like it should have created a new database).
After I added the new coordinator (a CC2531 USB stick), all my Zigbee devices were already in the Devices list…doesn’t seem like the zigbee.db file got removed and re-created.
I think the absence of the file causes it to be recreated, although I can’t say for sure if that’s only on initial setup of the integration, at each reboot, or any time.
I’m wondering if maybe it’s a bug that the database isn’t cleaned out or recreated when the integration is deleted?
I’m wondering if maybe it’s a bug that the database isn’t cleaned out or recreated when the integration is deleted?
It sure seems like it.
I looked at the SQLite Web add-on. It appears geared to ONLY look at the home-assistant_v2.db file, so you can’t use it to look at the zigbee.db file.
I just tried the experiment of stopping the HA server, renaming my zigbee.db file to zigbee.db.old, and restarting HA. ZHA created a new zigbee.db file, but all it had in it was the CC2531 coordinator. I would have to go back and add in all the Zigbee devices again.
So, I restored the zigbee.db.old file and restarted HA. All my Zigbee devices retured, including the former Sonoff coordinator.
At this point, I have a drastic way to eliminate the old Sonoff coordinator from the database…nuke it.
While that works to remove the Sonoff coordinator, I’d hate to have to spend an hour running around the house re-pairing all the Zigbee devices, yet again, in order to work around this suspected bug.
I poked around in my zigbee.db using sqlite3; there a number of inter-related tables, so it might take some investigative work to see if you can arrive at a safe set of edits to achieve your goals. This, of course, assumes you have some comfort level in using sqlite3 (and that it’s available on your platform of choice; I installed it here on macOS with Homebrew).
You’ll have to weigh the potential time spent for both approaches and decide for yourself which one best suits you. In my case, I did do a full “nuke and pave” approach when switching hardware, because most of my mesh are Aqara sensors, and those delightful devices don’t unpair when you delete them from ZHA. So, I had to go around and hand re-pair most of my devices anyway. Wasn’t too terrible (~25 devices) but it did take some time.
I’ve heard of mysql and used it a little, but until today, I’d never heard of SQLite!
It will definitely take more than an hour to figure out if I can run SQLite inside my HA virtual machine in VMware esxi and then even more time to try to use SQLite.
I’ll probably have to nuke the zigbee.db file in order to get rid of the Sonoff Zigbee Bridge out of the database. I hate taking such drastic measures.
For future reference, what are all the steps for switching Zigbee coordinators? I didn’t find any written instructions for doing it, so I guessed at the needed steps!
When I removed the ZHA integration, was I supposed to restart HA before adding the ZHA integration again?
I removed ZHA integration, saw it was gone, did not restart HA, added ZHA integration, and set the CC2531 USB stick as the coordinator.
Here’s what I ended up doing (it took me multiple attempts, because like you, I was mostly guessing at first at what was needed; I got some help from the gentleman that made the coordinator I’m using which helped get the details worked out).
Snapshot or backup!
(Optional) Remove each device from ZHA – for some devices, this will also unpair them from the coordinator, so they can easily be paired to the new one automatically afterward
innr and sonoff socket plugs behaved exactly as I wanted – I saw them join the new coordinator more or less right away
philips hue bulbs did unpair, but needed the power toggled to be visible during pairing (i tested this scenario with a sacrificial bulb first just to be sure, because resetting these to factory defaults without the currently paired coordinator is really painful!)
aqara switches and sensors couldn’t care less what you do – you’re stuck hand resetting and re-pairing these
Remove the ZHA integration
Stop HA core
Remove or rename zigbee.db
Start HA core
Add ZHA integration with your new coordinator
Be patient and let as many devices auto join as are able, to save yourself some legwork
Add devices that didn’t auto join the new mesh
The bulk of my time was spent going around and hand resetting all the aqara stuff, along with one socket plug that’s in a hard to reach (RF-speaking) location and needed coaxing.
(Edit: quick note – consider making a list of your existing zigbee entity names and IDs, so you can rename things as required to keep your automations, lovelace, etc working without further edits)
With some suggestions and hints from the zha deveolpers, I accomplished the surgical removal of the Sonoff Zigbee Bridge (Silicon Labs EZSP)!!
Along the way, I broke HA, too.
Thankfully, I had just made a full snapshot that I could restore!
The zha api is written to prevent a user from removing the Zigbee coordinator.
They pointed me to the code to disable, so it could be removed.
Thanks! It did not delete the ‘stubborn’ non-deleteable (GLEDOPTO mini 5 in1 leddriver) device from the ZHA list straight away, but after the removal of the device related parts in these 2 files, like you suggested, and after the obvious restart, I was able to remove them from the list within the UI this time. All good now!
renamed the zigbee.db to zigbee.orig, restarted HA.
it recreated the zigbee.db as blank and I was able to start over. I can see I need more repeats in my house… one of my bulbs will not produce a valid configuration due to its location, so that caused a stale entity that would not remove itself from the coordinator.
