Split automations into HA-style `triggers`, ongoing `conditions`, and
`actions`, with compatibility migrations for existing Advanced Camera
Card configs.
## Summary
At a glance (details below):
- **Added** `triggers:` -- a required, HA-shaped block: stock `state` /
`numeric_state` / `template` plus card-specific triggers (`camera`,
`view`, `fullscreen`, ...).
- **Added** the HA-native `if` / `then` / `else` action.
- **Removed** `actions_not` (replaced by `if` / `then` / `else`).
- **Removed** the ambient `advanced_camera_card` template namespace (use
`acc` instead).
- **Changed** the trigger template surface to a top-level `trigger.*`
variable (as in HA); the nested `acc.trigger.*` paths are removed.
- **Changed** `conditions:` to ongoing gates only -- they no longer wake
an automation, and change-only forms (`config`, valueless `camera` /
`view` / `state`) become triggers, not conditions.
- **Changed** action templates to render per step, so a later action
sees state an earlier one changed.
- **Compatibility:** HA-shaped YAML is accepted (singular keys,
single-or-list, `and` / `or` / `not` shorthand, `entity` / `entity_id`).
- **Migration:** existing configs upgrade automatically; anything that
cannot be converted faithfully is recorded under `__UPGRADE_FAILURE__`
for manual fixup.
## Breaking Changes
### 1. Automations now require triggers
Before this PR, `automations[].conditions` served two roles:
- They decided whether the automation should run.
- They also acted as the thing that woke the automation up.
After this PR:
- `triggers` wake the automation.
- `conditions` only gate it at the instant a trigger fires.
Most existing automations are migrated automatically from `conditions:`
to `triggers:`.
### 2. `actions_not` is retired
Legacy `actions_not` is replaced by an HA-style `if` action with `then`
/ `else`.
Faithful conversions are automatic. Cases that cannot be faithfully
converted are recorded under `__UPGRADE_FAILURE__.automations` and must
be migrated manually.
### 3. Template surface aligned with Home Assistant
Two related template changes, both auto-migrated:
- **Top-level `trigger.*`.** Automation actions now receive a top-level
`trigger` template variable, like Home Assistant. Legacy nested paths
such as `acc.trigger.state.to` and
`advanced_camera_card.trigger.camera.to` are migrated automatically when
they appear inside template strings.
- **The ambient `advanced_camera_card` template namespace is removed.**
The long-form ambient namespace (`advanced_camera_card.camera`,
`advanced_camera_card.view`, `advanced_camera_card.config`) is retired
in favour of its shorter `acc` alias -- supported since v7.1.0, and the
only spelling the new trigger surface uses. Existing templates are
migrated automatically by rewriting the `advanced_camera_card.` prefix
to `acc.`.
### 4. Trigger-only condition forms are no longer valid conditions
Some legacy "conditions" were really change detectors. These are now
triggers only:
- `condition: config`
- valueless `camera`
- valueless `view`
- valueless `state` / picture-elements state condition with neither
`state` nor `state_not`
These are automatically promoted in automations and stripped from
overrides/elements where they would no longer be meaningful as ongoing
conditions.
### 5. Template truthiness now follows Home Assistant behavior
Template conditions and template triggers intentionally use different
truthiness rules, matching HA:
- A template condition passes only when the rendered value is `true`
(case-insensitive), matching HA's `condition.py`.
- A template trigger uses HA's broader `result_as_boolean` coercion: a
non-zero number, or `1` / `true` / `yes` / `on` / `enable`
(case-insensitive), counts as true.
### 6. Action templates render when each action executes
Action templates are now rendered per action step, not once for the
whole sequence. This means a later action can see card-local state
changed by an earlier action in the same sequence.
The `trigger` context is fixed for the automation run. HA entity state
updates still depend on the frontend receiving updated HASS state over
the websocket.
## Automatic Migrations
### Automation `conditions:` to `triggers:`
Simple legacy automation:
```yaml
# Before
automations:
- conditions:
- condition: fullscreen
fullscreen: true
actions:
- action: custom:advanced-camera-card-action
advanced_camera_card_action: substream_on
```
```yaml
# After, automatic
automations:
- triggers:
- trigger: fullscreen
fullscreen: true
actions:
- action: custom:advanced-camera-card-action
advanced_camera_card_action: substream_on
```
State conditions become HA-style state triggers:
```yaml
# Before
automations:
- conditions:
- condition: state
entity_id: binary_sensor.front_door
state: 'on'
actions:
- action: custom:advanced-camera-card-action
advanced_camera_card_action: live
```
```yaml
# After, automatic
automations:
- triggers:
- trigger: state
entity_id: binary_sensor.front_door
to: 'on'
actions:
- action: custom:advanced-camera-card-action
advanced_camera_card_action: live
```
Multiple conditions become both triggers and ongoing conditions:
```yaml
# Before
automations:
- conditions:
- condition: camera
cameras: [front_door]
- condition: fullscreen
fullscreen: true
actions:
- action: custom:advanced-camera-card-action
advanced_camera_card_action: substream_on
```
```yaml
# After, automatic
automations:
- triggers:
- trigger: camera
cameras: [front_door]
- trigger: fullscreen
fullscreen: true
conditions:
- condition: camera
cameras: [front_door]
- condition: fullscreen
fullscreen: true
actions:
- action: custom:advanced-camera-card-action
advanced_camera_card_action: substream_on
```
The flattened trigger list is an implicit OR. The retained `conditions:`
list is an implicit AND checked when any trigger fires.
### Trigger-only legacy conditions
Legacy `config` conditions become `config` triggers:
```yaml
# Before
automations:
- conditions:
- condition: config
paths: [menu.style]
actions:
- action: custom:advanced-camera-card-action
advanced_camera_card_action: status_bar
```
```yaml
# After, automatic
automations:
- triggers:
- trigger: config
paths: [menu.style]
actions:
- action: custom:advanced-camera-card-action
advanced_camera_card_action: status_bar
```
Trigger-only leaves are removed from retained `conditions:` blocks
because they no longer describe an ongoing state.
### `actions_not` to `if` / `then` / `else`
```yaml
# Before
automations:
- conditions:
- condition: state
entity_id: input_boolean.camera_alerts
state: 'on'
actions:
- action: custom:advanced-camera-card-action
advanced_camera_card_action: live
actions_not:
- action: none
```
```yaml
# After, automatic
automations:
- triggers:
- trigger: state
entity_id: input_boolean.camera_alerts
actions:
- if:
- condition: state
entity_id: input_boolean.camera_alerts
state: 'on'
then:
- action: custom:advanced-camera-card-action
advanced_camera_card_action: live
else:
- action: none
```
If the legacy automation had no conditions, or only trigger-only
conditions, `actions_not` is dropped because the old `else` branch could
not be reproduced as an ongoing predicate.
### Trigger template paths
```yaml
# Before
message: 'Door is {{ acc.trigger.state.to }} from {{ acc.trigger.state.from }}'
```
```yaml
# After, automatic
message: 'Door is {{ trigger.to_state.state }} from {{ trigger.from_state.state }}'
```
Path rewrites performed automatically:
| Old path | New path |
| -------------------------- | -------------------------- |
| `acc.trigger.state.entity` | `trigger.entity_id` |
| `acc.trigger.state.from` | `trigger.from_state.state` |
| `acc.trigger.state.to` | `trigger.to_state.state` |
| `acc.trigger.camera.from` | `trigger.from_acc.camera` |
| `acc.trigger.camera.to` | `trigger.to_acc.camera` |
| `acc.trigger.view.from` | `trigger.from_acc.view` |
| `acc.trigger.view.to` | `trigger.to_acc.view` |
| `acc.trigger.config.from` | `trigger.from_acc.config` |
| `acc.trigger.config.to` | `trigger.to_acc.config` |
The same rewrites are applied for the older
`advanced_camera_card.trigger.*` namespace.
### Ambient template namespace
Any remaining long-form ambient `advanced_camera_card.*` references
(outside the trigger surface) are rewritten to the `acc.*` alias:
```yaml
# Before
title: 'Now viewing {{ advanced_camera_card.camera }}'
```
```yaml
# After, automatic
title: 'Now viewing {{ acc.camera }}'
```
## Manual Migration Cases
### `__UPGRADE_FAILURE__.automations`
If a legacy automation cannot be converted faithfully, the original
automation is recorded under:
```yaml
__UPGRADE_FAILURE__:
automations:
- ...
```
These entries require manual migration.
The main known case is legacy `actions_not` with a condition whose
trigger can only fire on a rising edge, such as:
- `condition: template`
- `condition: screen`
- `condition: numeric_state` without an entity-backed state to watch
Those conditions can start the `then` branch, but cannot reliably start
the `else` branch when they stop matching.
### Unsupported HA conditions and triggers
This PR aligns the card with HA where supported, but it is not a full HA
automation engine.
Unsupported HA condition families include:
- `time`
- `zone`
- `sun`
- `location`
- `device`
- `condition: trigger`
Unsupported HA trigger platforms include:
- `event`
- `time`
- `time_pattern`
- `sun`
- `zone`
- `calendar`
- `webhook`
- `tag`
- `device`
- `mqtt`
The card-specific camera `triggers:` feature (which auto-selects and
wakes the card on camera events such as motion) is a separate feature
from automation `triggers:`, despite the shared word.
### Trigger IDs and variables
HA keys such as `id`, `alias`, and `variables` are accepted so pasted HA
YAML validates, but they are ignored by the card. There is no
`trigger.id` support in this PR.
## New Compatibility Features
This PR also makes card config more forgiving for HA-style YAML:
- `trigger`, `condition`, and `action` singular keys are accepted and
normalized to `triggers`, `conditions`, and `actions`.
- Single trigger, condition, and action objects are accepted where lists
are expected.
- `if`, `then`, and `else` accept a single item or a list.
- Composite condition shorthand is accepted:
- `{ and: [...] }`
- `{ or: [...] }`
- `{ not: [...] }`
- `{ condition: [...] }` as an implicit AND
- State conditions resolve expected state values that name another
entity, matching HA/Lovelace behavior.
- Both `entity` and `entity_id` are accepted on state and numeric
conditions and triggers (a superset of HA's two dialects), so there is
no forced rename.
- `state_not` remains supported as a card/Lovelace-friendly extension.
## Trigger Payloads
Automation action templates receive a top-level `trigger` object.
For stock `state` and `numeric_state` triggers:
```yaml
trigger.platform
trigger.entity_id
trigger.entity
trigger.from_state
trigger.to_state
```
For template triggers:
```yaml
trigger.platform
```
For card-specific triggers:
```yaml
trigger.platform # "acc"
trigger.type
trigger.from_acc
trigger.to_acc
```
The card does not currently expose HA's `id`, `idx`, `for`, `attribute`,
`above`, `below`, or `alias` trigger fields.
BREAKING CHANGE: Automations now follow Home Assistant's `triggers:` /
`conditions:` / `actions:` model. Automations require a `triggers:`
block and `conditions:` no longer wake an automation; `actions_not` is
removed in favour of an `if` / `then` / `else` action; the nested
`acc.trigger.*` template paths and the ambient `advanced_camera_card`
template namespace are removed (use the top-level `trigger.*` surface
and the `acc` alias); trigger-only condition forms (`config`, valueless
`camera` / `view` / `state`) are no longer valid conditions; and
template-condition vs template-trigger truthiness now follow HA.
Existing configs are upgraded automatically where a faithful conversion
exists; anything that cannot be converted is recorded under
`__UPGRADE_FAILURE__` for manual migration.
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
247 lines
9.0 KiB
TypeScript
247 lines
9.0 KiB
TypeScript
import type { IssueTriggerContext } from 'issue';
|
|
import { ConditionStateChange } from '../../condition-trigger/conditions/types';
|
|
import { isActionAllowedBasedOnInteractionState } from '../../utils/interaction-mode';
|
|
import { Timer } from '../../utils/timer';
|
|
import { CardIssueManagerAPI } from '../types';
|
|
import { IssueStateManager } from './state-manager';
|
|
import { Issue, IssueKey, IssueReadOnlyState, IssueTriggerContextKey } from './types';
|
|
|
|
// Exponential backoff schedule for 'auto' retry. The base is set above the
|
|
// per-media retry threshold (~10s) so the issue-level backoff kicks in *after*
|
|
// lower-level recovery has had a chance to work, not in parallel with it.
|
|
export const RETRY_EXPONENTIAL_BASE_SECONDS = 30;
|
|
export const RETRY_EXPONENTIAL_MAX_SECONDS = 600;
|
|
const RETRY_EXPONENTIAL_JITTER_MIN = 0.5;
|
|
const RETRY_EXPONENTIAL_JITTER_MAX = 1.0;
|
|
|
|
// Wraps the passive IssueStateManager with reaction logic. A single
|
|
// condition-state listener drives everything: it runs one-shot static
|
|
// detection when mandatory-init completes (`initialized` transitions to
|
|
// true), then evaluates dynamic issues on every subsequent state change,
|
|
// schedules retries, and updates the card. Full-card issues are rendered by
|
|
// card.ts via getStateManager().getFullCardIssue(). Non-full-card issue
|
|
// notifications are shown on demand via showNotification().
|
|
export class IssueManager {
|
|
private _api: CardIssueManagerAPI;
|
|
private _stateManager = new IssueStateManager();
|
|
private _retryTimer = new Timer();
|
|
private _retryAttempt = 0;
|
|
private _suspended = false;
|
|
|
|
// Reentrancy guard: evaluate() calls setState() on the condition state
|
|
// manager, which fires listeners synchronously — including the one
|
|
// registered in this constructor. Without this guard, detectDynamic()
|
|
// and presence computation would run twice per evaluation.
|
|
private _evaluating = false;
|
|
|
|
constructor(api: CardIssueManagerAPI) {
|
|
this._api = api;
|
|
api.getConditionStateManager().addListener((change) => this._onStateChange(change));
|
|
}
|
|
|
|
// =========================================================================
|
|
// Setup.
|
|
// =========================================================================
|
|
|
|
public addIssue(issue: Issue): void {
|
|
this._stateManager.addIssue(issue);
|
|
}
|
|
|
|
public getStateManager(): IssueReadOnlyState {
|
|
return this._stateManager;
|
|
}
|
|
|
|
// =========================================================================
|
|
// Detection & reaction.
|
|
// =========================================================================
|
|
|
|
// Called by components that detect an issue directly (e.g. a provider
|
|
// error event), bypassing the condition-state polling loop.
|
|
public trigger<K extends IssueTriggerContextKey>(
|
|
key: K,
|
|
context: IssueTriggerContext[K],
|
|
): void {
|
|
this._stateManager.trigger(key, context);
|
|
this.evaluate();
|
|
}
|
|
|
|
// Evaluate all dynamic issues against current state, then react to any
|
|
// changes: notify, update condition state, and schedule retries.
|
|
//
|
|
// Detection of "anything changed" is delegated to the condition state
|
|
// manager: IssuePresence is a Map<IssueKey, IssueDescription>, so its
|
|
// deep equality check naturally catches both presence-set churn (issues
|
|
// appearing/disappearing) and content-level churn (an issue swapping
|
|
// sub-states without changing its key, e.g. ConnectionIssue going from
|
|
// 'lost' to 'starting').
|
|
public evaluate(): void {
|
|
if (this._suspended || this._evaluating) {
|
|
return;
|
|
}
|
|
|
|
this._evaluating = true;
|
|
try {
|
|
const state = this._api.getConditionStateManager().getState();
|
|
this._stateManager.detectDynamic(state);
|
|
|
|
if (
|
|
this._api.getConditionStateManager().setState({
|
|
issues: this._stateManager.getIssuePresence(),
|
|
})
|
|
) {
|
|
this._api.getCardElementManager().update();
|
|
}
|
|
|
|
this._scheduleRetryIfNeeded();
|
|
} finally {
|
|
this._evaluating = false;
|
|
}
|
|
}
|
|
|
|
// Attempts a retry for the given issue. Pass `force = true` for user-
|
|
// initiated retries (e.g. clicking the retry button on a notification): it
|
|
// bypasses the `needsRetry()` gate that scheduled auto-retries must
|
|
// respect, so even an issue that doesn't currently want a retry will run
|
|
// its `retry()` method. Also stops the pending auto-retry timer so the
|
|
// user action resets the backoff schedule.
|
|
public retry(key: IssueKey, force?: boolean): void {
|
|
this._stateManager.retry(key, force);
|
|
this._retryTimer.stop();
|
|
this.evaluate();
|
|
}
|
|
|
|
// Show the notification for an issue on demand (e.g. user clicks a loading
|
|
// icon) regardless of whether the issue is currently active.
|
|
public showNotification(key: IssueKey): void {
|
|
const notification = this._stateManager.getNotification(key);
|
|
if (notification) {
|
|
this._api.getNotificationManager().setNotification(notification);
|
|
}
|
|
}
|
|
|
|
// =========================================================================
|
|
// Lifecycle.
|
|
// =========================================================================
|
|
|
|
public reset(key?: IssueKey): void {
|
|
// When resetting a specific key that has no active issue, skip the
|
|
// reset+evaluate cycle entirely to avoid unnecessary work.
|
|
if (key && !this._stateManager.getIssuePresence().has(key)) {
|
|
return;
|
|
}
|
|
this._stateManager.reset(key);
|
|
this.evaluate();
|
|
}
|
|
|
|
// Gate evaluation while the card is detached so timers don't arm or mature
|
|
// offscreen. Issue state is preserved (including full-card issues like
|
|
// config_error). Issue-internal timers are stopped via Issue.suspend so
|
|
// offscreen time doesn't count against age-based thresholds (e.g. media
|
|
// loading timeout). Evaluation resumes on resume().
|
|
public suspend(): void {
|
|
this._suspended = true;
|
|
this._retryTimer.stop();
|
|
this._stateManager.suspend();
|
|
}
|
|
|
|
public resume(): void {
|
|
this._suspended = false;
|
|
this.evaluate();
|
|
}
|
|
|
|
public destroy(): void {
|
|
this._retryTimer.stop();
|
|
this._stateManager.destroy();
|
|
}
|
|
|
|
// =========================================================================
|
|
// Private helpers.
|
|
// =========================================================================
|
|
|
|
// Drives both one-shot static detection (on mandatory-init completion) and
|
|
// normal re-evaluation (on any condition-state change).
|
|
//
|
|
// `initialized: true` in the change payload means mandatory initialization
|
|
// just finished — see InitializationManager._initializeMandatory. That's
|
|
// also the earliest point at which the full HASS object is guaranteed
|
|
// ready for websocket calls (e.g. LegacyResourceIssue's lovelace/resources
|
|
// fetch). Because `initialized` is latched (its comment notes it never
|
|
// changes again), this block fires exactly once per IssueManager life.
|
|
private _onStateChange(change: ConditionStateChange): void {
|
|
if (change.change.initialized === true && change.new.hass) {
|
|
/* async */ this._stateManager
|
|
.detectStatic(change.new.hass)
|
|
.then(() => this.evaluate());
|
|
}
|
|
this.evaluate();
|
|
}
|
|
|
|
private _scheduleRetryIfNeeded(): void {
|
|
if (!this._stateManager.needsRetry()) {
|
|
this._retryTimer.stop();
|
|
this._retryAttempt = 0;
|
|
return;
|
|
}
|
|
if (this._retryTimer.isRunning()) {
|
|
return;
|
|
}
|
|
|
|
const config = this._api.getConfigManager().getConfig();
|
|
if (!config) {
|
|
this._retryAttempt = 0;
|
|
return;
|
|
}
|
|
const delaySeconds = this._nextRetryDelaySeconds(config.view.issues.retry_seconds);
|
|
if (delaySeconds === null) {
|
|
this._retryAttempt = 0;
|
|
return;
|
|
}
|
|
|
|
this._retryTimer.start(delaySeconds, () => {
|
|
if (!this._stateManager.needsRetry()) {
|
|
this._retryAttempt = 0;
|
|
return;
|
|
}
|
|
if (this._isScheduledRetryAllowed()) {
|
|
this._stateManager.retry();
|
|
this._retryAttempt++;
|
|
// evaluate() re-arms the timer via _scheduleRetryIfNeeded.
|
|
this.evaluate();
|
|
} else {
|
|
// Retry was gated (e.g. user interaction). This isn't a failed attempt
|
|
// so don't increment — re-arm at the same delay.
|
|
this._scheduleRetryIfNeeded();
|
|
}
|
|
});
|
|
}
|
|
|
|
private _nextRetryDelaySeconds(retryConfig: 'auto' | number): number | null {
|
|
if (typeof retryConfig === 'number') {
|
|
return retryConfig === 0 ? null : retryConfig;
|
|
}
|
|
|
|
// 'auto': exponential backoff, capped, with jitter to avoid thundering-herd
|
|
// when multiple cards retry the same backend in lockstep.
|
|
const exp = Math.min(
|
|
RETRY_EXPONENTIAL_MAX_SECONDS,
|
|
RETRY_EXPONENTIAL_BASE_SECONDS * 2 ** this._retryAttempt,
|
|
);
|
|
const jitter =
|
|
RETRY_EXPONENTIAL_JITTER_MIN +
|
|
Math.random() * (RETRY_EXPONENTIAL_JITTER_MAX - RETRY_EXPONENTIAL_JITTER_MIN);
|
|
return exp * jitter;
|
|
}
|
|
|
|
private _isScheduledRetryAllowed(): boolean {
|
|
const interactionMode = this._api.getConfigManager().getConfig()?.view
|
|
.issues.interaction_mode;
|
|
return (
|
|
!!interactionMode &&
|
|
isActionAllowedBasedOnInteractionState(
|
|
interactionMode,
|
|
this._api.getInteractionManager().hasInteraction(),
|
|
)
|
|
);
|
|
}
|
|
}
|