-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
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
Refactor group state logic #116318
Refactor group state logic #116318
Conversation
b26d725
to
4c6339d
Compare
4c6339d
to
c9d6023
Compare
|
Pushing this to production now |
Tested on production. Everything seems the same and working |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jbouwh 👍
As mentioned on discord I would still like to see a test for vacuum
and also add on for lock
later on it's PR
Thanks all for reviewing! |
Proposed change
This PR replaces #116116, which was based on #115866, but this change was reverted.
Needs #116317 to be merged first.Needed by #111968 (Add lock
open
state).Refactors the way group states are processed. There are no functional changes.
With #116317
on
states were passed as a tuple, allowing to assign the first state as the defaulton
state.To allow additional
on
states that are also used for other platforms we need togroup
the on/off state state pairs to be able to check for a single use of a state pair.To handle groups of groups some additional logic was added, as we need to know if a group uses single state group. E.g. groups of
locks
usinglock
andunlocked
. The default state group ison
/off
The logic as it is expected to work
Multipe domains with a single shared
on
/off
state can be combined as they are have the same group state type, e.g.:person
anddevice_tracker
:home
andnot_home
switch
andlight
:ON
andOFF
In case a domain has multiple
on
oroff
states we use the defaulton
state, e.g.:lock
will haveunlocked
andopen
asON
state. The groupon
state will always beunlocked
So each group state type has its own consistent ON and OFF state.
If entities of different group state types are combined, the group state default to
on
/off
Example:
In case a
lock
entities are combined with other domain entities, e.g.cover
, then the group status will beon
oroff
.Some group state types when entities of multiple domains are combined:
on
/off
:switch
,light
,vacuum
,siren
,climate
etc.zone
:person
,device_tracker
etc.open
/closed:
cover`unlocked
/locked
:lock
. Alsoopen
is anON
state, but in a group the defaultON
state (unlocked
) will be used.Groups will always be consistent on and off state, so:
lock
andcover
are combined, and the group isON
, the status will beON
, andOFF
if the group isOFF
person
anddevice_tracker
are combined, and the group isON
, the status will behome
andnot_home
if the group isOFF
Type of change
Additional information
Checklist
ruff format homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
..coveragerc
.To help with the load of incoming pull requests: