The Frigate Home Assistant integration: MQTT for state, HTTP for everything else

What the component actually puts into Home Assistant

The feature list is short enough to read as a specification, and it divides into three kinds of entity. The sensors report the pipeline rather than the house: camera frames per second, detection frames per second, process frames per second, a skipped frames per second figure, and a count of objects detected. There is one binary sensor, for object motion. Then there are camera entities, described as a live view and an object detected snapshot, and a media browser with thumbnails and navigation. Finally, and most consequentially, there are four switches: recording, detection, snapshots, and improve contrast. Alongside them sit services for controlling a camera, covering manual events and pan, tilt and zoom. Multiple Frigate instances are supported, so one Home Assistant can hold several. Read together, that is a component whose job is not only to show you what the NVR saw but to let Home Assistant change what the NVR does. A dashboard of numbers is a much easier thing to build than a switch that turns recording off, and the switch is the part with consequences for a household, so it deserves the attention that the sensor list tends to get in installation guides.

Two transports: MQTT for state, HTTP for media and for control

The requirements file is the best architecture diagram in the repository. It names an MQTT client library alongside an HTTP client, a CORS extension for the HTTP server, a queue library, and a small library whose name says web proxy. Put together with the README, that gives two distinct paths. Events and state arrive by MQTT, which is why the Home Assistant MQTT integration has to be present and configured before this one does anything, and why the README notes that the manual work in setting up a broker cannot be automated from here. Media and control go the other way, over HTTP: snapshots, clips, the thumbnail browser and every switch press are requests to Frigate, served through the CORS handling and the proxy library the component brings with it. That second path is the one people miss when installation appears to hang, since a working broker gives you sensors and switches that report stale values with no visible error if the HTTP side is unreachable. The queue dependency sits underneath both, which is consistent with a component that has to reconcile a stream of incoming events with a state it also fetches on demand. One more prerequisite is easy to overlook: the media source integration has to be enabled in the Home Assistant configuration, and until it is, the media browser simply is not there, with no error explaining why.

HACS copies the files; the integration and the broker are still yours

Installation through the community store is three clicks in a menu: open HACS, go to Integrations, explore and add repositories, and pick Frigate. The README then states two limitations in plain language, and both are the kind that cause a support thread. The first is that HACS does not configure the integration, so the files land in your configuration directory and nothing appears until you open the Home Assistant configuration screen, go to Integrations, and add Frigate yourself. The second is that the MQTT integration must be installed and configured, and that because it needs manual configuration it cannot happen automatically. In other words, the one click install is one third of the work. For advanced users there is a manual path that is more honest about what the component is: copy the frigate directory from custom_components into your own custom_components folder. That is the entire mechanism, a custom component dropped into the directory Home Assistant loads integrations from, and it explains both the flexibility and the fragility. Flexibility, because anything in that directory is picked up without a package manager. Fragility, because a custom component is not a plugin against a public interface, it runs inside Home Assistant and uses internals, so a core release that moves those internals is a compatibility problem for you rather than a changelog entry. The requirements file shows the coupling directly, with a single Home Assistant release pinned exactly for development.

The switches are the sharp edge: Recording, Detection, Snapshots, Improve Contrast

Of everything on the feature list, the four switches deserve the most careful reading, because they are write operations against a running detector. Recording and detection are the two that matter operationally. A switch that turns recording off stops evidence being captured, and a switch that turns detection off stops objects being noticed, which in a household with pets or a driveway means the difference between a useful camera and an expensive picture frame. Nothing in the README describes confirmation prompts, permissions or an audit trail, because those are Home Assistant concerns rather than this component's, and that is exactly the point: the safety behaviour is whatever your automations and your dashboard give you. Improve contrast and snapshots are lower stakes, and the second one is a useful thing to have on a switch, since turning snapshots off is the standard way to stop a camera filling a disk. The services sit in the same category. A manual event service is how a person or an automation says something just happened, and pan, tilt and zoom turns a camera into a controllable device, which is the feature that most often pulls a user toward hardware that supports it. All of these are HTTP calls rather than subscriptions, which means they can fail, and the README documents no retry or failure state for them.

The alternative: generic MQTT sensors, and what you give up

