Object detection labels are hardcoded too — package detections never reach Control4 #29

Same defect class as #28, but for visual detections — and already losing events on a live system

#28 found that hardcoded audio labels drift from Frigate's config. The same hardcoding exists for object detection, and unlike the audio case it is already dropping events in production.

Evidence from a live system

Frigate's resolved objects.track, per camera:

Union across the fleet: person, car, package.

The NVR driver subscribes to exactly four object topics (nvr-driver/driver.lua:285-288) and filters to the same four again in the handler (line ~417):

"frigate/+/person", "frigate/+/car", "frigate/+/dog", "frigate/+/cat"
...
if objType == "person" or objType == "car" or objType == "dog" or objType == "cat" then

So package is never subscribed to and never forwarded. Confirmed on the broker — these topics are live:

frigate/front_door/package/snapshot
frigate/front_door/package_detected

Package detection at the front door — a delivery notification, one of the more obviously useful things a camera can tell you — silently does nothing in Control4 today.

dog and cat are subscribed but tracked nowhere, so they are harmless no-ops. The mirror image of siren/music in #28.

Zones are affected identically

Zone subscriptions (frigate/+/+/person|car|dog|cat) carry the same four labels, so a package entering a zone is lost too.

There is dead code proving the intent

handleDetection() in the camera driver has a generic else branch that fires Object Detected / Object Left for any unrecognised object type, and friendlyObject() title-cases arbitrary labels. That branch can never execute, because the NVR filters to four labels before forwarding and does not subscribe to anything else. The camera driver was written to handle arbitrary objects; the NVR prevents it.

Per-camera overrides are real here

Worth noting for design: in #28 all 13 cameras inherited the global audio.listen, so a global-only read would have sufficed. For objects, 5 of 13 cameras override objects.track. Any fix must take the union across cameras, not just read the global list.

Proposed fix — same mechanism as #28

Derive both subscription lists from Frigate's config at discovery:

1. Parse objects.track per camera from the /api/config response the driver already fetches (nvr-driver/driver.lua:588), and subscribe to frigate/+/<label> and frigate/+/+/<label> for the union.
2. Drop the four-label filter in the handler; route unknown labels to the existing generic Object Detected path, which already exists and already produces sensible friendly names.
3. Keep person/car/dog/cat in a fallback list for when the config fetch fails.
4. Log the resolved label set at INFO on startup.

Measured cost of the equivalent parse for #28: 0.17 ms for a 13-camera union over a 150 KB config, with no additional network request. Object parsing is the same shape and the same order of magnitude.

Open question

person, car, dog and cat have dedicated events, variables and history types. Config-derived labels will not. Options: route everything unmapped through the generic Object Detected event (works today, no XML change), or generate per-label events dynamically (not possible — driver.xml events are static).

Suggest the generic path for arbitrary labels, and promoting package to a first-class event with its own variable given how common package detection is.

Related

• Audio detection type names don't match Frigate's labels — glass, shatter and car_alarm never reach Control4 #28 — identical root cause for audio labels. These should be fixed together; it is one mechanism serving both, and fixing one without the other leaves the same trap half-set.