Per-camera history registration is lost on any camera-driver restart #30

@mattstein111

Blocks release of the config-driven detection labels work (#28, #29)

The work on branch feature/28-29-config-driven-labels makes each camera driver register exactly the history event types it can emit, based on the detection labels the NVR forwards to it. That registration is lost on any solo camera-driver restart, and never restored until someone takes a manual action in Composer.

Why

sendCameraConfig() — the only thing that sends a camera its labels — is called from exactly two places in nvr-driver/driver.lua:

1. handleAdoptResponse(), when a camera is first adopted
2. inside discoverCameras(), which runs only from the manual Composer actions Create Cameras, Discover Cameras, Rename Cameras and Sync Camera Names

The NVR's own OnDriverLateInit() calls reconcileCameras() (prunes stale entries only) and adoptOrphanCameras() (pings only devices not yet in the managed list). Neither resends configuration to already-managed cameras.

Consequence

After a camera driver restarts on its own — a hot-reload, a controller reboot, or this project's own auto-update self-install flow — a previously working camera falls back to registering only the static event types. Person Detected, Car Detected, Package Detected and the specific Audio: * types are then recorded but not registered.

Control4's Navigator renders a history entry only when its type matches a registration, so those entries are stored correctly and never displayed. That is the same failure class as #24, which took four releases to diagnose — reopened at every routine update, and silent.

Why this is not a defect in the branch

Each task on that branch was reviewed clean. This is a gap in the cross-driver design, which I wrote: the plan scoped the camera-side task away from nvr-driver.lua, so no implementer was in a position to see or fix it. It was found by the Task 6 reviewer tracing the call graph further than the question asked.

Candidate fixes, in rough order of preference

1. Camera persists its own labels. The camera driver saves the label list with C4:PersistSetValue when config arrives and restores it in OnDriverLateInit. Self-contained in one driver, no new cross-driver protocol, and it survives a camera reload regardless of what the NVR is doing. The NVR already uses PersistSetValue for its managed-camera table, so the pattern is established here.
2. NVR resends config to all managed cameras on its own init. Smaller, reuses existing plumbing — but only helps when the NVR restarts. A camera-only hot-reload, which is exactly what auto-update does, still loses its registration.
3. Camera requests its config from the NVR at init. Cleanest protocol, but needs the camera to know its parent device id and a new inbound command on the NVR — the most new surface area for the same outcome as option 1.

Whichever is chosen needs a regression test that a camera restarting with no fresh SET_FRIGATE_CONFIG still ends up with its full registration.

Status

The branch is deliberately unreleased. No tag and no GitHub release exist for it, so no installation can auto-update to it. The work is recorded in an ## [Unreleased] CHANGELOG section.

Related

• Audio detection type names don't match Frigate's labels — glass, shatter and car_alarm never reach Control4 #28 , Object detection labels are hardcoded too — package detections never reach Control4 #29 — the work this blocks
• Bug: Camera history icon in C4 app shows empty despite recorded events #24 — the same recorded-but-unregistered failure class, and how it presents