This sounds similar to the event I have. Now that I think about it, my power plug did still work but none of the motion sensor events were working and none of the battery powered switches.
My recipe is unchanged from what I have reported earlier.
Deconz in the way it is implemented in the addon is not working. If you have both a zwave dongle and a Conbee II it will be random if the system works after a reboot. The issue was never fixed. And I have the impression that after the ingress feature was added additional issues came up.
If you want a stable deconz, move it out of the realm of Home Assistant. Run it the same way the Dresden Elektronik developers run the system. Run it the way they say it is supported. Run Deconz on bare metal. And with the degradation of Supervised support I now say, put Deconz on a separate computer.
A Raspberry Pi is so cheap. Put Deconz on a Pi or on a different Debian or Ubuntu. On a Pi you can install an entire image from Dresden Elektronik. On Debian/Ubuntu you can add the Dresden El. repo and install it with simple apt install deconz. If you do the latter install it on a Debian or Ubuntu that has full desktop so you can easily start the GUI version of Deconz when you need it and run the daemon version in the background the rest of the time.
Deconz running as a daemon on Debian or Ubuntu is rock solid. It also allows you to decide to follow the beta branch and always be up to date when you want it. And also when you do not want it.
Personally my latest change is that I now run Home Assistant on a Blue (Odroid N2+) with Home Assistant OS. No more crap with what is supported and what is not. The only addons I have are file editors, ssh, and samba
I have a NUC running Debian 10 with Mate desktop and I run Mosquitto MQTT, Deconz, and Unifi controller on that machine. All installed with apt install. All kept up to date with apt update and apt upgrade. And I have both the HA box and my NUC on fixed IP address naturally.
Result. Zero problems with Deconz. No waiting for addons to be updated. Deconz never reboots with the HA machine so no more race conditions at boot. Small machines that each consume 5-10 watts that are stable. And should HA go totally down the drain, I can still pair my zigbee remotes with the deconz groups on Deconz and have a working home. Should I want to try OpenHAB or something else I can do it and return to HA with the press of a button. I think everything gets too vulnerable when you try to run too much on the same machine.
Easiest way to put Deconz on different machine is installing the official Dresden Elektronik image on a Rasberry Pi. A Raspi 3 is fast enough. And it seems Deconz is by default setup to do minimal logging so it works quite OK from SD card (unlike HA that writes to a large database constantly). It is peanut money to have a Rasberry Pi up running with Deconz. Avoid the addon.
The Deconz Integration in Home Assistant is really stable. The issue is the Addon. Deconz integration connected to a different machine via its fixed IP is rock solid.
Last. Remember a 1 meter USB extension cable between Conbee II and any computer it is connected to to avoid radio interference from the noisy computer
I started receiving events again at 11:14 so same as last time at some point it starts again. No indication in the logs as to why it restarted.
I guess I could restart the add-on and see what happens, but not today
I moved to an all in one device to avoid having to maintain multiple machines. Based on my experience with the add-on and your thoughts here, I tend to agree that the add-on doesn’t work. That being said there is not enough benefit for me from zigbee to run and maintain another machine(I’ve got a freeNAS(true?) server, a couple desktops, laptops, RPI3, RPI zW, and my HA NUC with HA OS.)
For now I can get what I need from z-wave, 433mhz, and WiFi devices. I may revisit it in the future.
EDIT:
I see that I may be able to run this on a PI Zero W as well( I actually have an extra laying around currently.) I wish I wouldn’t have checked, now I probably have to try it. Thanks @KennethLavrsen
Is it possible to access the old web interface to the deconz add-on? I need a feature not available in the newer pwa interface
Hello together, I stumbled upon this thread, since I started having trouble with my deCONZ plugin in home assistant. I know KennethLavrsen recommends against this, and I have a fairly standard homeassistant setup, running on a raspberry pi 3, with the deCONZ plugin and a Raspbee II. I recently updated my HA installation to Version 2021.1.4 and the Hass OS to 5.1. My deCONZ plugin version is 6.6.2. I was using version 6.6.2 with the previous Hass OS version and Core version and everything was working fine. After HA and Hass OS update, I am unable to log in into the phoscon interface. If I use the Phoscon button, I get the message “network not found”. Using the deCONZ button opens VNC, gives me a dialog with an option to connect to Raspbee, which does nothing.
My deCONZ log shows the following over and over again:
20:47:20:901 dev /dev/ttyAMA0
20:47:20:903 COM: /dev/ttyAMA0 / serialno: , RaspBee
20:47:20:916 device disconnected reason: 4, index: 0
20:47:21:828 wait reconnect 15 seconds
I found this solution in the meantime: Zha can't connect to freshly installed RaspBee II on RPi 4B / RaspBee II seems not available
However it seems to disable Bluetooth, which I use for several sensors.
I would therefore be interested in fixing my Zigbee connectivity issues, while keeping BT active on my raspberry, basically going to the state before my 2021.1.4. and 5.10 update.
Thanks.
Sorry, but where did you cut the detection cycle ? Where is the option to do that ?
Thx, so stupid it was up
I have surface-mounted, flush-mounted switches or a zigbee valve, after deConz restart, they do not power the devices connected to them (light bulbs, bell). They are described in deConz as Helman TS0011, TS0012, TS0013 and in order for them to work, they must be physically turned on, otherwise they seem to work (e.g. the bell turned on in HA sends a signal according to the automation, but no longer gives voltage to the physical bell, in HA or deConz they are turned on and trigger the operation of other entities but do not turn on the light bulbs connected to them), so it looks like they are present, but their inclusion does not give voltage to the devices connected to them. I have had it for a long time and I have been looking for a solution to this problem for a long time. I don’t know English well, I was looking for solutions on Polish-language forums, but I decided to look for help here, but I don’t know if I describe the problem correctly in English, because I use a translator
Hello everyone,
I updated my systems last week (but not home assistant) and since the reboot afterwards deconz is not working anymore.
The log looks fine until the bootloader is checked. Thereafter it only tries to check again and it times up and again and again. Here is the log:
18:46:23:330 COM check bootloader
18:46:25:343 COM timout query bootloader, assume application
18:46:26:278 Announced to internet https://phoscon.de/discover
18:46:26:920 device state timeout ignored in state 2
This is running in docker (installed with the official installation script) on an arch linux server inside an KVM. And until last week everything was fine. Hopefully one of you can point me in the right direction.
Edit: It seems to be a problem with my KVM host or domain, not with home assistant nor deconz.
I found a way to turn it on remotely, I just need a wise person who knows deConz and will tell me if it is possible and if so how to automate this process.
After restarting Conbee, in the case of several devices that I mentioned at the beginning in the thread, just go to deConz (VNC) and click Read Node Descriptor or Read Simple Descriptor (s), but how to do it with an automaton when I’m away from home and one of these devices closes the water valve in case of problems?
I have a Namron 4ch button that is possible to add, but it is not showing up at all in Phoscon App. However ut is showing up as groups in the Old WebApp version Open Wireless Light Control (2016)
Lighs added to groups there is controllable. But the name of hese groups are just messy, is it possible to rename these?
Hi @Robban (eller tjenare)
Sorry for the late reply, I waited until having updated Hass before replying to give you a good answer. The last update seemed to change the channel which made my hallway lights unavailable. Funnily enough the Aqara temp sensor carried over this time which is new.
Hi folks,
I am new to the HA community. Running Core-2021.2.2, supervisor-2021.02.5 and HA OS 5.11 on a RPi 4 with a ConBee II attached and deCONZ 6.6.5
Receiving error message as follows:
WARNING (MainThread) [supervisor.addons.options] Unknown options vnc_password
As far as I can recall, this was a manual config for the add-on but has since disappeared.
Looking for some guidance on how to resolve the error. I have gone looking for it in every place I can think of but cannot locate the offending entry (assume it has been moved to a database entry somewhere).
Kind Regards,
Clinton
Yeah had that too yesterday, on the configuration page on deconz addon, i did a restore to defaults
Hi @pergola.fabio - when you restored deCONZ, assume you lost all of the configs etc?
I would prefer to avoid that if possible.
Is there a way to downgrade, remove the offending entry, then upgrade deCONZ?
Or some other way to get homeassistant to forget about this setting?
no, no settings lost, only that page where you can define the ports if you want to use ingress or not
nothing lost in deconz itself
Hi @pergola.fabio - just did that and still get the warning message.
Any other suggestions on how I can fix?
you are correct, i am still seeing it too , it was gone for a while , now my logbook is indeed filled again with those messages
21-02-09 07:15:19 WARNING (MainThread) [supervisor.addons.options] Unknown options vnc_password
21-02-09 07:16:19 WARNING (MainThread) [supervisor.addons.options] Unknown options vnc_password
21-02-09 07:17:19 WARNING (MainThread) [supervisor.addons.options] Unknown options vnc_password
21-02-09 07:18:19 WARNING (MainThread) [supervisor.addons.options] Unknown options vnc_password