Per device state about zigbee2mqtt HOT 20 CLOSED

Just getting back to the original issue:

• We can have multiple solutions device dependent, but in the end I guess everyone can agree on the need to publish availability of the sensor

from zigbee2mqtt.

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. )

from zigbee2mqtt.

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?

from zigbee2mqtt.

@ciotlosm that's a stop gap, clean integration should not rely on automations

from zigbee2mqtt.

@dgomes Yes, that would be best, as there is already support for this here and here

from zigbee2mqtt.

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.

from zigbee2mqtt.

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.

from zigbee2mqtt.

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.

from zigbee2mqtt.

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.

from zigbee2mqtt.

you could ping every day, that would be better then no event and limits the impact

from zigbee2mqtt.

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.

from zigbee2mqtt.

@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

from zigbee2mqtt.

@dgomes maybe just use automations in Home Assistant to validate when reports are no longer incoming (over a threshold). What do you think?

from zigbee2mqtt.

Not every device sends periodic updates.

from zigbee2mqtt.

Periodic ping only if a battery attribute not in device entry in dB?

from zigbee2mqtt.

Even if you have batteries the sensor can get out of range

from zigbee2mqtt.

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.

from zigbee2mqtt.

yes please. very important feature even just reported its online offline status when the device suddenly lost the connection. thanks

from zigbee2mqtt.

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.

from zigbee2mqtt.

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.

from zigbee2mqtt.