flan/advanced-camera-card
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: Clear the initialized condition state when the card is not usable (#2646)

Browse Source 
The `initialized` state (used in conditions/triggers) was written once
and never cleared, so it meant "has this card ever been initialized"
while everything reading it took it as "is this card usable now". Home
Assistant takes a card off the page and puts it back whenever its
dashboard tab is left and returned to, so the card initialized again
while the state claimed it was initialized throughout: `trigger:
initialized` fired once per card rather than once per startup, and
automations were dropped in between.

The card lifecycle is now an explicit state machine (`SessionManager`),
the only writer of `initialized`, which separates a card that is
starting up from one initializing part of itself again while it runs. A
new `ever` parameter (conditions/triggers) selects the old latched
behaviour.

`remote_control` uses that parameter to keep its two camera priorities
correct under repeated starts. With `camera_priority: entity` the card
now re-reads the entity every time it starts, so a camera selected while
the card was away is picked up on return. With `camera_priority: card`
the card writes the entity on its first start only, unchanged, since
repeating that write would overwrite a camera the user had selected.

Closes: #2642


BREAKING CHANGE: `condition: initialized` is now `false` whenever the
card is not usable, and `trigger: initialized` fires each time the card
starts up rather than only the first time. Set `ever: true` on either to
keep the previous behaviour.
This commit is contained in:
Dermot Duffy
2026-08-02 12:52:58 -07:00
committed by GitHub
parent e590f72783
commit 17146c8ca6
44 changed files with 1967 additions and 654 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/configuration/overrides.md
+8
View File
@@ -13,6 +13,14 @@ overrides:
> [!WARNING]
> Whilst all configuration parameters are theoretically overridable, in some instances a configuration variable may only be consulted on startup or changing its value may negatively impact behavior -- override results may vary!
> [!WARNING]
> Avoid an override whose `conditions` depend on a value that the override itself
> changes. Applying it changes what its own conditions were matching, so it may
> turn itself on and off repeatedly, or undo the very change that applied it. Examples: a [`camera`](conditions-triggers.md?id=camera) condition that sets
> `cameras`, an
> [`initialized`](conditions-triggers.md?id=initialized) condition that sets
> anything the card must start up again to use.
The top-level `overrides` configuration block expects a list, with each list
item containing `conditions` and at least one of `merge`, `delete` or `set` specified.