I did try it - it seems a bit inconsistent to me whether my sensors get marked as unavailable or not, I need to do more testing while tailing the debug log to see what’s coming over websockets.
I reviewed old discussions regarding the config filter for signalling updates. No one mentioned issues outside of with switches so maybe I can remove the check for sensors and binary sensors.
@donnib, @simonporter007 you guys didn’t have issues with ghost events for motion detectors or door/window sensors right? It would improve certain aspects if I can remove the check when it is not related to switches.
@donnib, @simonporter007 I’m taking your silence as the go ahead to remove the config control for ordinary sensors and binary sensors but I will not change it for remotes. I will also update the documentation to suggest that automations take care to cover both from and to states to not get ghost events
Thanks @Robban for the excellent work. I ordered a Conbee and I’m looking forward to replace my hue bridge and Xiaomi Gateway with it.
Do you know when the component should be going mainstream?
Regards
1 Like
No date yet unfortunately. The documentation has been approved though.
2 Likes
Sorry for silence Robban, I don’t actually have the motion detectors or door sensors yet (I say yet…) so can’t comment. I’m sure you have it all in order though!
Happy holidays/merry christmas.
1 Like
I have pushed a new version that will update on reachable and battery properly (hopefully). But this also means that you will need to be more specific with your states in automations so you don’t trigger automations when a battery update is sent.
Do you mean just making sure to set “from” and “to” states in the trigger?
Yes. Since for example when battery level changes there will be a signal to update sensor values, that will trigger the automations that looks at the sensor
Do we need to set both from and to? For example if I have to set to “on” and the sensor battery updates, will it trigger? Or just if there is a trigger on any state change of th sensor.
I am not sure. I don’t know how automations handle it. If to only requires that the new state is the one you’re after then it could possibly be a misfire when battery updates and current state already is what you want
Happy new year guys!
I’m happy to let you know that the PR has been accepted for merging. There is a small problem with the cla check system that don’t seem to handle the amount of commits so I need to squash commits in order to get it through. Keep a look out for deconz in next release!
Thanks for all support!
/Robban
3 Likes
Good news! Thanks for your effort! 
I’ve pulled in the dev branch and added deconz:
Seems to work, it added the remotes I configured + ikea pir.
Bit confused what to do now, tho. Previously I had all the lights in HA by pointing to the deconz installation ip using the hue: component.
Do I delete the hue component config section? EDIT : Yes. It pulls the lights in, no worries.
THe only sensors I see atm are just the battery levels in the remotes.
1 Like
The remotes are only as events. You can see their I’d in the attributes of the battery. Check the documentation for examples of automations using remotes
Cheers but I can’t seem to find the docs, seems very new, the links in the py code give me 404’s 
Yes. Since it is still only on dev branch you have to go through the github repository
Will the new deconz component also work with the HUSBZB-1? If not, is there a current way to use Xiaomi door/temperature sensors with the HUSBZB-1?
Deconz is only for conbee and raspbee. There are other zigbee components that support your hardware.
1 Like