## Summary
- Collapse `live_substream_{on,off,select}` into a unified
`substream_{on,off}` pair, symmetric with `call_{start,end}`.
- Rename the `camera` field on the former `live_substream_select` to
`stream` (it always was a stream ID).
- Add optional `camera` field to both new actions for targeting a
non-selected base camera.
- YAML configs are migrated automatically; URL bookmarks must be updated
by hand.
## Migration
### Cycling between camera and substream (toggle button)
Before:
```yaml
tap_action:
action: custom:advanced-camera-card-action
advanced_camera_card_action: live_substream_on
```
After:
```yaml
tap_action:
action: custom:advanced-camera-card-action
advanced_camera_card_action: substream_on
```
### Selecting a specific substream
Before:
```yaml
tap_action:
action: custom:advanced-camera-card-action
advanced_camera_card_action: live_substream_select
camera: camera.front_door_hd
```
After:
```yaml
tap_action:
action: custom:advanced-camera-card-action
advanced_camera_card_action: substream_on
stream: camera.front_door_hd
```
### Turning the substream off
Before:
```yaml
tap_action:
action: custom:advanced-camera-card-action
advanced_camera_card_action: live_substream_off
```
After:
```yaml
tap_action:
action: custom:advanced-camera-card-action
advanced_camera_card_action: substream_off
```
### URL querystrings (manual update required)
| Before | After |
| --- | --- |
|
`?advanced-camera-card-action.live_substream_select=camera.front_door_hd`
| `?advanced-camera-card-action.substream_on=camera.front_door_hd` |
Draws significant inspiration (and direct styling) from
https://github.com/dermotduffy/advanced-camera-card/pull/2447 . Thank
you @Maudfer !
BREAKING CHANGE:
The microphone condition previously bundled two unrelated signals —
whether a two-way-audio session was connected and whether the microphone
was muted. Connection state is now its own dedicated call condition, and
microphone is reserved purely for mute state. Configs are upgraded
automatically (the card rewrites affected conditions under overrides,
elements, and automations). If you maintain config by hand, convert as
follows:
If you only used connected:
# Before
```yaml
condition: microphone
connected: true
```
# After
```yaml
condition: call
call: true
```
If you used both connected and muted — they must be split into two
conditions, since they no longer live together:
# Before
```yaml
condition: microphone
connected: true
muted: false
```
# After
```yaml
condition: and
conditions:
- condition: call
call: true
- condition: microphone
muted: false
```
Introduces a ProblemManager that detects and surfaces actionable issues
(stale config, legacy frigate-hass-card resources, slow/failed streams)
via status bar indicators and notification popups with fix actions.
- Closes#2314
I used GPT-5.4 to investigate and generate this fix. I'm not sure if the
code is good, but I can confirm it works.
---------
Co-authored-by: dermotduffy <dermot.duffy@gmail.com>
This PR fixes an issue where, after running the card for a few hours,
new events (such as thumbnails and triggers) would stop showing up.
This bug was caused by the Home Assistant connection dropping and
reconnecting in the background. Event subscriptions (such as Frigate
WebSocket events established via `hass.connection.subscribeMessage`) are
bound to the connection they were created on. When the connection drops,
those subscriptions are lost, and until now, they were not being
automatically recreated when the connection was restored.
This PR ensures that when a restored connection is detected, the card
properly re-initializes the camera and view components to re-establish
these background subscriptions.
1. HA Connection Reconnect Handling (`HASSManager`)
- Added logic to detect when the Home Assistant connection transitions
from disconnected back to connected.
- When restored, the card uninitializes the `CAMERAS`, `VIEW`, and
`INITIAL_TRIGGER` initialization aspects.
- This forces the system to recreate the camera managers and
re-subscribe to the relevant WebSocket event feeds in the next render
cycle, fixing the broken thumbnail/trigger feeds.
2. Centralized Camera Teardown (`InitializationManager`)
- Improved the teardown logic by moving the
`this._api.getCameraManager().destroy()` call directly into
`InitializationManager.uninitialize` when the `CAMERAS` aspect is
targeted.
- Removed duplicate `destroy()` calls scattered across `ConfigManager`
and `CardElementManager`.
- This ensures that whenever cameras are forced to re-initialize (such
as during a reconnection event), the old manager is safely destroyed in
a centralized, predictable way without memory leaks.
3. Testing
- Added tests in `hass-manager.test.ts` to verify the uninitialization
logic fires during a reconnection event.
- Updated `initialization-manager.test.ts` to verify that
`CameraManager.destroy()` is automatically called when uninitializing
cameras.
---------
Co-authored-by: dermotduffy <dermot.duffy@gmail.com>
- Add support for Frigate reviews / detections.
- Add support for GenAI metadata.
- Significant internal refactor to more flexible "UnifiedQuery" to allow
mixing cameras with simple metadata and review metadata (e.g. a timeline
view of a Frigate camera with reviews, and a Reolink camera with simple
metadata).
- Add support for folder media as camera media.
There are a few more PRs to commit prior to this going live, but
commiting this for now due to the scale of the change.
BREAKING CHANGE: `media_type` and `events_type` are retired under
`live`, `viewer` and `timeline` configuration sections, instead media
type is associated (once) with the camera under `media`.
### Problem
When configuration overrides are removed or changed for
`remote_control`, the automations previously registered by the card were
not updated, causing stale automations to remain active.
### Fix
Re-run the remote-control and automations loaders when the effective
configuration changes due to overrides so that automation
additions/removals reflect the current config.
#### What changed
- Modified: config-manager.ts
- Call `setKeyboardShortcutsFromConfig(this._api)`,
`setRemoteControlEntityFromConfig(this._api)` and
`setAutomationsFromConfig(this._api)` inside `_processOverrideConfig()`.
- Modified: `config-manager.test.ts`
- Added ConfigManager for test setup with real AutomationsManager and
ConditionStateManager
- Added test constants to centralize test data
- Expanded test coverage for override conditions:
- loaders should re-run when overrides change
- remote-control loader with overrides
#### Testing
- Full test suite run locally: 229 files, 2852 tests — all passing (with
TZ forced to 'UTC') ✅
Dermot Duffy