Audio detection type names don't match Frigate's labels — glass, shatter and car_alarm never reach Control4 #28

Problem

The NVR driver's audio subscription list uses type names that do not match the labels Frigate actually publishes. Three audio detection types configured on a live system can never reach Control4 — silently, with no error.

Found while verifying #23.

Evidence

Frigate's own config (GET /api/config → audio.listen) on the reference system:

bark, fire_alarm, scream, speech, yell, glass, shatter, car_alarm

The driver subscribes to (nvr-driver/driver.lua:296-304, mirrored in AUDIO_DETECTION_TYPES at line 272):

speech, bark, scream, yell, fire_alarm, glass_breaking, siren, car_horn, music

Comparison:

Coverage: 5 of 8 configured detection types. Glass breaking and car alarms — arguably the two highest-value security audio events — are among the three that are lost.

Impact

Silent. Frigate detects the sound and publishes to frigate/<camera>/audio/glass; nothing subscribes; no event fires, no history entry, no Last Event update, no log line. Anyone with glass or shatter in their listen list believes it is wired up when it is not.

Note that the driver already declares Audio: Glass Breaking and Audio: Car Horn as events in driver.xml, and registers them with the History agent — so the events exist in Composer's programming UI and simply never fire.

Cause

The names appear to have been chosen from the YAMNet class list or from Frigate's documentation rather than from a live audio.listen config. Frigate publishes on frigate/<camera>/audio/<label> where <label> is exactly the string in audio.listen.

Proposed fix

1. Add the missing subscriptions and whitelist entries: glass, shatter, car_alarm.
2. Keep glass_breaking, siren, car_horn, music — they cost nothing and may be valid labels on other Frigate versions or configurations. Removing them risks breaking someone whose config does use them.
3. Map the new labels onto the existing friendly event names so no new Composer events are needed:
   • glass, shatter → Audio: Glass Breaking
   • car_alarm → Audio: Car Horn (or add a distinct Audio: Car Alarm event — needs a decision, since adding an event means a driver.xml change and a new registered history type)
4. Consider driving the subscription list from Frigate's audio.listen config at discovery time instead of a hardcoded list, which would make this class of drift impossible. Larger change; worth weighing separately.

Verification

audio.listen labels come from Frigate's config, and the topic tree is confirmed to use the label directly (rms and dBFS publish on the same frigate/<camera>/audio/ tree). A live glass/shatter/car_alarm detection has not been observed to confirm the topic string end-to-end — worth doing before or alongside the fix, e.g. by publishing a test message to frigate/bbq/audio/glass and confirming the driver reacts once subscribed.

Related

• Bug: Spurious 'Audio: Rms' events flooding Last Event on every camera #23 — the flooding fix that introduced this explicit subscription list. That fix is correct; this is a gap in the same list.