Observations as of 0.13 about homebridge-deconz HOT 4 CLOSED

Thanks for your feedback. I'm still trying to find the best way of providing the settings to expose devices.

Currently, Expose Lights, Expose Sensors, and Expose Groups are more like auto-expose settings. When set, all corresponding devices are exposed, with a Device Settings service to un-expose each accessory individually. When an accessory is un-exposed, the Device Settings service "moves" to the Gateway accessory, so you can re-expose it. When un-selecting Expose Lights, etc, the accessories continue to be exposed, but the Device Settings services on the Gateway accessory are removed. Also, new devices won't be exposed automatically. When later re-selecting Expose Lights, ..., the previously blacklisted devices remain blacklisted, but the Device Settings service re-appears under the Gateway accessory, and accessories for new devices will be added.

The Expose setting on the gateway is like a hard reset: de-selecting it clears all configuration settings for that gateway, incl. the blacklist, and even the API key. When re-selecting Expose, the gateway is treated like a new gateway, and a new API key needs to be obtained.

By un-exposing (deselecting Expose on the Device Settings service of the device accessory) and re-exposing (selecting Expose on the Device Settings service in the gateway accessory), the accessory is reset. That should refresh the names. No need to remove them from deCONZ. This also clears the Eve history for the accessory.

As I said: I'm still struggling with the best way to deal with this. I thought about exposing all devices by default, but on large installations, you'd run into the 149 accessories per bridge limit. I thought about not exposing any device by default, but you'd run into the 99 services per accessory limit. I thought about exposing the Device Settings on the gateway accessory, regardless of whether the device is blacklisted, but again: the 99 services per accessory limit. Maybe I could provide a way to scroll through the devices. In that case, I'd have a single Configure characteristic to expose the Device Settings services on the gateway, like for 50 devices at a time.
I also like to be able to change how to expose a device (e.g. from Lightbulb to Outlet), without removing the accessory from HomeKit. Of course, you'd lose the scenes and automations (as the characteristics now belong to a different service), but you'd keep the room assignment.

I'm also exploring the possibility to do these settings from the Homebridge UI. The challenge is that it runs detached from Homebridge, so I need a mechanism to apply the changed settings without having to restart Homebridge. Of course, that would mean that the plugin is usable only from a standard Homebridge installation, with the UI. Then again, now you need Eve, or another HomeKit app, and to be the owner of the HomeKit home, to be able to do the configuration.

from homebridge-deconz.

I think I understand better how the various EXPOSE options work now, or at least can refer back to this message to refresh!

I think a configuration method through Homebridge sounds tempting. My thinking is:

• We already have to have Homebridge, so it isn't an additional app (like Eve) that we might not already be using. I'm sure some people are using it anyway, but certainly not all.
• No 'Owner of the Home' requirement.
• Homebridge makes it so easy to put any plugin into a Child Bridge that even if you did have to restart Homebridge, you'd only be restarting the Child Bridge not the entire Homebridge. (I suspect that psychologically this is a very undesirable option for you, since one of the biggest goals of the new plugin was to be dynamic and not require a restart. Although it would solve the problem of accessories popping into HomeKit before they'd been fully renamed in Phoscon.)

You mentioned that doing configuration through the Homebridge UI requires a standard Homebridge installation. I wonder how many non-standard installations would be likely for this plugin that would conflict with that. Or if a separate web-based configuration page on its own port, outside of Homebridge UI, might be an option that would work with any type of Homebridge installation. Plus, it might be a way to quickly and easily rename newly added devices (Phoscon is cumbersome on mobile) and an easily clickable "refresh" button could then update the changed name or other setting into HomeKit without needing to go anywhere else to make it happen, and while retaining dynamic loading.

from homebridge-deconz.

I started doing Homebridge plugins, so I wouldn’t have to deal with user interfaces. Creating a separate web-based UI is way too much for me.

Your expose before renaming issue would also be solved by not automatically exposing new devices, but requiring a manual action.

Names of accessories and services are accessible only to HomeKit apps; it’s technically not possible for a Homebridge plugin (or any accessory) to change these. It can only un-expose and re-expose the accessory, so HomeKit re-initialises the names, but loses the configuration.

I don’t collect any statistics, but judging by the issues I get on GitHub, and the questions on Discord, there are more non-standard installations out there than installations without a proper HomeKit app.

BTW, historically, Apple’s Home is the additional app. HomeKit started out as a framework, where each accessory vendor would deliver their own app. When I started Homebridge Hue, Eve and Home+ were already there. Apple’s Home app was introduced later, and it still doesn’t support all of HomeKit.

from homebridge-deconz.

Understood.

from homebridge-deconz.