Frigate

Separating camera processing from home automation

The separate PC runs Frigate's video ingestion, configured detection pipelines and recording services. Home Assistant connects to that server to expose supported camera entities, detection state, media and controls.

This keeps Frigate processing off the Raspberry Pi. Camera views, notification clips and media playback can still pass through Home Assistant, depending on how they are accessed.

The boundary is about responsibility: Frigate manages camera processing and recordings; Home Assistant makes that information useful alongside the rest of my home. Optional Bark Alerts audio-history conversion is a separate task that runs on the Home Assistant host.

Bringing different camera sources into Frigate

Local RTSP cameras

My local cameras provide RTSP streams over the local network. Frigate consumes those streams on the separate PC and applies the recording and detection settings configured for each camera.

These are the native local camera inputs in my setup.

Ring cameras through my Ring MQTT fork

My Ring MQTT fork provides an RTSP gateway for Ring camera video, allowing those cameras to join the same Frigate setup.

The gateway depends on Ring's cloud service. Exposing an RTSP endpoint on my network does not turn a Ring camera into a native local camera or guarantee an uninterrupted stream. Availability still depends on the camera, the bridge, the internet connection and Ring's service.

My project builds on Ring MQTT (opens in a new tab).

Blink cameras through my experimental BlinkBridge fork

I use my experimental BlinkBridge fork (opens in a new tab), based on Roger's BlinkBridge project, to make Blink footage available to Frigate over RTSP.

In clip-based mode, it publishes a new clip and then holds the final frame between updates. The fork also includes logic to recover new clips that the motion flag missed, using media responses already retrieved from Blink.

An experimental Live View option provides another path, but it should not be read as a guarantee of continuous footage. Live View and aggressive polling can increase battery use and encounter service limits.

This connection remains dependent on Blink's cloud service. A persistent RTSP endpoint does not necessarily contain fresh camera frames.

How Home Assistant connects to Frigate

The official Frigate integration uses a direct server connection alongside a shared MQTT broker. Live camera viewing also requires access to the relevant streaming endpoint.

Scroll the table horizontally to compare all four columns.

These are typical endpoint examples, not my household addresses.

Port 8971 is Frigate's authenticated endpoint, with TLS enabled by default. Home Assistant needs a working HTTPS connection with a certificate it can validate.

Port 5000 is a separate internal, unauthenticated HTTP endpoint. Using that endpoint does not require disabling TLS on 8971. Likewise, disabling TLS on the authenticated endpoint changes transport encryption, not authentication.

Frigate's MQTT configuration and Home Assistant's MQTT integration must use the same broker. A successful API connection does not replace the MQTT dependency, and MQTT does not carry the live camera video.

The official Frigate integration documentation (opens in a new tab) covers these connection requirements.

My Bark Alerts integration

I built Bark Alerts to connect Frigate's bark audio detections to a compatible training collar's learned beep command through an RF-capable Broadlink device.

The workflow is:

Frigate bark audio detection → Frigate integration's Home Assistant sensor → Bark Alerts → Broadlink RF transmitter → learned collar beep request

Frigate publishes detection state through MQTT. The Frigate integration exposes that state in Home Assistant, and Bark Alerts watches the configured entity state changes. Bark Alerts does not subscribe directly to MQTT.

This is an event-driven workflow. Sending a command does not confirm that the collar received it or establish the animal's response.

The Bark Alerts guide covers arming, dry run, cooldown and the limits of a sound label.

Manual testing and command verification

The explicit Test beep action requests RF transmission even when Armed is off or Dry run is on. It still respects cooldown, and a request can fail. The action is not proof that the collar received the command.

The intended output is a beep only. Software cannot inspect a learned RF command and establish whether the receiver will beep, vibrate or deliver a shock. The command must be tested with the collar off the animal, and its actual response verified before automatic operation. That verification needs repeating if the command, receiver, channel or configuration changes.

Optional bark audio history

