Honor zigbee2mqtt device availability about homebridge-z2m HOT 25 CLOSED

This is not in plugin at the moment. First thing on my list in this area is looking at the overall zigbee2mqtt bridge state.
After that I'll have a mechanism to let the service handlers know if an accessory is online or not, which can probably also be used for this.

The "annoying" thing is that, as far as I understood, there's no way in Homebridge for a plugin to indicate this accessory is offline. It seems that the only thing you can do is return an error when characteristics are get/set, so it's a bit tedious.

The plugin does poll for the state in terms of what is published to the device topic, but it only does this on startup and if it hasn't received any update for 4 hours or so.
This will however not update the availability of the accessory and this will only work for accessories that expose properties that can be retrieved with a get command.
Most battery devices do not support this.

from homebridge-z2m.

It is possible to reproduce the No Response behavior, I believe.
It just requires some more code and thought 😅

from homebridge-z2m.

Short update / "note to self": after having another look at the homebridge/HAP-NodeJS sources, I think it might be possible to use updateValue to make HAP aware of the fact that an accessory is not reachable (see this interface)

However, this probably still needs to be handled by the service handlers/converters, as they know which characteristics are the "main" characteristic for their service.

The service handler should probably call characteristic.updateValue(new HapStatusError(HAPStatus.SERVICE_COMMUNICATION_FAILURE)) when the device (or Zigbee2MQTT itself) become unreachable and revert this by calling characteristic.updateValue(new HapStatusError(HAPStatus.SUCCESS)).
Even though this still sets this.status to a non-null value (in PlatformAccessory), I think this should work as the handleGetRequest function only checks this.statusCode.
Calling updateValue this way, should also leave this.value (in PlatformAccessory) untouched, meaning that it will return the "old" value again once it gets updated or once a new value is received.

from homebridge-z2m.

I'm actually going to keep messing with this before I say it doesn't work, but I've not yet seen it proliferate all the way through to homekit. Since I know that the functionality is supported through the zigbee2mqtt layer, the next unknown is homebridge-z2m, which is why I'm posting it here.

In Homebridge logs, I never see anything show up other than publish requests to a given topic, so I'm making an assumption that it's not actively polling device state.

from homebridge-z2m.

Gotcha, thanks for the clarification!

From a place of ignorance, would a workaround here be for homebridge-z2m to observe the ping state from zigbee2mqtt for a given device, and if that ping state is 'offline', then basically publish a state of "off" to that same device? It would then show as "Offline" in Homekit, which is actually true, and the message could be published roughly at the same time frame specified in the availability_timeout setting for zigbee2mqtt.

Of course, the best way would be for Homekit to display "No Response" or something similar, but if there's no way to duplicate that, I'd think showing "Offline" would be a close runner-up.

This way, you wouldn't necessarily see an error, but you'd see that the device keeps going offline in Homekit when it's not connected to power or is otherwise unavailable.

Let me know if that makes sense? It may not be doable, but I'd assume subscribing to the correct "availability" topic for a given device would produce an online or offline hook.

from homebridge-z2m.

I've started working on the implementation today.
It seems I have a working solution, however I still need to fix/update the automated tests.

I'm also still thinking about an easier way to provide this functionality. Currently you have to think about this in every ServiceHandler implementation (a.k.a. whenever you configure a HomeKit characteristic). I'll see if I can come up with a way that is more generic. Perhaps just iterating over all services and characteristics after all the ServiceHandlers have been created.

from homebridge-z2m.

I appreciate it! I think it would go a long way for usability in general of the plugin. By far one of the least effort Homebridge plugins I've found to date. I'll pull the :next branch when its ready for test for sure!

from homebridge-z2m.

