itavero / homebridge-z2m

Expose your Zigbee devices to HomeKit with ease, by integrating 🐝 Zigbee2MQTT with 🏠 Homebridge.
https://z2m.dev
Apache License 2.0
311 stars 49 forks source link

[Bug] Category of bridged devices is always `Other` #903

Open burmistrzak opened 2 months ago

burmistrzak commented 2 months ago

Is there an existing issue for this?

Describe the bug

I was inspecting individual devices exposed through homebridge-z2m, and noticed that all devices have the same HAP accessory category of Other.

This behavior can be attributed to the following line: https://github.com/itavero/homebridge-z2m/blob/cb71fd79e0890c9f6e8bf59214d27d6036e949d6/src/platform.ts#L598

Because we're not explicitly specifying an accessory category, a default category is used by Homebridge. I'm not sure how relevant this is for bridged devices, but it might help in cases like #869... 🤔

Related devices

No response

Related Devices

No response

Steps To Reproduce

No response

Expected behavior

No response

Device entry

No response

Status update

No response

Messages from this plugin

No response

This plugin

1.11.0-beta.6

Homebridge

1.7.0

Zigbee2MQTT

1.39.0-dev

Homebridge Config UI X (if applicable)

No response

itavero commented 2 months ago

Any feature request you are proposing?

burmistrzak commented 1 week ago

@itavero Sorry for only getting back to you now, been dealing with some health stuff. 😬 Absolutely not high priority, but maybe we can use the Z2M converter type as a hint for the correct accessory category?

itavero commented 1 week ago

maybe we can use the Z2M converter type as a hint for the correct accessory category?

Yes, but a single accessory can use multiple converters, so they should somehow have a priority between them.

burmistrzak commented 1 week ago

maybe we can use the Z2M converter type as a hint for the correct accessory category?

Yes, but a single accessory can use multiple converters, so they should somehow have a priority between them.

Correct. According to HAP spec, the primary service should be used here. So if we e.g. have a ceiling fan with a built-in light, Fan is the category to use. Using the first type of features we see for a given device seems like a good start, because converter devs can choose the order of features in exposes, IIRC.