Skip to content

Comments

Add quirks v2 siren entity based on ZCLEnumMetadata#668

Draft
TheJulianJES wants to merge 10 commits intozigpy:devfrom
TheJulianJES:tjj/siren_v2_quirk_enum
Draft

Add quirks v2 siren entity based on ZCLEnumMetadata#668
TheJulianJES wants to merge 10 commits intozigpy:devfrom
TheJulianJES:tjj/siren_v2_quirk_enum

Conversation

@TheJulianJES
Copy link
Contributor

DRAFT.

Based on:

Proposed change

This allows quirks v2 entities to provide entity_platform=EntityPlatform.SIREN for .enum() entities to create a siren entity on the HA side, instead of a select entity.

Entry 0 from enum will be the off-state.
Entry 1 will be the default tone if enabled without one explicitly selected (similar to ZCL siren that hardcodes it).
Remaining entries will also be exposed as additional tones for the siren entity in HA.

Additional information

This came up as zigpy/zha-device-handlers#4637 added a select entity with "Stop" and two different tones for a smoke sensor with a siren. ZCLEnumMetadata already works good enough to also allow us to create siren entities with it, so that's what this PR implements. IMO, having entry 0 in the enum be the OFF state for the siren entity is fine.

Creating separate SirenMetadata would confuse things more (for the few devices that will ever use that..), as we'd potentially need to support on/off attribute writes with no tones, but also multiple tones, and maybe even custom commands for siren entities at some point? (which we don't, yet)

Reusing existing SwitchMetadata and ZCLEnumMetadata works well enough and is somewhat consistent with the existing implementation of .enum(entity_platform=EntityPlatform.SENSOR). I don't think we should overcomplicate sirens at this point.

Future

When we deal with select entities (based on enum classes) getting translations, we should (naturally) also replicate that logic to the siren class. IMO, it doesn't make sense adding that now, as the ZCL siren completely hardcodes the static values still, select/enum entities do not support translations at all yet, and we don't have nice scripts to auto-generate those parts for translations. It should be easy to implement it here when we do everything else (since it's all enums / state translations).

@dmulcahey
Copy link
Contributor

see comment: #667 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants