Skip to content

[RFC] Merge state with info_object#663

Draft
puddly wants to merge 16 commits intozigpy:devfrom
puddly:puddly/zha-entity-state-consolidation
Draft

[RFC] Merge state with info_object#663
puddly wants to merge 16 commits intozigpy:devfrom
puddly:puddly/zha-entity-state-consolidation

Conversation

@puddly
Copy link
Contributor

@puddly puddly commented Feb 19, 2026

This PR builds off of #662 and replaces the state dict with a strongly typed dataclass that absorbs info_object.

For stronger typing and to support the client/server architecture split in the future, we benefit from having more centralized state for entities. This will allow us to send batched state updates to the client instead of the client being notified of a general "update" and then reaching for the state dict of the ZHA entity.

One consequence of this change is that practically all entity descriptors are part of the state, including availability, the device class, and so on. This in theory will give us the ability to react to changes to these fundamental descriptors on the Home Assistant side.

@dmulcahey
Copy link
Contributor

Love the idea. I think at one point I was doing something similar in one of the web socket branches. What is the need for the suppression though? Do we need to rework discovery? something like go through init of the device, apply quirk and maybe reinit, then entity discovery then configuration to deal with some sort of multi pass issue? I am making an assumption that this is somehow causing the need to suppress stuff.

@puddly
Copy link
Contributor Author

puddly commented Feb 20, 2026

What is the need for the suppression though? Do we need to rework discovery?

A few tests were failing because we emitted an event unnecessarily while computing the primary entity during init. The event suppression just prevents that one event from leaking during initialization.

@dmulcahey
Copy link
Contributor

What is the need for the suppression though? Do we need to rework discovery?

A few tests were failing because we emitted an event unnecessarily while computing the primary entity during init. The event suppression just prevents that one event from leaking during initialization.

ok, but is this a side effect of a lifecycle that should be altered? Meaning does it make more sense to add event suppression or does it make more sense to alter the device config / init + entity discovery lifecycle to remove that from even being a possibility? Like, is there some way we can single pass through the config / init / discovery phases so that entities can never fire anything until this is all determined correctly?

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