Bark Alerts

Frigate detects; Bark Alerts decides whether to request a beep

Frigate processing runs on my separate PC. Its Home Assistant integration exposes the relevant camera audio-detection entities. Bark Alerts watches those entities inside Home Assistant and evaluates a qualifying detection before calling the Broadlink remote action.

Frigate bark audio detection → my Bark Alerts integration → Broadlink RF transmitter → stored collar beep command

Bark Alerts does not run a new audio classifier or subscribe directly to MQTT. Frigate's event-driven entities depend on the shared MQTT broker connection described in the Frigate guide. The media and API paths have different responsibilities.

For a direct bark input, the integration responds to a new off-to-on transition. An initial or retained on state, an attribute update, or recovery from an unavailable state is not treated as a fresh detection. This avoids replaying an old state as a new request during startup or recovery.

The connections inside the monitor

Scroll the table horizontally to compare all four columns.

Controls that govern automatic requests

Arming and dry run

Armed is the main gate for automatic operation. Dry run permits observation without automatic RF requests. Both controls return to off after a restart, reload, options change or reconfiguration. Enabling dry run before arming is the observation workflow; arming with dry run off permits a request on the next valid event.

When both controls are on, a persistent Home Assistant notification explains that automatic transmissions are blocked. Arming does not replay earlier detections or request a startup beep. Disarming stops new automatic requests, but cannot cancel a command already handed to Broadlink.

Cooldown and overlapping detections

Selected cameras within one monitor share its cooldown and in-flight command limit. Busy events are discarded, and the integration does not queue a delayed beep or automatically retry a failed request. Other monitor entries and unrelated automations have separate controls, so their combined behavior must be considered.

Configured repetitions belong to one command request. The request counter does not measure the number of RF packets or audible beeps. Increasing repetitions changes what is requested; it does not provide receiver confirmation.

The manual test is an explicit transmission request

Test beep bypasses arming and dry run, although it still respects cooldown and can fail. Verify the actual receiver with the collar off the animal. Never learn or automate shock or vibration commands through Bark Alerts. A wrong packet could trigger either one, and a label saying beep, or the setup confirmation checkbox, cannot establish the captured packet's effect.

Audio history is a separate review path

I have optional bark audio history enabled. It retrieves a short interval from existing Frigate recordings, roughly five seconds before and after the bark event, then uses FFmpeg on the Home Assistant host to create an audio clip. Recording segment boundaries can affect the captured interval.

This uses a separately configured connection to Frigate's documented HTTP API. It does not borrow the Frigate integration's private client or change the server's recording and retention settings. Existing recordings must contain audio, and the configured account must be able to access the relevant cameras.

The history keeps the latest 25 bark episodes for a monitor, including events while disarmed, in dry run or in cooldown. Failed captures count toward that episode limit, so it is not a promise of 25 playable clips. Manual tests and animal-sound fallback are not recorded in this history.

Clips are stored in the integration's private storage outside the public web directory and played through authenticated or temporarily signed Home Assistant media access. They can contain household conversations and may be included in backups. No recordings or playback links are published on this site.

Capture failure is reported separately. It does not interrupt the command decision, retry a transmission or queue a later collar request. Turning history off retains existing clips; the separate clear-history control removes them. The project documentation explains retention, capture status and API setup.

A sound label is not an identified animal or a confirmed result

Animal-sound fallback is optional, and its visual check is a separate setting: Require a dog seen on the same camera for animal sounds. That check is on by default when fallback is enabled. I turn it off because my camera is not always looking at where it would see the dog, so requiring a sighting would keep fallback from firing. With the check off, other animal sounds can also trigger a request.

A camera that always covers the area where the dog would be can leave the check on. Fallback then needs a dog recently seen on that camera, which narrows the trigger set. Direct bark detections never require a visual dog detection, with the check on or off.

This is a deliberate distinction between a camera hearing a classified sound and establishing which animal made it. Frigate can misclassify audio. Neither the direct bark path nor fallback identifies a particular dog, and neither should be treated as an animal-welfare assessment.

My published compatibility report concerns the tested beep function on a FunniPets collar. It does not validate every model, multi-collar operation or other command modes. Broadlink RF compatibility and the command's actual behavior must be established for the intended receiver.

A command-request outcome means the service returned without raising an error to Bark Alerts. Broadlink may log some failures without raising them, and the RF receiver provides no end-to-end acknowledgement here. Detection, request submission and an audible beep remain different observations.

The collar has one catch. Its receiver goes into standby after about 5 minutes with no operation and wakes when it is moved. A request sent during standby can produce no beep, while Home Assistant still reports a requested command. This is how the collar behaves, not a fault in Bark Alerts. It mostly shows up when a collar sits still, such as on a shelf during testing, and a dog that has been resting for more than 5 minutes could miss the first beep.

Follow the outcome through the gates

I first check the selected source's recent transitions and the monitor's current controls. Last outcome describes the previously processed event; it does not replace checking whether the monitor is armed now. A source remaining on is also different from a new off-to-on detection.

Next I distinguish a blocked outcome, such as dry run or cooldown, from a command request. For an unavailable source or remote, I investigate that connection. For a requested command without an observed beep, I check the Broadlink path and receiver separately, with any manual verification performed off the animal.

History has its own checks: recording availability, an audio track, API access and FFmpeg conversion. A history failure does not explain every missing beep, just as a playable clip does not establish that a command was sent.

The Bark Alerts repository contains installation instructions, the current controls and verification guidance. The Broadlink guide covers the output device independently.