We have a topic with the state of the gateway but we miss a topic per device with the state of the device.
This is important to know if a device has become disconnected/powerer_off/removed
This is a nice addition indeed. However we need to check if these events are send by zigbee-shepherd or if we need to ping to check if the device is still alive.
We could use the internal Functions:
https://github.com/zigbeer/zigbee-shepherd/wiki
*devIncoming (Fired when there is a ZigBee Device incoming to the network. )
*devLeaving (Fired when there is a ZigBee Device leaving the network. )
Or Simple with
*devStatus (Fired when there is a ZigBee Device going online or going offline. )
The devStatus event is not fired when for e.g. the battery is pulled out of the sensor. (not even after a few hours). Perhaps some pinging algorithm should be implemented however I have concerns that this would affect the battery life of the sensors.
you could ping every day, that would be better then no event and limits the impact
Pinging should not be considered as an option. Maybe for some very small set of users that agree to drain battery.
I think if you get battery at least once a day you should be fine. You could have a WARN around 5%. Considering the battery should last around 2 years for most Xiaomi sensors the threshold should be enough to give you time to change.
@Koenkk
The devStatus event is not fired when for e.g. the battery is pulled out of the sensor. (not even after a few hours). Perhaps some pinging algorithm should be implemented however I have concerns that this would affect the battery life of the sensors.
Do you check via the .dump Api ??
https://github.com/zigbeer/zigbee-shepherd/wiki#dump
@dgomes maybe just use automations in Home Assistant to validate when reports are no longer incoming (over a threshold). What do you think?
@ciotlosm that's a stop gap, clean integration should not rely on automations
How about a configuration per device with the maximum interval of no messages. Only ping it when it goes beyond the interval, and if it doesn't answer to ping and interval is passed, consider it unavailable.
Not every device sends periodic updates.
Periodic ping only if a battery attribute not in device entry in dB?
Even if you have batteries the sensor can get out of range
If it has a battery you could avoid pinging but define a time after which the sensor would be considered unreachable as it should have sent at least the battery update. Would that work?
Just getting back to the original issue:
I found this behavior with light switch, smart plug (use ac power). When device out off range or offline, send mqtt on or off command never success, so we may add an topic for the device available (switch, plug) and ping from zigbee2mqtt, if can send available payload then device online.
Very important feature... my tests with reset xiaomi sensor shows that zigbee2mqtt continues report thats all ok, and more over - translates old data on each zigbee2mqtt restart and home assistant thinks that time of this data = time of restarts zigbee2mqtt.
It's making useless water leak or fire sensors at all if one of them will lose connection or zero battery.
yes please. very important feature even just reported its online offline status when the device suddenly lost the connection. thanks
Today case:
Home Assistant + Zigbee2mqtt = uptime 4 days 8 hours
I saw that temperature/humidity/pressure sensor not updates data 20 hours (horizontal lines with same values on graphics). Going to Zigbee2mqtt log (journalctl -u zigbee2mqtt@name -f) and saw that all sensors except temperature/humidity/pressure have last reports.
What give to us restarting Zigbee2mqtt demon? It's once sending to Home Assistant old data with new (actual time) and thats all:
Sep 19 00:19:45 hass npm[7506]: zigbee2mqtt:info 2018-9-19 00:19:45 MQTT publish, topic: 'zigbee2mqtt/cabinet_thp', payload: '{"temperature":23.33,"linkquality":15,"humidity":40.14,"pressure":993,"battery":"91.67","voltage":2975}'
so in Home Assistant last time of update values will be updated (for what with fake/old data ? :) ).
What must to be? Befor restart demon Zigbee2mqtt must report no values and sensor's connection lost I think. After restart demon - sensor's connection lost and of cause no values. It's simple solution by timeouts. About possibility for some sensors by some vendors to recall connection - it's another talk of cause. In my case it's xiaomi sensor and I press reset button and all data updates immediately. If connection lost will be reported by timeout to smart home, we can create automation with alert for example, and sensor will be reconnected manual asap without 20 hours of losing data.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
Just getting back to the original issue: