Superfluous configured name characteristic for settings service

[torandreroland]

I feel the configured name characteristic for the settings service is at best superfluous and mostly confusing. My understanding is that this should mirror the name of the resource, but the characteristic of the settings service doesn't have a resource counterpart.

[ebaauw]

In case of the Device Settings service, the name is synced to the name of the main resource suffixed by Settings. Similar to e.g. the Battery service (which. when based on config/battery doesn't have a resource of its own either).

[torandreroland]

I have a thermostat that is exposed as one sensor resource in the deconz api. This is represented as an accessory in HomeKit with three services:

• Accessory Information (HomeKit native)
• Thermostat (HomeKit native)
• Settings (Custom)

Both the thermostat and settings services have a configured name charactestic, but only the characterstic of the thermostat service is actually linked to the name of the sensor resource in the deconz api.

Below is JSON-representation of the sensor from the API:

{ "config": { "heatsetpoint": 2200, "locked": false, "mode": "heat", "offset": 0, "on": true, "reachable": true }, "etag": "1c75a7a1c86185f2b6a9a09a4d107d7c", "lastannounced": null, "lastseen": "2022-11-21T17:32Z", "manufacturername": "ELKO", "modelid": "Super TR", "name": "Downstairs Bathroom Floor Heatin", "state": { "lastupdated": "2022-11-21T17:32:35.076", "on": false, "temperature": 2220 }, "type": "ZHAThermostat", "uniqueid": "00:0d:6f:00:0f:55:6f:a3-01-0201" }

[ebaauw]

They're all linked. When you change the name on the REST resource in deCONZ, Homebridge deCONZ updates the names of all three services. When you change the name of the (primary) Thermostat service, Homebridge deCONZ updates the name of the resource, and then updates the names of the Accessory Information and Device Settings services (because the name on the resource has changed). When you change the name of the Device Settings service, Homebridge deCONZ does nothing. I don't know of any HomeKit app that allows you to change the name of the Accessory Information service.

[torandreroland]

"When you change the name of the Device Settings service, Homebridge deCONZ does nothing": I think this is my point.

But my opening comment here wasn't spot on as you point out, since one device may be:

• represented with multiple resources in the REST API which can be combined into one HomeKit-service
• represented with one resource in the API which may be split into multiple HomeKit-services (your example of battery-services)

However I still hold that Device Settings service shouldn't have a configured name characteristic. Potentially one can argue that it's the only service which should have a configured name characteristic, omitting it from the other services to bypass the cardinality aspects described in the previous paragraph.

This is obviously nitpicking. I discovered this while troubleshooting why my naming of one services was constantly changing which resulted in issue 83. In that troubleshooting I noticed one configured name characteristic that could be changed and was synced to Deconz, while another one (belonging to the Device Settings service) was dead.

[ebaauw]

This is obviously nitpicking.

OK, so we can close this issue?

However I still hold that Device Settings service shouldn't have a configured name characteristic. Potentially one can argue that it's the only service which should have a configured name characteristic, omitting it from the other services to bypass the cardinality aspects described in the previous paragraph.

I'm planning to ditch the Device Settings service, once I'll have figured out how to do dynamic settings from the Homebridge UI.

Each service should have Configured Name. Since iOS 16, HomeKit screws up the initialisation of service names, and uses the accessory name for each service. This sucks for accessories with mulitple services of the same type, as you can no longer distinguish these in Home or another HomeKit app. By adding Configured Name, HomeKit on iOS 16 links the service name to its value, making it settable from the accessory (i.c. Homebridge plugin).

Whether or not you want to update Configured Name when the resource name changes, or whether or not you want to update resource name when user changes the service name (which changes Configured Name), is a different question, see #83.

But my opening comment here wasn't spot on as you point out, since one device may be:

• represented with multiple resources in the REST API which can be combined into one HomeKit-service
• represented with one resource in the API which may be split into multiple HomeKit-services (your example of battery-services)

In principle, a Zigbee device is exposed as a single HomeKit accessory, with a HomeKit service per REST API resource. As you indicate, there are some exceptions to this principle:

• Wireless switches have Label service and a Stateless Programmable Switch service per button, independent of how many ZHASwitch and/or ZHARelativeRotary resources they use;
• ZHAConsumption and ZHAPower resources are currently exposed on the primary Lightbulb, Outlet, or Switch service, to accommodate Eve history. That might change, however; I got myself an Eve Energy Strip on Black Friday, and it exposes three Outlet services and a custom service for the consumption and power. I need to test if I Eve accepts the same custom service on an accessory with a single Outlet, Switch, or Lightbulb service;
• As you mentioned, config/battery is currently exposed as a separate service. In deCONZ APIv2, battery will be exposed as a separate subdevice (cf. the ZHABattery for window covering devices, that are exposed as lights resource);
• ZHAAirPurifier is exposed as two services, Air Purifier and Filter Maintenance, in line with HomeKit standard services.

In Homebridge Hue, you can use resourcelinks to combine multiple CLIP resources into a single MultiClip accessory or to split a device into multiple accessories (to accommodate wired in-wall switches with wires to ceiling points in different rooms). I want to offer similar features to Homebridge deCONZ as well (once I'll have sorted out the settings).

[torandreroland]

Thank you for the extensive answer. Yes, you can close this issue.