Feature Request: Make devices show as not responding, when the device is in fact not reachable

[kruegermedia]

Hello Y'all, I've stumbled upon an issue with devices from a third party provider, for example deCONZ. The Devices expose a "reachable" datapoint, but when exposed to Homekit, this status is ignored and the device - for example a lamp - is still shown as active and values can even be adjusted.

It seems to be the case, as pointed out in this article, that HomeKit is determining locally wether a device is reachable or not. So as long as the bridge - in this case yahka / io.Broker is responding anyhow the device will remain as available.

Therefore I would enjoy a lot the feature of "beeing able to consider the reachable option within yahka and not responding to homekit requests as long as the status is false" as a configurable option for each device.

Thanks a lot for considering and kind regards Benjamin

[Videonisse]

This is an interesting and useful feature request! The question is how Yahka will learn about the "reachable" datapoint for the particular device?

As I understand it, Yahka is not aware of any ioBroker Devices and only map datapoints (or scripts) to Homekit Characteristics. The mentioned article describes a workaround within the third-party Homebridge Hue plugin, so it's not directly available within HAP-NodeJS.

I assume Yahka could be extended with a field "noResponse" on the Device properties (Accessory) that the user optionally maps to the ioBroker datapoint for the Device, and handle a field value of "false" like the Homebridge Hue plugin, see below.

Source: https://github.com/ebaauw/homebridge-hue/wiki/No-Response#no-response "No Response To change the default behaviour, set noResponse, in config.json. When reachable becomes false and noResponse is set, Homebridge Hue, in addition to setting Status Fault:

Returns an error response on a HomeKit read of On or Active; Returns an error response on a HomeKit write for any state attribute, but still sends the corresponding request to the Hue bridge or deCONZ gateway."

[kruegermedia]

Thanks for the fast intervention :)

So far I have worked with different sensors from aqara, xiaomi, ... and lamps from Ikea, Philips, as well as switches from these manufacturers and until this point all of them exposed a boolean wether they are reachable or not.

So I imagined in the first moment a datafield within the service header:

In the known yahka style you would be able to choose between state, multistate, script, const, etc. for the beloved customizability. It would expect a boolean and api calls - if set to not reachable - would be rejected.

[Videonisse]

I don't think it would be appropriate to have this on the service level, it belongs to the Accessory, ie the Device level in Yahka.

(I believe each Accessory has two mandatory service types, "General State" and "Accessory Identification") Source: https://developer.apple.com/documentation/homekit/hmcharacteristic/characteristic_types?language=objc

[dklinger]

+1 Bei Zigbee-Devices im Altbau wäre dies sehr hilfreich.

[Her0m]

+1 I am also very interested in this function. I have a few devices that sometimes go offline. Unfortunately, I can't see the status in HomeKit.