Bark Alerts also supports optional local audio history for reviewing detected bark episodes. This is a configurable feature, not a requirement for sending collar commands.

When enabled, it requests approximately five seconds before and five seconds after a bark from the triggering camera's existing Frigate recordings. Those recordings must contain audio. Recording-segment alignment can affect the captured boundaries.

The integration retrieves the clip through Frigate's documented HTTP API, independently of the Frigate Home Assistant integration's internal client. It then uses FFmpeg on the Home Assistant host to convert the downloaded media into a mono 16 kHz WAV file.

History retains the latest 25 bark episodes for a monitor. Failed captures count toward the episode limit, so 25 retained episodes do not necessarily mean 25 playable recordings.

Capture failures do not interrupt, retry or queue collar commands. The Bark Alerts guide and the project's audio-history documentation (opens in a new tab) cover storage, privacy and capture status.

Switching profiles from presence

Frigate's profiles (opens in a new tab) are named sets of per-camera overrides that can be switched while Frigate runs. A Home Assistant automation chooses one of three from presence: away when nobody is home, night when someone is home overnight, and home the rest of the time. Away outranks night, so an empty house overnight keeps its away settings. The automation publishes its choice on Frigate's MQTT profile topic.

Frigate's documentation says switching a profile clears runtime toggle overrides. In my setup, a real profile change put cameras back to their configured enabled state a few seconds later, measured on September 18, 2026. That matters for the on-demand cameras in the next section.

The profile choice starts with Home Assistant's person tracking and uses a vehicle state as a tie-breaker, so a wrong presence reading can pick the wrong profile.

Battery cameras that stream only on motion

Some of my Ring cameras run on batteries. Keeping their streams open for Frigate all the time would run those cameras continuously, so an automation keeps each one's Frigate camera switched off and turns it on only while Ring reports motion, using Frigate's per-camera enabled topic over MQTT.

In my setup, these battery cameras can return to their configured enabled state after Frigate restarts or a profile change clears runtime toggle overrides. The automation therefore reapplies the disabled state after Frigate comes online and after profile changes. It never disables a camera while Ring still reports motion.

Frigate's view of these cameras starts only once Ring's motion event has arrived through Ring's cloud and the stream has opened, so the first moments of an event are not in Frigate. I have not measured how much battery this saves.

Checking that Frigate is still recording

Recording check

A timer on the Frigate PC checks how old each covered camera's newest recording segment is. When it is older than five minutes, the camera is reported as not recording, and a Home Assistant automation sends a phone alert, then another when the camera recovers. A separate watchdog does the same for the Blink bridge and restarts the bridge itself. A camera left out of the check is not watched.

MQTT link watchdog

On September 24, 2026, Frigate's MQTT connection went silent for about five hours, and alert pushes were lost. The next day I added a watchdog on the Frigate PC: if Frigate's MQTT link looks dead for three checks in a row, a minute apart, it restarts Frigate, with limits on how often it may do so, and Home Assistant turns its event into a phone notice.

It has not been proven against a real hang. Its decision logic and a live dry run were checked on September 25, 2026, but the failure it was built for has not been observed under it. Its notice automation last ran on November 3, 2026, and I have not examined what prompted that event.

Offline backstop

If Frigate's retained availability status stays offline for six minutes, which a watchdog restart should prevent, Home Assistant sends a separate alert that camera alerts are not being sent. It was last triggered on October 24, 2026, inside the period when my phone notifications were failing because of a phone rename. If it sent an alert then, the alert could not have reached me.

Why this arrangement fits my build

Frigate gives my different camera sources a common place for processing and recording. Home Assistant connects their detection state and supported controls to the wider home.

Running Frigate on a separate PC lets me manage its workload independently of the Raspberry Pi. The API connection supports server functions, MQTT carries detection updates, and streaming connections deliver camera video. Bark Alerts builds on the resulting Home Assistant entities, with optional audio history providing a way to review detections afterward.