Home Assistant Full-Estate Audit — 27 Oct 2026

Home Assistant — Full-Estate Audit

Date: 27 October 2026, ~18:20 GMT
Scope: Home Assistant and its connected home stack, including the external Frigate server, HA-managed apps, automations, registries, dashboards, safety coverage, public route and monitoring.
Method: HA MCP snapshots, direct HAOS SSH reads, one read-only Zigbee function report, live Frigate stats/config GETs, public unauthenticated HTTP checks, and the current five-day HA error log window. No automation or alarm was fired during the audit. The Portal Mini automation was changed afterward at Joe’s request; that change is recorded below.

Verdict

The HA core is healthy and the automation estate is internally consistent. The urgent issue is that an unauthenticated request to an existing file under /local/ on the public HA hostname returned HTTP 200. /config/www contains about 720 MB across 3,603 files, so at least some HA-local media is reachable without login; the entire directory needs treating as public until proved otherwise. The second material finding is a Frigate retention drift: the live config keeps alerts/detections for 7 days, but keeps neither continuous nor general motion footage. That may be deliberate, but differs from the 7-day motion-retention target recorded after the October Frigate change.

Change made after the audit — 27 Oct 2026

Item	Status	Verified result
Portal Mini display stayed on overnight	✅ DONE	automation.portal_mini_night_mode now turns light.facebook_portalmini_screen off after applying its night screensaver settings, and turns it on at 08:00 with the observed daytime brightness (204/255). HA configuration check passed, automation reload succeeded, and read-back shows the automation is on with both actions present. The automation was not run manually; the next scheduled overnight trigger will prove physical behavior.

Portal+ and Portal Go remain unavailable, and this automation does not target them.

P1 — address first

1. Public HA route serves an existing /local file without authentication

• A plain unauthenticated GET to the public HA hostname for an existing file under /local/ returned HTTP 200. The probe discarded the response body and did not expose the filename.
• /config/www currently contains 3,603 files / 720.4 MB. The /local path maps to that directory, so other files may also be reachable when their paths are known.
• This is separate from the HA login page. A public login page can be intentional; public static files may include doorbell snapshots or other private media.
• Recommendation: treat /config/www as internet-accessible. Move private images/media out of it or block /local at the public route. Then retest a known existing file without cookies and confirm it no longer returns 200.

P2 — fix or explicitly accept

2. Frigate is not retaining general motion footage

• Frigate 0.18 API is live; both cameras are enabled, detection is enabled at 5 fps, and the stats endpoint reports active frame processing. HA’s doorbell and garden detection, motion, recording and review switches are on.
• Effective global recording config: recording enabled; continuous.days: 0, motion.days: 0; alert and detection retention are each 7 days, mode motion.
• Frigate’s current documentation says zero disables continuous/motion retention. With these values, ordinary motion without a retained alert/detection is not kept. This matches an alerts/detections-only policy, but differs from the previous recorded target of 7 motion days. Because recordings may matter as evidence, confirm that event-only retention is intended before changing it. Frigate recording retention reference

3. Several ESPHome devices are unavailable

• 8 ESPHome devices / 307 entities currently report unavailable. They include the Sproom blind controller and several presence sensors; Portal devices account for many of the entity rows. The recent HA log also showed recurring ESPHome reconnect failures.
• The three blind entities on the Sproom controller are unavailable, so blind controls and position feedback are not currently usable through HA. Prioritize those and the room-presence devices; confirm whether the Portal endpoints are still wanted.

4. Roomba integration is still retrying setup

• Roomba is the sole non-ignored integration entry in setup_retry (94 entries total: 88 loaded, 5 intentionally ignored, 1 retrying).
• The five-day log window contained 2,196 connection errors for the vacuum. HA automations unrelated to the vacuum remain loaded.

5. Fellow kettle reauthentication loop and phone notification errors

• The five-day error log contained 472 Fellow unauthorized/reauthentication warnings.
• It also contained 29 mobile-app notification errors. I did not send a test notification, so actual delivery to the phone is unverified. This affects doorbell/safety notifications if they depend on the failing target.

6. Stale restored registry entries need a controlled cleanup pass

• HA’s live dead-entity check reports 0 config-entry orphans and 80 stale-restored entities. The first returned page contains 50, including obsolete HACS update entities, old Cast names, and several superseded ESPHome/Reolink entities.
• This is registry cruft, not evidence that all 80 are currently breaking automations. Do not bulk-remove them without checking references first.

7. Some current dashboard cards point at unavailable entities

• The five explicit dashboard entries plus the default view account for 6 dashboards, 10 views and 43 frontend resources. The current main dashboard has no missing entity IDs, but Watchman reports 7 unavailable references and 1 unknown battery value: Portal screens, DE1 status, two blind entities, lounge motion and the kitchen smoke battery sensor.
• The kitchen smoke battery entity is known not to provide a numeric battery level. The smoke alarm entities themselves are present and currently clear.
• Watchman also reports four missing references in an archived dashboard backup file; those are not used by the active dashboard.

