You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
Folder mode is available in the Home Assistant app. The directory watcher has existed
in the standalone service since 0.23.0, but the app never offered it: no folder options, frigate_url was mandatory, and /media and /share were not mounted at all — so even a
hand-written path could not be read. Requested in #31 by a user with five Reolink cameras
and no Frigate, uploading snapshots to /media over FTP.
frigate_url may now be left empty. An empty URL means no Frigate: the service falls back
to a no-op client, and the gallery, unknown review and history stay usable.
/media is mounted read-only and /share writable — the latter only so gallery
backups can be written there, see below. FaceID never changes or deletes what it watches,
and no other host path is visible to the app.
The app now refuses to start with neither input configured, and warns on start when folder_path does not exist inside the container — naming the two mounted roots, since a
path the app cannot see is the likeliest mistake.
In folder mode the camera sensor appears at startup, not only after the first
recognition. The folder has no camera list to query, so its name is taken from the
configuration; without that a fresh install looked like it was doing nothing.
Home Assistant backups of the app shrink by roughly 600 MB. The recognition model
cache was stored in every backup although it re-downloads by itself on the next start; backup_exclude now leaves it out. Reported in #33 with measurements: 1.1 GB compressed
for an app whose irreplaceable data is about 11 MB.
backup_dir is settable in the app, and /share is mounted writable for it. Pointing
the built-in gallery backup at /share/faceid puts it where Home Assistant's own backups
already look — a few MB for the one thing that cannot be re-created. /media stays
read-only: it is a source, never a target.
A backup target that cannot be written is refused right away — at start-up, when you
save it in Settings, and on a manual backup — instead of letting every nightly backup fail
into the log, which is a failure you discover when you need the backup. The check writes a
real probe file and removes it again, because /media is readable and only the write
attempt reveals that the mount is read-only.
The target must also resolve inside a mount that survives an update (/data or /share in the app). A typo like /shre/faceid is writable inside the container but lives
in the overlay filesystem, so the archive would vanish with the next update — a backup that
looks like one and is not. Paths are resolved first, so .. segments and symlinks cannot
step outside. Standalone installs have no such boundary and stay unrestricted.
A failed backup can no longer cost a good one. The archive is written under a temporary
name and moved into place only once complete: a write that breaks off (no space, I/O error)
used to leave a truncated faceid-backup-*.tar.gz behind, which — being the newest — made
the rotation discard a valid older backup.
Settings and "Back up now" show the reason when a path is rejected. Saving an unusable path
previously produced no message at all.
Fixed: a folder camera suppressed Frigate discovery. With both inputs configured and no
explicit camera list, only the folder sensor was announced.
Still open from #33: the app image itself (~1.4 GB) is in every backup because the app is
built locally. That needs prebuilt images and is tracked separately.
Fixed: three options were settable and inert.cross_risk_margin, self_outlier_ratio
and history_keep were offered by the app and read by the service, but run.sh never
wrote them into the generated config — the same defect as #24, in three more fields. Found
by a new test that checks every option reaches the generated file.