I’m throwing this out here because of @jo-me recent issues with unavailable devices.
Sensors don’t update when a non-state change has happened. deCONZ reports two different events; state and config. State contains the usual things with its state and other attributes. Config reports stuff such as reachable and battery. Config comes when unreachable happens or scheduled every 5-ish minutes.
At the moment the component doesn’t update the entities if event=config, since this gave “ghost” triggers of automations for previous testers and the solution was to not trigger sensor updates when a config event is received.
Interesting - so this explains why sensors don’t seem to get marked as unavailable in HA if they are unavailable in deconz, unless they are unavailable in deconz when HA starts. Do I have that right? My preference would be to know when a sensor is unreachable so that I could figure out why, rather than assume it’s available. Maybe we could look into why the automationa get ghost triggered?
Well the ghost thing is that config triggers an update to the entity without the state actually changing. So we know what the ghost is. You can check higher up in this thread about the thoughts to fix it.
Its an easy change.
In binary_sensor/deconz.py and sensor/deconz.py in the method def async_update_callback(self, reason): remove the line if reason['state']:
I’m not sure I understand completely, but I would expect that, for example. the temperature value remains the same if the sensor becomes unavailable. The timestamp shows whether the value might be stale or not. Otherwise, when the sensor returns to the network and sends the same value as before, it would be a entity value change for home assistant (20° => unavailable => 20°). That does not sound right, also in regards to automation triggers.
I have not seen battery status messages yet, but couldn’t these become separate entities just like _temperature, _humidity, e.g. _battery?
For Zwave devices, they have solved the availability question by showing a separate Zwave group that populates automatically with the detected devices and their status:
This is in addition to the values of the individual zwave devices.
So in order to find out why there is no value update for a certain device, you can look in that group to see whether the device is just sleeping or marked as dead.
That way real sensor values are not mixed with availability states and other meta information.
Makes the sensor values more type safe as well
I have not looked at your suggestion yet, but I just noticed that since my reboot yesterday, the sensor values have swapped. While temperature was reported from entity {sensor} and humidity from {sensor}_2, this is now the other way around thus making my entity name customization wrong and all other places where the enitity name was used like in the history graph:
If device is unavailable it is hass who changes state value to unavailable, the component just informs that the device is unavailable.
Yeah, depending on how it works to rename your devices I might need to add a suffix, please test this first. Might also have a discussion with deconz team about allowing renaming specific sensors of device in deconz. I’d prefer to not keep work arounds in the component for stuff that can be manually set.
Regarding battery; for devices reporting battery there is a attribute with the battery level available. On switches that doesn’t get exposed as entities there will be an additional battery entity created. This is how its expected to be.
Understood… I renamed them and its fine now.
Was easy to forget that they are in fact 2 sensors as this is not shown in the Phoscon app but only in the rest api. My other sensors were already named correctly because I added them before phoscon became available.
I’m still not decided on how I’d prefer this to be handled. I agree it would be best if the individual sensors could be renamed in deconz/Phoscon, but if that’s not forthcoming then my vote would be for your component to add suffixes, I think it’s less confusing and better for end users rather than having to call a HA service or figure out using Postman to rename sensors. That’s just my thought though, I always think making it easy for people is preferable (and then, if they don’t like the suffix, they are free to rename, but the component has done the right thing in the first place, which is give each sensor a unique entity Id).
Well if I where to add the suffix that wouldn’t be possible to override with personal preference from deconz. I’d prefer to keep it as straightforward as possible.
On a second note, did you try to remove those checks to see if you got a better behavior with unavailable attribute?
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?
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!
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.