8. MQTT retained/discovery census remains incomplete

• The broker rejected an anonymous MQTT connection (CONNACK 5, not authorized), which confirms anonymous clients cannot connect on the tested LAN route.
• Zigbee2MQTT’s read-only function audit found 53/53 devices OK. Its recent log snapshot had 55 MAC_NO_ACK messages and no NWK_TABLE_FULL entries. These radio messages did not correspond to a failed device in the functional check.
• I did not enumerate retained MQTT topics or test authenticated broker access in this pass, so orphaned retained discovery topics and credential/TLS posture are not certified here.

P3 — housekeeping

• Only 32 of 228 devices have an area; 196 are unassigned. The unassigned set includes 113 service-type devices and 83 with no entry type, so this is partly registry noise. Assign the physical room devices first if room-based dashboards or voice targeting matter.
• HA’s health API returns 6 dashboards while the dashboard listing returns 5 explicit entries; the sixth appears to be the default view. No active dashboard entity reference is genuinely missing.
• The HA Cloudflared add-on is stopped, but the public hostname responds and the tunnel is served by the host-level Cloudflare route. This is not a current availability failure.
• Two SSH/terminal add-ons are installed and started. Consider whether both are needed; no change was made.

What’s solid — directly checked

• Core 2026.10.4, Supervisor 2026.10.4, HAOS 18.3; HA reports healthy, host and Supervisor connectivity are true, NTP is synchronized, disk usage is 60.2 / 219.4 GB, with zero active repairs and zero notifications.
• HA configuration check is valid. 58 YAML automations match 58 live automations by ID; all are on. Six scripts and zero scenes were found. The structured and Jinja entity-reference sweeps found zero dead references.
• All seven water-leak sensors are included in the leak detection, wet-since, clear and escalation automations. All seven currently read dry. Both smoke automations are armed and both smoke sensors currently read clear. No alarm test was run.
• The broad all lights off script is scoped to lights and intended lamp switches; both light groups resolve to live members. The September kitchen pendant group omission is fixed.
• Zigbee functional report: 53 devices OK. No routing-table-full signature appeared in the inspected Z2M log window.
• Energy Dashboard configuration references grid, solar, battery, gas and washing-machine consumption statistics. Solar, battery and washing-machine statistics have current state and recent recorder statistics. sensor.power_sys_load does not exist, so no conclusion is made about that older derived metric.
• Three local backup tarballs match the three current Supervisor registry entries; local /backup is 10.9 GB. The same-day whole-stack pass confirmed encrypted off-host B2 copies for 25–27 October. Backup and Zigbee/HA health watchdog jobs all report successful latest runs, zero failure streak and a scheduled next run.
• The public /local probe returned HTTP 200 for an existing file without authentication. No file contents were downloaded; treat the directory as exposed until its contents and route are secured.

Baseline changes since 22 September

Area	22 Sep baseline	27 Oct check
Core	Core 2026.9.3 / HAOS 18.2	Core 2026.10.4 / HAOS 18.3; healthy
Automations	49	58, all matched and on
Live entities	1,011	1,474
Devices	211	228
Light groups	Kitchen pendant missing	Both groups contain the intended kitchen light switch
Deleted registry entities	111 removed in September	0 deleted_* entries in current registry snapshot
Tailscale	Logged out / NeedsLogin	Add-on started; current log has no logged-out signal
Leak coverage	Three leak sensors offline	All seven leak sensors included and currently dry
Backups	Eight untracked old archives removed	Three local registered archives; offsite copies checked 25–27 Oct
Public media	/local exposure previously flagged	Reconfirmed: existing /local file returns HTTP 200 without login
Frigate retention	Motion retention target recorded as 7 days	Live config reports motion 0 days; alerts/detections 7 days

Numbered next actions

1. Restrict or empty public /config/www — I can help trace the Cloudflare/HA route and identify which files belong outside it; this changes remote access and needs your approval.
2. Decide Frigate retention — restore 7-day motion retention if you want general motion footage, or explicitly keep event-only retention; changing it affects storage and footage.
3. Restore the blind/presence ESPHome devices — check power/network and device logs, starting with Sproom and bedroom presence.
4. Fix Roomba and Fellow connectivity — reconfigure/reload the affected integrations after confirming their network/account access.
5. Run a phone notification test — only after you approve a real push to your device.
6. Review stale-restored entries — remove only after reference checks; no bulk cleanup.
7. Finish MQTT topic census — requires authenticated read access; anonymous access is already confirmed blocked.

My pick: do 1 first because it is the direct privacy exposure, then decide 2 before making any recording-policy change.