### 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') ✅
These conditions are probably not hugely useful for most card users, but
allows the inbuilt automation systems to be used for card internal
operations.
[skip ci]
- Much improved API cleanliness and testability to allow further
extensibility in future
- Simplified code in `live` view
This technically contains a small change in how overrides work in the
`live` view. Since that change is _closer_ to the documentation, and
since this is likely to be rarely used, this is not considered a
breaking change. Previously, overrides for a given live camera would
always render _as if_ that camera was selected, vs was actually
selected. Now, overrides will only apply in the live view when the
camera is _actually_ selected. If this is an issue for you in practice,
lets discuss.
Whilst the Frigate support in this card is the best among camera
engines, the name incorrectly suggests that Frigate is a requirement.
Instead, to broaden the appeal, change to more camera agnostic name.
This does not suggest any change in priority, role or support for
Frigate.
This change is likely to be bug prone, due to the size of the rename --
the code contains 1500+ references to "Frigate" most of which make sense
to rename, some which do not, all of which needed human assessment.
- Closes#1298
BREAKING CHANGE: References to `frigate-card` in all kinds of
configuration need to be updated to `advanced-camera-card`. An automated
config upgrade should take care of the majority of usecases (click `Edit
-> Upgrade -> Save`), though may not be perfect.
- Closes#1818
**Why add this?**: A repeated pattern is that an issue is fixed in the
card, a new build is released and users will incorrectly believe it's
not yet fixed due to their browser caching the old code. This results in
wasting their time, and my time.
**But it's obnoxious!**: I'm pretty sensitive to this (hence adding
these messages!), so let me know how terrible you find it. You can
disable it with:
```yaml
performance:
features:
card_loading_indicator: false
```
* The `low-performance` profile itself had parse errors: fix them!
* Do not silently swallow override parse errors, they are always a user issue
* Minor error message rendering improvements to show multiple pieces of context
Dermot Duffy