Programmable Switch Names in Home app about homebridge-homeconnect

[rayr007]

Log entries of fridge door open/close:

[1/5/2021, 10:36:15 AM] [HomeConnect] [Fridge freezer] Event STATUS (1 item)
[1/5/2021, 10:36:15 AM] [HomeConnect] [Fridge freezer] BSH.Common.Status.DoorState=BSH.Common.EnumType.DoorState.Open (1 listeners)
[1/5/2021, 10:36:15 AM] [HomeConnect] [Fridge freezer] Door open
[1/5/2021, 10:36:30 AM] [HomeConnect] [Fridge freezer] Event STATUS (1 item)
[1/5/2021, 10:36:30 AM] [HomeConnect] [Fridge freezer] BSH.Common.Status.DoorState=BSH.Common.EnumType.DoorState.Closed (1 listeners)
[1/5/2021, 10:36:30 AM] [HomeConnect] [Fridge freezer] Door closed

[thoukydides]

On my fridge, there are programmable switches created. In the Home app, they show up as "BUTTON 1", "BUTTON 2", "BUTTON 3". However, if I use the Eve app, it properly shows me the programmable switch names of "Freezer Door Alarm", "Refrigerator Door Alarm", "Freezer Temperature Alarm". Is there more than one attribute on the programmable switches that need to be set so that the Home app also shows the proper names? Or is this a bug in the Home App?

This is how Apple designed the Home app to work. It is not a bug, and there is nothing that can be done about it unless Apple choose to change their design. I note this limitation on https://github.com/thoukydides/homebridge-homeconnect/wiki/HomeKit-Apps.

Also (feature request): I see in the logs when the Door is open and then when the Door is closed. Can these be mapped to virtual programmable switches so I can attach automation rules to them? Rather than waiting for the "Refrigerator Door Alarm" to go off?

There is a Current Door State characteristic that provides this status and that can be used to trigger automations, as described on https://github.com/thoukydides/homebridge-homeconnect/wiki/HomeKit-Mapping. You should be able to create a Rule in the Even app that uses it.

[thoukydides]

It is worth noting, however, that on a FridgeFreezer appliance the Home Connect API does not distinguish between the fridge door and the freezer door. The Current Door State indicates the state of whichever changed most recently. There's nothing that I can do about that - it is an API limitation.

[rayr007]

Thanks Alexander.

• ok job on Homekit Apple but man they need to improve the UI
• ok job on HomeConnect but they sure need improvements there too.... (other example, my hood reports 3 fan speeds and no intensive levels when it does in fact have an intensive level)
• fantastic job on this plugin. Too bad you're stuck between mediocre... 😜

[thoukydides]

Thank you for your kind comments @rayr007.

However, I think the HomeKit / Home app criticism is a little unfair. Whilst the HomeKit framework is extensible, allowing creation of arbitrary new Accessory, Service, and Characteristic types, it is not really possible to provide a good user experience unless the app understands those types. Apple have quite reasonably picked the device types that they consider are most useful to control via Siri and defined appropriate Services and Characteristics for them, and then built the relevant semantics into the Home app and Siri. For those standard device types this gives a pretty good user experience.

The problem is that other device types (such as the appliances bridged by this plugin) are not a good match to those standard Services and Characteristics. Some third-party HomeKit apps do a best-effort job of supporting custom Services and Characteristics, but the Home app does not even try. In some cases the Home app allows known Characteristics to be included in Services that would not normally have them, although that needs to be done with care since it can break Siri control. Hardware manufacturers with their own HomeKit apps (such as Elgato with their Even app) can add custom Services and Characteristics which are only supported by their own app. Eve also supports some custom Services and Characteristics defined by some of the major Homebridge plugins. However, most Homebridge plugins have to restrict themselves to mapping functionality to the closest standard Services and Characteristics. In most cases that just means having a large number of Switch Services.

Apple are gradually expanding the range of device types for which they define a proper object model. As that happens, and Homebridge plugins are updated to use the standard types, the UI will naturally improve.

The Home Connect API is a different story. The API is essentially defined by the company manufacturing the appliances (albeit under a variety of different brand names). They don't have a good excuse for such a poor mapping between the appliance features and the API. There are also strange inconsistencies between which features are exposed by their own Home Connect app, their IFTTT integration, and the public Home Connect API. They also seem to be unable to run a reliable server infrastructure, even though it is hosted on AWS.