Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Streamline None attribute check for when ZHA entities are created #233

Open
TheJulianJES opened this issue Oct 11, 2024 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@TheJulianJES
Copy link
Contributor

The problem/background

Most entities in ZHA (e.g. sensors) are created even when the attribute cache doesn't contain a value for them yet, so if cluster.get(attr) returns None.
However, the classes listed below check if there's a None value in the attribute cache.
For most devices, this isn't an issue, as the values should be read during pairing (populating the attribute cache with an initial value). However, this has created issues in the past where some entities are only created after a HA restart if the value isn't read on pairing.

IMO, we only want the not None check for generic ZCL configuration entities that check all devices, like StartupOnOffSelectEntity (or would that already always fail as "unsupported" for unsupporting devices? At least newly-added generic (config) entities need this check, as an initial read -> unsupported or not, would only be done after ZHA started.)

Quirk v2 entities (and device-specific entities in ZHA) should always be created if the attribute definition exists on that cluster.
Or, there should be an option to allow/disallow None values in attribute cache.

Starting with zigpy/zha-device-handlers#3415, Tuya datapoints mapped to attributes on LocalDataClusters will return None + success, instead of "unsupported attribute". This allows most entities to be created during pairing (sensors).
I don't think there are any Tuya quirks that utilize switch/select/number configuration entities for LocalDataCluster attributes atm, but we should still make sure that v2 entities for those would be created, even if the value is None during pairing, only later being populated.

Additionally, even if we change our approach with Tuya devices at some point to have all attributes on the mfg and proxy reads from virtual ZCL clusters to the mfg cluster, the initial value might still be None during pairing (if attribute read -> datapoint reads aren't supported), thus causing some entities to not be created that check for it.

This is a low priority for now, but it's something we should eventually do and get right.

Classes with not None check for attribute cache value

These are the three classes with the not None required check:

ConfigurableAttributeSwitch (used by quirks v2 entities + used by device-specific entities in ZHA):

or cluster_handler.cluster.get(cls._attribute_name) is None

ZCLEnumSelectEntity (used by quirks v2 entities + used by device-specific entities in ZHA + generic ZCL entities):

or cluster_handler.cluster.get(cls._attribute_name) is None

NumberConfigurationEntity (used by quirks v2 entities + used by device-specific entities in ZHA + generic ZCL entities):

or cluster_handler.cluster.get(cls._attribute_name) is None

All other entity classes do not check this, like sensors and so on. They mostly only check if the attribute definition exists and if the attribute is supported, ignoring any possible values in the attribute cache.

@TheJulianJES TheJulianJES added the enhancement New feature or request label Oct 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant