I had Frigate running object detection across nine cameras, six wired Hikvision units through an NVR and three Wyze cameras over WiFi. The next step was wiring it into Home Assistant so motion events and object detections could drive automations and notifications. I installed the Frigate integration, it discovered every camera and every sensor, and then every single entity showed up as unavailable.

The problem

The integration set up cleanly. It found the cameras, created the device entries, registered all the sensors: motion, object counts, per-camera binary sensors. And all of them sat greyed out with no state. A page full of entities that exist and report nothing is a particular kind of frustrating, because the integration looks like it worked.

Frigate talks to Home Assistant over MQTT

The thing I had not internalized is that the Frigate integration is not an HTTP poll against Frigate’s API. It works over MQTT. Frigate publishes object events, camera state, and sensor values to an MQTT broker, and Home Assistant subscribes to them. Home Assistant runs Mosquitto as that broker. If Frigate is not publishing to the broker, Home Assistant has nothing to subscribe to, and every entity it created stays unavailable.

So the question was whether Frigate was publishing at all. It was not. My Frigate config had MQTT switched off:

mqtt:
  enabled: false

That line is easy to leave behind. Object detection and recording both work fine with MQTT disabled, so when I first set Frigate up around detection and storage, I never turned it on. The Home Assistant integration is the one consumer that depends on it, and I had not gotten to that part yet.

Turning MQTT on

The fix was to enable MQTT and point Frigate at Home Assistant’s Mosquitto broker:

mqtt:
  enabled: true
  host: ha.internal
  port: 1883
  user: frigate
  password: # pulled from the Ansible vault

I manage the Frigate config through an Ansible role, with the MQTT credentials kept in the vault rather than in the template. Deploying the change and restarting Frigate took a few seconds, and the Frigate log showed the MQTT connection come up. In Home Assistant the entities flipped from unavailable to live almost immediately: motion sensors started reporting, object counts updated, the per-camera binary sensors began firing on detections.

That was the whole fix for the part that mattered most. One disabled setting stood between a dead integration and a working one.

The half that did not go as cleanly: live video

Entities worked. Live video did not. The camera cards in Home Assistant showed snapshots, a still frame that refreshed every so often, but never a live stream. Live view worked fine in Frigate’s own web UI, so the cameras and Frigate were healthy. The gap was specifically in what Home Assistant could play.

Home Assistant 2024.11 had introduced native WebRTC support for camera streams with stricter requirements than before. Live streaming from Frigate to Home Assistant goes through go2rtc, either as an RTSP restream or over WebRTC, and two things got in my way.

The first is that Traefik, the reverse proxy that fronts my services, cannot proxy RTSP. Traefik is an HTTP/L7 proxy with no RTSP support, so any RTSP URL pointed at the Traefik hostname just hangs. RTSP consumers have to talk to Frigate directly on frigate.internal:8554, bypassing the proxy entirely.

The second is WebRTC. go2rtc’s WebRTC needs candidate addresses that Home Assistant can actually reach, and the candidate has to be the Frigate host’s own IP, not the proxy name:

go2rtc:
  webrtc:
    listen: :8555
    candidates:
      - 192.168.20.19:8555 # Frigate host IP, not the Traefik hostname
      - stun:8555

I added explicit live: configuration to every camera, set the RTSP URL template in the integration options to the direct Frigate address, configured WebRTC as above, reloaded the integration, and restarted Home Assistant more than once. Snapshots kept showing. Live stayed stubborn. The stream worker kept reaching for the Traefik domain even after I set the template.

Where I stopped

I could have kept grinding on the WebRTC setup, but I decided the integration did not have to do everything. So I split it by what each side is good at.

The Frigate integration does what it does well, all over MQTT: object-detection notifications, event tracking, and the motion and occupancy sensors that drive automations. For live viewing I disabled the cameras in the Frigate integration and added the cameras to Home Assistant directly over RTSP, which is its own story. Frigate for AI and notifications, direct camera integrations for the live tiles.

This was a “good enough” call, not a clean win, and I want to be honest about that. The RTSP-through-Traefik constraint is real and the WebRTC candidate setup is finicky. Splitting responsibilities let each path do the thing it is reliable at instead of forcing one integration to be both the detection brain and the video player.

Lessons learned

• The Frigate Home Assistant integration runs on MQTT, not HTTP. If every entity is unavailable, check that Frigate has MQTT enabled and pointed at your broker before you look at anything else. Unavailable entities almost always mean no MQTT.
• Detection and recording work without MQTT, which is exactly why it is easy to leave off. The integration is the one piece that needs it, so it is the thing that breaks when you forget.
• RTSP does not go through an HTTP reverse proxy. Traefik has no RTSP support, so point camera streams straight at the Frigate host on port 8554. A stream URL on your proxy hostname will just hang with no useful error.
• WebRTC candidates have to be the Frigate host’s reachable IP, not the proxy name. A wrong candidate fails quietly as snapshots-only, which sends you looking everywhere except the candidate list.
• Split responsibilities when one integration will not do both jobs well. Frigate is excellent at detection and events; direct RTSP is more reliable for live tiles. Using each for its strength beat forcing one to do everything.