flan/advanced-camera-card
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a31816c168655b5dd7c237ae7b7ae1dbb1851c84
advanced-camera-card/docs/troubleshooting.md
T
Dermot DuffyandClaude Opus 4.8 b701366762 feat: Align automations with Home Assistant triggers and conditions (#2527) 
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>
2026-06-30 17:45:13 -07:00

412 lines
18 KiB
Markdown
Raw Blame History

# Troubleshooting
## Highlighted Issues
### Legacy dashboard resource detected
You still have the old `frigate-hass-card.js` resource registered in your
dashboard (and not `advanced-camera-card.js`). Having both registered causes
duplicate element registration errors and unpredictable behavior. Symptoms
include the card not loading, the version changing between reloads, or log
entries like:
`Failed to execute 'define' on 'CustomElementRegistry': the name "focus-trap" has already been used with this registry window`
To fix:
1. Edit your dashboard (click the three-dot menu in the top right) and select
**Manage Resources**.
1. Remove any entry referring to `frigate-hass-card`. You should only have a
single entry for `advanced-camera-card`.
1. Optionally, delete the `frigate-hass-card` directory on your filesystem if
present (e.g. `$HA_PATH/www/community/frigate-hass-card`), as long as an
`advanced-camera-card` directory exists there too.
1. Clear your browser cache and reload.
If you are an admin user and the card detects both resources are registered, an
alert icon will appear in the status bar -- clicking it will display a
notification with a button to automatically remove the legacy resource.
### Configuration upgrade available
If you see a notification that a configuration upgrade is available, it means
your card configuration uses an older format that can be automatically updated.
To upgrade:
1. Open your Home Assistant dashboard.
1. Click the pencil icon to enter edit mode.
1. Click the three-dot menu on your card and choose **Edit**.
1. In the card editor, click the **Automatic Upgrade** button at the top.
1. Review the changes and save.
If the automatic upgrade button is not visible, your configuration may already
be up to date. Try clearing your browser cache and reloading.
### Configuration could not be fully upgraded
Automatic configuration upgrades are not perfect. If you see a notification that
your configuration could not be fully upgraded, you will find part of your
configuration set aside -- untouched -- under an `__UPGRADE_FAILURE__` field.
To resolve it:
1. Edit your card's YAML manually and find the `__UPGRADE_FAILURE__` key.
1. Re-create each entry under it in the current format (see the relevant
configuration documentation in the sidebar). An upgrade usually fails this
way when a feature has been retired, or changed enough that the migration
needs human judgement.
1. Once you're happy with the result, delete the `__UPGRADE_FAILURE__` key.
The notification clears once the `__UPGRADE_FAILURE__` key is gone.
### Media does not load
Media not loading? Permanent "loading circle"?
Media failing to load is a relatively common error, but can be caused by any
number of issues (e.g. installation problems, networking problems, video/codec
problems, a Home Assistant bug or card bug). This applies to live streams,
recorded media in the viewer, and image views.
During a live stream load, the card will show a "loading circle" icon and, for
cameras with a `camera_entity` configured, will show images refreshing once per
second until the stream has fully loaded (unless `live.show_image_during_load`
is set to false).
Debugging steps:
1. If you're using the default `auto` live provider, or explicitly setting the
`ha` live provider, try opening the `camera_entity` in Home Assistant and
verifying whether the stream loads there. You can press the `e` key on any
Home Assistant dashboard, choose the relevant entity, and see if the stream
loads. If it does not, you have an upstream installation issue with your
camera / the integration for the camera, and need to resolve that first.
Your issue is not related to the card itself.
1. Check whether any URLs specified in your card configuration are accessible
_from the network of the browser_.
1. Check whether or not there are helpful clues shown on your Javascript
console (`F12` in many browsers) that might indicate the source of the
issue.
1. Check you are using the latest version of all relevant camera integrations
(e.g.
[Frigate](https://github.com/blakeblackshear/frigate-hass-integration)).
1. If you're using a Frigate camera and are requesting a `webrtc` stream,
ensure [you have configured Frigate
accordingly](https://docs.frigate.video/configuration/live/#webrtc-extra-configuration).
1. Search for your symptoms on the [card issues
page](https://github.com/dermotduffy/advanced-camera-card/issues) and see if
you find any prior relevant discussions.
If you're happy with just using an image stream but want the small circle to go
away, use the [`image live provider`](./configuration/cameras/live-provider.md?id=image).
### Unknown Command
`Camera initialization failed: Unknown command`
Your Frigate integration may not be up to date. Check [the latest Frigate
Integration
releases](https://github.com/blakeblackshear/frigate-hass-integration/releases/tag/v5.7.0).
## Other Issues
### 2-way audio doesn't work
There are many requirements for 2-way audio to work. See [Using 2-way
audio](usage/2-way-audio.md) for more information about these. If your
microphone still does not work and you believe you meet all the requirements try
eliminating the card from the picture by going directly to the `go2rtc` UI,
navigating to `links` for your given stream, then to `webrtc.html` with a
microphone. If this does not work correctly with 2-way audio then your issue is
with `go2rtc` not with the card. In this case, you could file an issue in [that
repo](https://github.com/AlexxIT/go2rtc/issues) with debugging information as
appropriate.
### Android will not render &gt;4 JSMPEG live views
Android Webview (as used by Android Chrome / Android Home Assistant Companion)
appears to severely limit the number of simultaneous OpenGL contexts that can be
opened. The JSMPEG player (that this card uses), consumes 1 OpenGL context per
rendering.
This limitation may be worked around (at a performance penalty) by disabling
OpenGL for JSMPEG live views:
```yaml
live:
jsmpeg:
options:
disableGl: true
```
[This bug](https://github.com/dermotduffy/advanced-camera-card/issues/191) has some
more discussion on this topic. New ideas to address this underlying limitation
most welcome!
### Autoplay in Chrome when a tab becomes visible again
Even if `live.auto_play` or `media_viewer.auto_play` is set to `[]`, Chrome
itself will still auto play a video that was previously playing prior to the tab
being hidden, once that tab is visible again. This behavior cannot be influenced
by the card. Other browsers (e.g. Firefox, Safari) do not exhibit this behavior.
### Blank white image on `live` view
For some slowly loading cameras, for which [Home Assistant stream
preloading](https://www.home-assistant.io/integrations/camera/) is not enabled,
Home Assistant may return a blank white image when asked for a still. These
stills are used during initial Advanced Camera Card load of the `live` view if the
`live.show_image_during_load` option is enabled. Disabling this option should
show the default media loading controls (e.g. a spinner or empty video player)
instead of the blank white image.
### Casting to Chromecast broken
This could be for any number of reasons. Chromecast devices can be quite picky
on network, DNS and certificate issues, as well as audio and video codecs. Check
your Home Assistant log as there may be more information in there.
> [!TIP]
> For Frigate to support casting of clips, the default ffmpeg settings for
> Frigate must be modified, i.e. Frigate does not encode clips in a Chromecast
> compatible format out of the box (specifically: audio must be enabled in the AAC
> codec, whether your camera supports audio or not). See the [Frigate Home
> Assistant documentation](https://docs.frigate.video/integrations/home-assistant/)
> or [this issue](https://github.com/blakeblackshear/frigate/issues/3175) for
> more.
### Custom element does not exist
This is usually a sign that the card is not correctly installed (i.e. the
browser cannot find the Javascript). In cases where it works in some browsers /
devices but not in others it may simply be an old browser / webview that does
not support modern Javascript (this is occasionally seen on old Android
hardware). In this latter case, you are out of luck.
### `double_tap` does not work in Android
The Android video player swallows `double_tap` interactions in order to
rewind or fast-forward. Workarounds:
- Use `hold` instead of `double_tap` for your card-wide action.
- Use an [Advanced Camera Card Element](configuration/elements/README.md) or menu icon to
trigger the action instead.
### Dragging in carousels broken in Firefox
The Firefox video player swallows mouse interactions, so dragging is not
possible in carousels that use the Firefox video player (e.g. `clips` carousel,
or live views that use the `frigate` or `webrtc-card` provider). The next and
previous buttons may be used to navigate in these instances.
Dragging works as expected for snapshots, or for the `jsmpeg` provider.
### Dragging video control doesn't work in Safari
Dragging the Safari video controls "progress bar" conflicts with carousel
"dragging", meaning the video controls progress bar cannot be moved left or
right. Turning off carousel dragging (and using next/previous controls) will
return full video controls in Safari:
```yaml
live:
draggable: false
media_viewer:
draggable: false
```
### Downloads don't work
Downloads are assembled by the Frigate backend out of ~10s segment files. You
must have enough cache space in your Frigate instance to allow this assembly to
happen -- if large downloads don't work, especially for recordings, check your
Frigate backend logs to see if it's running out of space. You can increase your
cache size with the `tmpfs` `size` argument, see [Frigate
documentation](https://docs.frigate.video/frigate/installation#docker).
Large downloads may take a few seconds to assemble, so there may be a delay
between clicking the download button and the download starting.
### `Forbidden media source identifier`
- If you are using a custom `client_id` setting in your `frigate.yml` file (the
configuration file for the Frigate backend itself), the card will auto-detect
it from the camera entity. If auto-detection fails (e.g. no `camera_entity`
is configured), set it manually — see [Frigate engine
configuration](configuration/cameras/engine.md?id=frigate).
- You must have the `Enable the media browser` option enabled for the Frigate
integration, in order for media fetches to work for the card. Media fetches
are used to fetch events / clips / snapshots, etc. If you just wish to use
live streams without media fetches, you can use the following configuration:
```yaml
live:
controls:
thumbnails:
mode: none
```
### Fullscreen doesn't work on iPhone
Unfortunately, [iOS does not support the Javascript fullscreen
API](https://caniuse.com/fullscreen) on the iPhone, which severely limits the
fullscreen functionality available. On iPhone, fullscreen is only possible of
the selected video element. As a result, there will be no menu, status bar, grid
support, gallery / timeline support, nor support for non-video based [live
providers](./configuration/cameras/live-provider.md) such as `image` or `jsmpeg`
-- exclusively viewing a selected live video or media video in fullscreen.
The card will only show the fullscreen menu button when fullscreen can usefully
be activated, which means for certain views on the iPhone it will be absent.
### Custom `go2rtc` server only works on Home Network
This card runs in your browser, and (if configured) attempts to opens a direct
connection to a `go2rtc` server. If you are manually specifying a custom server
using the [`url`](./configuration/cameras/live-provider.md?id=go2rtc) option,
your browser may only be able to access that server when you're on the same
network, and/or when both Home Assistant and the `go2rtc` server are both
accessed over `http` or both over `https`.
To automatically proxy the connection via the Home Assistant process instead
(ensuring that if you can access the card, you'll always have access to the
`go2rtc` server), optionally install
[hass-web-proxy-integration](https://github.com/dermotduffy/hass-web-proxy-integration)
and your connection will be automatically proxied. See
[proxying](./configuration/cameras/README.md?id=proxy).
### iOS App not updating after card version change
Try resetting the app frontend cache:
- `Configuration -> Companion App -> Debugging -> Reset frontend cache`
### Javascript console errors
#### `[Violation] Added non-passive event listener to a scroll-blocking [...] event`
This card uses [visjs](https://github.com/visjs/vis-timeline) -- a timeline
library -- to show camera timelines. This library currently uses non-passive
event-listeners. These warnings can be safely ignored in this instance and
cannot easily be fixed in the underlying library.
### Microphone menu button not shown
The microphone menu button will only appear if both enabled (see [Menu Button
configuration](configuration/menu.md?id=available-buttons)) and if the media
that is currently loaded supports 2-way audio. See [Using 2-way
audio](usage/2-way-audio.md) for more information about the requirements that
must be followed.
### Picture-in-Picture only shows video but not other card controls
Picture-in-Picture (PIP) uses the browser's [native video PIP
API](https://caniuse.com/picture-in-picture) which floats the raw video element
into a small window. This means:
- **No card UI in the PIP window.** Only the video itself is shown — no menu,
status bar, timeline, or other card elements. The card remains fully
functional on the dashboard behind it.
- **Limited browser support.** Not all browsers support the PIP API. See
[Can I use: Picture-in-Picture](https://caniuse.com/picture-in-picture) for
current browser compatibility.
- **Non-video live providers are not supported.** Providers such as `image` or
`jsmpeg` do not use a native `<video>` element so PIP is unavailable for
these.
A more fully featured PIP mode (showing the entire card in a floating window)
was explored using the experimental [Document Picture-in-Picture
API](https://caniuse.com/mdn-api_documentpictureinpicture), however it proved
unworkable: Home Assistant state updates cannot reach a card in a separate
document, and browser-managed styles (`adoptedStyleSheets`) are cleared when
elements move between documents — resulting in an unstyled, non-updating card.
### New version not working in Chrome
When upgrading the card it's recommended to reset the frontend cache. Sometimes
clearing site data in Chrome settings isn't enough.
- Press F12 to display `Dev Console` in Chrome then right click on the refresh
icon and select `Empty Cache and Hard Reload`
### Static image URL with credentials doesn't load
Your browser will not allow a page/script (like this card) to pass credentials
to a cross-origin (different host) image URL for security reasons. There is no
way around this unless you could also control the webserver that is serving the
image to specifically allow `crossorigin` requests (which is typically not the
case for an image served from a camera, for example). The stock Home Assistant
Picture Glance card has the same limitation, for the same reasons.
### Status "popup" continually popping up
Status popup can be disabled with this configuration:
```yaml
status_bar:
style: none
```
### Too many releases!
A new version of this card is [automatically
released](./developing.md?id=release-philosophy) on each change ("Pull
Request"). This means features and fixes are available immediately! However, it
also means there may be visual notifications in Home Assistant frequently
recommending update and some users find this annoying.
The topic of intentionally doing fewer releases has been discussed fairly
extensively
([#1781](https://github.com/dermotduffy/advanced-camera-card/issues/1781),
[#2072](https://github.com/dermotduffy/advanced-camera-card/issues/2072)) but it
always comes down to some users (and this developer!) like it instant / often,
others like it slower / rarer.
As a workaround for those that this bothers, the visual notification (the 'dot')
to remind users to upgrade can be disabled by disabling the matching `update`
entity provided by HACS. The entity is usually called
`update.advanced_camera_card_update`. To disable it:
- Navigate to: `Settings -> Devices & Services -> HACS -> # Entities -> Advanced Camera Card update`
- Click the settings "cog"
- Set "Enabled" to off
### Unknown Frigate instance `frigate`
e.g. `API error whilst subscribing to events for unknown Frigate instance frigate`
The card auto-detects a custom `client_id` from the camera entity, so this
error usually means auto-detection couldn't run (no `camera_entity` configured)
or the entity doesn't expose a `client_id` attribute. Set it manually via the
`client_id` parameter:
```yaml
cameras:
- camera_entity: camera.my_frigate_camera
frigate:
client_id: my-frigate
```
See [Frigate engine configuration](configuration/cameras/engine.md?id=frigate)
for more details.
If you're not using a custom `client_id`, your Frigate integration is likely not
installed correctly.
### `webrtc_card` unloads in the background
[AlexxIT's WebRTC Card](https://github.com/AlexxIT/WebRTC) which is embedded by
the `webrtc_card` live provider internally disconnects the stream when the
browser tab is changed (regardless of any Advanced Camera Card configuration settings,
e.g. `lazy_unload`). To allow the stream to continue running in the background,
pass the `background` argument to the `webrtc_card` live provider as shown
below. This effectively allows the Advanced Camera Card to decide whether or not to
unload the stream.
```yaml
live:
webrtc_card:
background: true
```
Reference in New Issue View Git Blame Copy Permalink