Conversation
|
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. |
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? |
This PR builds off of #662 and replaces the
statedict with a strongly typed dataclass that absorbsinfo_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
statedict 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.