Overnight so about 7 hours so I re-paired them. I’ve had them for over a year and had no trouble until now.
Every time Deconz restarts all my devices (or ALMOST all of them) stop working… most still show up on the map (though many do not) some are ghosted, some… Pressing a button will cause a blue indicator to come on on the map momentarily but most of the time nothing will come up in the Deconz logs and it won’t pass events to home assistant…
I’ve had to re-pair all my devices 4 times now and I’ve only been using a Conbee II for a few days… This has been the worst home automation experience I’ve ever had.
Is there anything I can do to fix this? My devices are predominantly Xiaomi round buttons, motion sensors, door sensors and temp/humidity sensors…
Any help would be greatly appreciated. Going to the Deconz GitHub next.
I don’t recognise that behaviour at all. Have never lost anything on a restart (so far)
Seems the problem is the Deconz integration in Home Assistant… Whether devices show up in Deconz appears to be largely irrelevant (ie those I have found missing can still work).
If I remove and integration and then re-add it things begin to function again… So there’s some sort of a problem that occurs with communication between Deconz and the integration when Deconz restarts. I’m glad I figured that out before re-pairing everything again.
Ok, so it probably is that the add-on changes address. Enable zeroconf discovery and you should get rid of that issue
Hi, since I moved all my bulbs (hue, innr, osram and tint) to deConz I’m facing serious problems with stability of hue bulbs. I never had these isuues before. And yes, I use an usb enhencement cable.
The interesting points:
- osram GU10 bulbs, which were unavailable all the time on the hue hub, are stable and reliable
- hue bulbs are, even located in the near of the conbee stick and a very strong mesh network, high frequently unavailable.
- Via HA as well as phoscon, Scenes and groups can control the bulbs reliably but accessing them directly (change color, switch on or off) does not work.
The last point is the most important one. Why does a screne working accurate when the direct control of a single bulb then does not work? Why is sthe status, displayed in HA obviously wrong? Sometimes the status changed to unavailable after the second or third try to switch on or of.
For the time being, I have too much trouble with my light control. In times of the hue hub, the motion sensors were too slow and osram alway unavailable and therefore uncontrolable. But now the situation changed and the hue bulbs are very unreliable.
My mesh cannot be the trouble maker:
The arrows showing the bulbs cousing the major trouble. all hue bulbs
I have discovery enabled in home assistant but it never automatically sees the Deconz add-on… I have to manually add the integration… what’s more when I re-integrate I discovered that the device_id’s change for the buttons thus causing a nightmare where home assistant cannot start due to the automations pointing to old device_id’s. What’s worse is that config check does not pick this up. I don’t understand why the device_id’s would change… I thought they were static to the device… Or is that unique_id?
At any rate, I just spent 5 hours fixing my system. If this is still a thing when I get back in 2 weeks I’ll submit an issue.
I run with hassio installed on an Ubuntu machine
A while ago I decided to move my Deconz from being a Hassio managed Docker addon to simply being installed on “bare metal” directly in the Ubuntu.
It is not difficult to install. It is the official way that Dresden Elektronik (the company that make Conbee) does it. You need to install what they call the beta or development version to match what is distributed in the Home Assistant Deconz addon.
The advantages are
- Gets updated with rest of Ubuntu with apt update and apt upgrade
- Runs on the same IP address as the Ubuntu so predictable
- Home Assistant does not care. It connects to the Deconz API via an IP address anyway so all is discovered like normal.
- You can restart and upgrade Home Assistant and any addons all you want without Deconz restarting.
- No issues with ttyACM0 and ttyACM1 swapping when having multiple USB sticks or the Deconz addon not starting up when using symlinked device name (unresolved known bug)
The only real disadvantage I see is that it is not the easy one click installation. But with all the problems people have it may be a very time consuming 1-click.
Deconz is running on a raspberry pi located centrally. Whatever problem exists in terms of issues reconnecting after a Deconz restart is made worse by the fact that removing and re-adding the integration creates new device_id’s… Seems like madness to me… Especially given that home assistant cannot cope with that change and will simply not start…
Something is up with deconz right now. Mine worked like clockwork for over a year. Upgraded from .58 to .69 and it’s small problems all the time. It’s a bit disheartening to see that the majority of commits is expanding features and not fixing broken things, that is for me a bad sign in a project. Hopefully it will settle down. Conbee and Deconz usually works like a charm.
and the issue is?
Buttons needing double presses sometimes. Lights not responding. Lights turning on again after being turned off. IKEA lights not reporting CT anymore and can thus not change colortemp via reemote. Motion detector not always turning light on.
On reboot of raspberry all deconz devices gone unless I restart homeassistant again, this is off course not necessarily deconz fault, might as well be homeassistant that does something different at startup.
None a crisis (CT thing very annoying) but surprising since I had none of these issues before upgrade.
It is known that HA is not good at removing “cruft” from core.entity_registry and core.device_registry.
The devs added a GUI way to delete entities. But for devices the only way that works is to remove the integration that added them and if something from the old days is there, HA may not even do that properly.
I encourage to remove the Deconz integration, then walk through all the files in .storage and remove ANYTHING related to Deconz (with HA stopped), and then add the integration again. Remember to have a safe copy of the files because it is easy to miss a comma or quote or bracket and then HA will not even start
I suspect that device_id is generated randomly upon integration. It’s something I’ll have to look at when I get back in 2 weeks. Hopefully the system will keep running while I’m away
Discovery or zeroconf? They are not the same thing
Yes device id is randomized on creation. Unique id is what static
Hey, that’s what I detected as well. I thought, that I was doing something wrong. Reading this, gives me a good feeling
Sorry to bring this up again, but can you please explain in a bit more detail how it works? When I open the STD OTAU plugin in VNC then I can select the device but when I open the window to select the file, then it only accepts .ota.signed files but the Ledvance files are all .ota. When I simply rename the files, I can see them in the window but selecting the files and then click on the “Update” button doesn’t do anything.
look here : https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1631#issuecomment-548601605
Thanks for the info!
I’m on the official addon and I don’t get how I can transfer the renamed file to it.