Note to self: I should also verify that availability_timeout != 0 in the zigbee2mqtt configuration (which is also published on zigbee2mqtt/bridge/info and maybe also consider the availability_passlist and availability_blocklist when processing the incoming MQTT messages.

The reason for this is that old MQTT topics/messages may stick around if the feature is disabled in zigbee2mqtt (as I've just noticed).

from homebridge-z2m.

I saw some more questions from other plugin developers on the Homebridge Discord server.
Something tells me that there should probably be an API added in Homebridge to get an easy and unified way for marking devices as unavailable instead of adding additional logic to each characteristic.
I'll think on this a bit more and, once I find some time to do so, dive into the Homebridge sources to write a feature proposal for Homebridge.

from homebridge-z2m.

Just wanted to let you know, this issue is still on my mind, but I haven't found the time yet to propose a supporting feature/API for this to the Homebridge community.

from homebridge-z2m.

Perhaps it is possible to use the Reachable characteristic for this. I think it used to be integrated in HAP-NodeJS, but I got removed at some point (not sure why).
It's at least worth the experiment ;)

from homebridge-z2m.

The Bridging State service and Reachable characteristic no longer work with recent versions of iOS unfortunately.

I think I'll need to add a generic way of adding a handler to all characteristics of a service to deal with checking the online/offline state.

from homebridge-z2m.

hi, are there any updates on this topic? ;)

from homebridge-z2m.

No updates from my side unfortunately.

from homebridge-z2m.

It appears that this issue did not have an update in quite some time. Please check if you can provide any additional information to help resolve this issue. If there isn't any activity in the next two weeks, this issue will be closed automatically. Thank you for your contributions!

from homebridge-z2m.

This would be the missing link in my extensive zigbee setup - any update from your side?

from homebridge-z2m.

No, but if someone where to provide a clean solution in a PR for reporting errors from all characteristics when a device is not available, I'd definitely look at it.

from homebridge-z2m.

I think it may be possible to add something in the Zigbee2mqttAccessory class to detect when characteristics are added (perhaps by using the SERVICE_CONFIGURATION_CHANGE event from Service) and then add a new/overridden get callback.
Not sure if that would work if the converter would also want to add a get callback, but so far this is not being used as far as I know.

from homebridge-z2m.

Short update: tried to implement based on the info mentioned above. Marking them as unavailable a.k.a. not responding works, but I can't easily make them available again.
Setting the error to SUCCESS does not seem to work correctly. I might try to somehow get the old value of the characteristic and set that again to clear the value, but I might also just be missing something else or testing it wrong.

In other words, some more investigation is needed 😉

from homebridge-z2m.

Resending the last value using sendEventNotification does seem to work, but I still have to reopen the Home.app for it to show the devices as responding again. I think that might be acceptable though.

from homebridge-z2m.

I think many accessories behave like this, it is possible that, this is Home.app at all :)

from homebridge-z2m.

Just released v1.10.0 to homebridge-z2m@next which includes this feature. Because there were quite some internal changes, I haven't pushed it to latest yet. So far it seems to be working fine on my setup, but if you run into any issues, please do let me know.

from homebridge-z2m.

hey, not sure if this is the breaking change but it seems to be one of the candidates. Just updated the plugin from v1.9.2 where everything was looking good to v1.10.0 and suddenly started to see loads of errors like

[12/15/2022, 3:22:39 PM] [zigbee2mqtt] Received devices...
[12/15/2022, 3:22:39 PM] [zigbee2mqtt] Update "error" status for characteristics of <accessory_name_here> to 0
[12/15/2022, 3:22:39 PM] [zigbee2mqtt] Update "error" status for characteristics of <accessory_name_here> to 0
[12/15/2022, 3:22:39 PM] [zigbee2mqtt] Update "error" status for characteristics of <accessory_name_here> to 0
[12/15/2022, 3:22:39 PM] [zigbee2mqtt] Update "error" status for characteristics of <accessory_name_here> to 0
[12/15/2022, 3:22:39 PM] [zigbee2mqtt] Update "error" status for characteristics of <accessory_name_here> to 0
[12/15/2022, 3:22:39 PM] [zigbee2mqtt] Update "error" status for characteristics of <accessory_name_here> to 0
[12/15/2022, 3:22:39 PM] [zigbee2mqtt] Update "error" status for characteristics of <accessory_name_here> to 0
[12/15/2022, 3:22:39 PM] [zigbee2mqtt] Update "error" status for characteristics of <accessory_name_here> to 0
[12/15/2022, 3:22:39 PM] [zigbee2mqtt] Update "error" status for characteristics of <accessory_name_here> to 0

in the logs and mostly all of the devices controller by this plugin gone into No response status. I also tried to add "ignore_availability": true, as a default as well as for every accessory but nothing changed :(

from homebridge-z2m.

@bulivlad This message is not an error actually. Maybe the phrasing is a bit weird. It is indeed to trigger the "No response" behavior in the HomeKit. (Should also only be in the debug logs.)

Setting the "error" to 0 actually means "Success" a.k.a. available, but it's weird that ignore_availability does not seem to work for you (I believe it then still sets the error to 0).

A few additional questions though:
Do you have the Availability feature in Zigbee2MQTT turned on or not?
Was Zigbee2MQTT itself online?

Perhaps you can create a bug report and also include a bit more information on your Zigbee2MQTT setup, the configurations you've tried and the answers to these questions?

from homebridge-z2m.

@itavero opened one here. I think I added all the details in there but please let me know if you need any other details on that

from homebridge-z2m.