Not sure if this is due to a home assistant update or a deconz addon update (as I’ve updated both in the last week) but I’ve noticed that devices that are physically switched off (such as a tradfri light turned off at the light switch) are still showing as Available in home assistant, where previously they would have changed to Unavailable almost straight away. Anyone else experiencing this?
Yes, there is some delay between switching lights from physical switch and phoscon/HA knowing this. I think this might be due to some querying of devices states that takes time.
What is more annoying for me, is that frequently phoscon (and in consequence HA) do not report state of device properly. E.g. it thinks light is off, while it is on or other way around. Usually toggling light from HA resolves the issue, but it is annoying when out of 6 bulbs on my stairways 1 stays on while 5 go off and HA thinks everything is OK. I do not have physical switch for these lights, it is controlled only by motion sensor. So I iether need to go HA or wave my hands hoping it gets resolved next time…
1 Like
Thanks for the response but this isn’t quite the issue I’m seeing.
End-point devices like xiaomi motion sensors tend to take a while to change to “unavailable” as they only periodically ping the conbee, so deconz has to make an educated guess at some point if the device has gone missing.
Router devices though are constantly powered and are generally in regular contact with the conbee, so I’ve noticed in Home Assistant the last few months that if a bulb (for example) is removed from the socket then Home Assistant will recognise this very quickly and mark it as Unavailable. I have a few automations that reliably let me know when someone physically powers off a zigbee bulb using the switch instead of the hue / tradfri remote, and it’s usually within a minute.
The issue for me is that in the last week none of these devices ever seem to change to Unavailable, even if they’ve been powered off for hours. Testing it this morning, I can see that if I toggle the light in home assistant then it will finally change to unavailable after a few seconds. This unfortunately is of no use to discover if a device has been incorrectly powered off.
Happily I’ve never seen your own issue where sometimes HA does not report the correct state of the bulb; you might like to check if the state in phoscon matches that of Home Assistant, and if so, it’s possible that wireless interference on your network is preventing some bulbs from sending or receiving messages reliably on the mesh network (ie its possible your bulb did not receive the last message to toggle). If you ensure that your home Wifi does not overlap with your zigbee network channel number then zigbee performance becomes incredibly reliable. Firmware updates for bulbs can also help with odd issues like this.
Well, at least I know that this is not a problem of HA, as it always shows status in sync with phoscon. So the issue is somewhere between phoscon and bulbs… Strangely, depending on phoscon/deconz version it is more or less visible. There were periods of time that I’d summarize as being 99.5% stable and reliable, but there are periods, where it is ~75%…
In the past I did quite a lot of troubleshooting regarding interference, including reconfiguration of my WiFi to least interfering channels. It helped a lot, but not eliminated issues. I think that it is just up to Ikea bulbs not being the best in class 
I think you can be lucky or unlucky with your devices. I have mostly ikea tradfri bulbs, several hue bulbs, and 2 gledopto LED controllers. I absolutely never see issues with the Hue bulbs, they are rock solid. And are good value in that regard; they are practically guaranteed to work. I used to see the odd issue with the tradfri bulbs where one or two would get “stuck” every now and then (completely unresponsive until power cycle), but these have been practically eliminated with OTA updates that I carried out late last year - I think some older firmware on some of the tradfri bulbs was causing hiccups from time to time.
From what I’ve read, some brands of zigbee devices are very unreliable (in the UK and Ireland I think Innr are not great for quality or stability). You could be unlucky and have just one device that is technically working but is sometimes dropping messages, and essentially sabotaging your mesh.
My setup is completely broken now. Added this issue: deCONZ broken - Cannot connect to Conbee 2 stick · Issue #1881 · home-assistant/addons (github.com)
Hi @pergola.fabio @netjedi, did you managed to get rid of the message? If yes, how? I have them to.
Or is there some thread across the internet on this?
10X
No, still occuring
I assume the vnc_password is deprecated. The configuration is now UI by default and not yaml anymore - I can’t see vnc_password as an option there, plus it is not mentioned in the GitHub repo of the addon. Do you still get the error if you:
- Go to deCONZ configuration tab
- click the three dots at the top right and choose ‘Edit in YAML’
- remove the vnc_password part
1 Like
aha, thats must be it, indeed, if i choose edit in yaml , i still see the vnc password
gonna remove it there now,
but where to specify the password then instead?
@M1ke great hint, I was not aware of the 3 dots… 
@pergola.fabio you don’t need it anymore, just erase it.
But where to specify the password now?
@pergola.fabio I think you can’t anymore - do you even need that though? It was only used for direct vnc connection - and not the built-in (ingress) one… maybe that’s why they added the “Not secure!” part next to the port…
I still use the direct vnc, i don’t like the web vnc 
I also prefer using VNC here. But unfortunately I think it means when opening this VNC port anyone can connect to your Deconz with VNC using just host IP in your LAN without any password. Doesn’t it?
There must be a reason to remove the password but I sure would like to still have a password for VNC.
Didn’t try yet, do if we remove the password, we can still connect to it without password? I hope so
You can connect without password, I can confirm it. I think password in configuration here is totally useless.
Perfect, 1 issue less -