v0.8.40

Switch on an entity that your own exclude globs hide

If you use exclude.entity_globs or exclude.domains in the Manual exclusions field, an entity matched by them could never be switched back on: the toggle went green and the recorder kept skipping it (#18). Switching such an entity on now writes it to include.entities, the one recorder rule that outranks a glob or domain exclusion. Everything else your globs hide stays hidden, and everything they don't match keeps recording as before.

• This only happens from the individual entity toggle. Select all and the device toggle deliberately leave glob-hidden entities alone, so a bulk action can't silently override your own globs.
• include.entities is only written while you still have a domain or glob filter configured. Without one, nothing is hidden anyway, and that key would turn your whole config into an allowlist.

What you'll notice after updating: entities hidden by your own globs or domains now show their toggle off, with a note underneath. Before, they showed on even though they weren't being recorded. Nothing changed in what gets recorded; the panel just stopped claiming otherwise. If you don't use globs or domains in the manual field, nothing changes for you at all.

Also

• One-click install button in the README (#22).
• The repository now lives at martinandersen84/gui-recorder. Old links redirect; the integration's manifest and codeowner now point at the new location.

v0.8.39

• SQLite db_url with URI parameters now works. A URL such as sqlite:////dev/shm/ha-ramdb/home-assistant_v2.db?journal_mode=WAL&cache=shared kept the parameters glued to the file name, so statistics reported Database not found. Contributed by @varhub in #20 — thank you.
• Easier to read tables. Rows now alternate their background and highlight on hover, as do device headers, so on a wide screen it is clear which toggle or purge button belongs to which row. Works in light and dark themes. Requested on the community thread.

v0.8.38

Fixes exclusions of entities that have no entity registry entry (sun.sun, sensor.date_time and other legacy YAML platforms without a unique_id) being reported as Unmatched configured exclusion once their records had been purged.

Those entities were only tracked while they still had rows in the database, so excluding one and purging its history made its exclusion look stale.

More importantly, Remove all unmatched computed its own list from the entity registry alone, so it deleted valid exclusions the panel displayed as matched — silently re-enabling recording for those entities after the next restart.

Reported by CaptTom on the Home Assistant community thread.

v0.8.37 — migration data-loss fixes

Two migration data-loss fixes

Both of these could silently replace your recorder configuration — including a custom database location — and cause Home Assistant to start a fresh empty database. If you have a recorder: block with anything non-default in it, update before migrating.

Migration steps could be run out of order (v0.8.37)

The three migration steps were independently clickable. Nothing stopped you from running Step 2 (Disable current recorder config) and Step 3 (Enable gui_recorder.yaml) without ever running Step 1 (Import).

Doing that replaces your entire recorder config with GUI Recorder's defaults — purge_keep_days: 10, no exclusions, no db_url — because gui_recorder.yaml is generated from storage that was never populated. If your database lives at a custom path, HA falls back to the default location and creates a new empty database, orphaning your history.

Steps 2 and 3 are now blocked until the import has run, both in the UI and server-side.

Fresh installs are unaffected — with no legacy config to import, Step 3 works as before.

Custom db_url was dropped on import (v0.8.36)

Even when you did run the import, a custom db_url (e.g. a database moved to /share) was never carried across into gui_recorder.yaml, so the same fresh-empty-database outcome applied.

Migration now captures db_url from your legacy config and writes it to gui_recorder.yaml. The migration summary shows the detected value, and the import confirmation notes that it was preserved.

If you already migrated on an earlier version, your stored config has no db_url. Either re-import with the legacy recorder: block active, or add db_url: back to configuration.yaml by hand alongside the !include. Existing installs without a custom db_url are unaffected — nothing is written.

Thanks to Frank_Beetz on the community forum for the report that led to both fixes.

v0.8.36

Bug fix: custom database location was lost on migration

If your recorder database lives somewhere other than the default path — set via db_url: in your recorder: block (e.g. a DB moved to /share) — migration silently dropped that setting. After the final restart, Home Assistant fell back to the default path and started a fresh empty database, orphaning your existing history.

The old database file wasn't deleted, so a backup restore recovers it, but this was effectively data loss for anyone without one.

Fixed: migration now captures db_url from your legacy recorder: block and writes it into the generated gui_recorder.yaml, so your database location survives the switch. The migration summary shows the detected db_url, and the import confirmation tells you it was preserved.

If you already migrated before v0.8.36

Updating alone won't restore the setting — there's nothing in storage to restore from. Either:

• Re-run Step 1 (Import) with your legacy recorder: block active, or
• Add db_url: <your url> back to configuration.yaml by hand, alongside the recorder: !include gui_recorder.yaml line.

If you never used a custom db_url, nothing changes — the generated file is byte-identical to before.

Thanks to Frank_Beetz on the HA community forum for reporting it.

v0.8.35

Brand asset fix

The integration's brand/ PNGs (icon, logo, @2x variants) were RGBA on disk but every pixel was fully opaque — the background rendered as white on HA / HACS cards instead of blending in like other integrations' icons.

Flood-filled the white background from the image borders (interior white of the config-panel graphic is intact), so the icons now composite correctly on any card color and theme.

No code changes. Version bump so HACS surfaces this as an update.

v0.8.34

Hotfix

If your legacy recorder config had entity_globs patterns starting with * (e.g. *_rx_*, *battery*), restarting Home Assistant after completing migration could fail with:

while scanning an alias, expected alphabetic or numeric character, but found '*'

The migration's auto-transfer in v0.8.32 correctly stored those globs (using yaml.safe_dump with proper quoting), but the writer that produces gui_recorder.yaml was emitting list items unquoted, so the leading * was getting parsed by YAML as an alias reference (*_rx_) and Home Assistant rejected the file.

Fix: the exclude:/include: blocks are now written via yaml.safe_dump, which quotes values with YAML-significant characters automatically.

If you were stuck on the migration restart, update to v0.8.34 and try again — no need to redo Step 1.

v0.8.33

What's fixed

The panel was re-rendering on every Home Assistant entity state change — dozens of times per second on active setups. This destroyed focus and selection on any input, making the new Manual exclusions (advanced) textarea practically unusable (reported in #5 after v0.8.32: focus disappeared in under a second, Ctrl+V did nothing).

set hass(hass) no longer triggers a re-render. The render is a pure function of our own state (data from WS, filter text, migration state) and never reads from hass.states, so those rebuilds were wasted work. Render is now triggered only by our own state mutations: after data loads, after user actions, after viewport changes.

This is also the underlying fix for the typing/expanding lag on large installs (#1) — the 250ms filter debounce shipped in v0.8.29 was a patch on a symptom; this addresses the root cause. The debounce stays as defense in depth.

v0.8.32

What's new

New Manual exclusions (advanced) field for the recorder filters that GUI Recorder doesn't manage per-entity, addressing #5.

Migration card

• Step 1 (import) now auto-transfers unsupported legacy filters (exclude.domains, exclude.entity_globs, exclude.event_types, include.domains, include.entity_globs) directly into the new Manual exclusions field — they were previously just counted and warned about, now they're carried over.
• The only filter type still lost on migration is include.entities (allow-list mode), which GUI Recorder can't represent. The UI calls this out explicitly.

Manual exclusions card

• Raw YAML textarea, merged into the generated gui_recorder.yaml alongside the per-entity exclusions.
• Allowlist: only exclude.{domains,entity_globs,event_types} and include.{domains,entity_globs}. Individual entities (entities: lists) are rejected — those stay exclusively managed by the device/entity toggles so the two systems never fight over the same list.
• Validated server-side: invalid YAML or unsupported keys never get persisted, you get an inline error instead.

Bug fix

• Migration card: hasUnsupported was not counting exclude.event_types, so the warning banner could be hidden when only event_types filters existed. Fixed.

v0.8.31

Bug fixes

• Live entities mislabeled as Obsolete/Unlinked (#4): entities without a unique_id — common on legacy YAML platforms like snmp, template, or command_line — never get an entry in Home Assistant's entity registry, even though they're live and actively recording. GUI Recorder's obsolete-detection only checked the entity registry, so these entities were incorrectly bucketed as obsolete.

  They're now cross-checked against live entity states. An entity with a live state but no registry entry is listed under Entities without a device instead, using its current friendly name when available. This also corrects the "Current records" / "Obsolete records" counts in the Database statistics card, which were previously counting these entities on the wrong side.