There is a version of this that involves no custom component at all. Home Assistant has a built-in MQTT integration, Frigate publishes its state as MQTT topics, and an MQTT sensor with a value template will turn a payload into a number. That path has two real advantages. It survives changes on either side, because it depends on a topic and a payload rather than on Home Assistant internals, and it costs nothing to maintain. What it cannot give you is anything that requires a request rather than a subscription. A thumbnail media browser is a browse of Frigate's media tree. A live view and an object detected snapshot are cameras, not numbers. A switch is a write, and a write to Frigate means an HTTP call that the generic path has no way to express, regardless of how clever the template is. The custom component exists to provide exactly this set, and the value scales with how much of the feature list you use. Someone who wants detection counts on a dashboard has a choice and can reasonably pick the simple route. Someone who wants the recording switch in an automation, a camera entity in a view, and a manual event button next to the door sensor cannot. The version coupling argument runs the same way in reverse, and it is not hypothetical: a component pinned to one Home Assistant release for its development is a component whose behaviour on the next core release is untested until someone runs it.

A dev stack with a privileged Frigate, a broker and a preconfigured Home Assistant

The development environment is a compose file in the repository, and it is more informative than it looks. It runs four services. A devcontainer is built from a Dockerfile in the .devcontainer directory and mounts the Docker socket, which is how the stack manages the containers underneath itself. Home Assistant comes from the published image with a version taken from an environment variable defaulting to latest, and it is preconfigured by a shell script dropped into the container's init directory along with a directory of configuration fragments. Frigate runs privileged with the USB bus and the DRI device nodes passed through, which is the hardware access object detection needs, and with an environment flag allowing arbitrary execution in its streaming component. A broker runs as Eclipse Mosquitto on version 2 with its own configuration file mounted. Two comments in the file explain a decision worth copying into your own setups: rather than mounting whole configuration directories, individual files are mounted read only so that data is not persisted between runs. The version pins live in an example environment file, with both the Home Assistant and the Frigate versions present but commented out, so the default is whatever the images consider current.

    frigate:
      privileged: true
      image: "ghcr.io/blakeblackshear/frigate:${FRIGATE_VERSION:-stable}"
      restart: unless-stopped
      devices:
        - /dev/bus/usb:/dev/bus/usb
        - /dev/dri:/dev/dri

MIT, three maintainers, and user documentation hosted on Frigate's site

Two things about how this project is run are worth knowing before you depend on it. The first is documentation. The repository has no user documentation of its own, and the README sends you to the central Frigate documentation for full installation and usage instructions, and to the media source and MQTT pages on the Home Assistant site for the prerequisites. That is a reasonable division of labour for a component that is really part of a larger system, and it also means the component's behaviour is documented by people who did not write the code, so edge cases may be described in terms the component does not implement. The second is the release record. The last push was on 2026-09-12, and the recent releases are v5.15.4 on 2026-06-04, v5.15.5 on 2026-08-28 and v5.15.6 on 2026-09-03, a five line minor version with three patch releases inside a quarter, which is the shape of a project that ships when a fix lands. Three people are named as maintainers, and the licence is MIT, so the code carries no obligations beyond attribution and the components directory is ordinary source you can fork. The repository also has a test suite with coverage reporting, a pre-commit configuration, separate development requirements, and an editor configuration, none of which changes what the integration does but all of which indicate that the component is worked on rather than merely published.

Editorial conclusion

Install this component if your cameras already run Frigate and you want detection, recording and snapshots to be controllable from Home Assistant rather than merely visible there, because the switches and the PTZ and manual event services are the parts no MQTT template can reproduce. Do not install it if all you need is the numbers on a dashboard, since Home Assistant's own MQTT integration can subscribe to the same topics without depending on Home Assistant internals, and that dependency is real, shown by the integration pinning a single Home Assistant release for development. Two things decide whether it works at all in your setup, and neither is optional. A broker must be installed and configured separately, because the integration cannot do that itself, and the media source integration must be enabled before the media browser appears at all. Then check the version you are pinning: releases are on a 5.15 line with v5.15.6 dated 2026-09-03, and the requirements file names one Home Assistant release, so verify that pair against your own install before updating either side.

Frequently asked questions

Official sources

1. blakeblackshear/frigate-hass-integration on GitHub
2. Issues
3. License: MIT
4. README
5. Releases