Now your Frigate cameras become Gladys devices, with their sensors, switches, and scene triggers. You need Gladys 5.1.0 minimum and Frigate 0.16, 0.17 or 0.18.
In detail:
Cameras in Gladys (Discovery tab → Scan → Add to Gladys):
The image of each camera, refreshed every minute and taken instantly when Gladys requests it (chat, scenes). It’s Frigate that resizes it to fit within the 150 KB accepted by Gladys.
Frigate switches: camera enabled, object detection, snapshots, and recordings/audio detection if they are enabled in your Frigate configuration. A switch is only shown as changed once Frigate has confirmed.
Sensors: motion, presence, and count for each tracked object (person, car, dog…), total objects, review status (nothing/detection/alert). Optionally, a presence sensor per zone and per object.
Only what your Frigate configuration enables is created: no recording switch if recording is disabled in the file, for example.
Triggers and a scene action (search for "Frigate: " in the editor):
Triggers: « new review » (alert or detection, filterable by severity, object, and zone), « object detected » and « object enters a zone ». Once per incident, never a burst with each image: false positives and stationary objects (the parked car) are ignored, with adjustable minimum confidence and delay in the configuration.
« Join the event image » action: the snapshot that Frigate kept, with or without the detection frame, becomes the camera image. Example: « new review », severity Alert, object person, then this action with {{triggerEvent.data.event_id}}, then « Send a camera image ». And you have the photo of the person in front of the door on your phone.
On an alert, the integration also publishes a fresh image before triggering. A simple « Send a camera image » right after therefore sends the alert, and not the image from a minute ago.
Real-time goes through the MQTT broker on which Frigate publishes (recommended). Without a broker, the integration uses Frigate’s WebSocket, but the switches then require a Frigate admin account: since 0.17, Frigate refuses commands from other roles on the WebSocket.
Less visible side:
Security:
Designed for the authenticated port 8971, with a dedicated Frigate account in the viewer role.
Frigate’s self-signed certificate is approved on the first connection and then pinned: if it changes, the connection is refused until you click on « Trust the new certificate ». Same for the broker in TLS.
The password and token never go to an unapproved server, and never appear in the logs.
The badge of each camera in the device list goes to unreachable if Frigate does not respond or if the camera stream is lost for 30 s. It goes to degraded if recording is interrupted or if the real-time stream is cut.
The connection status at the top of the configuration clearly states what is wrong, and « Test the connection » checks everything (Frigate, certificate, account, broker).
Reconnection is automatic (Frigate, broker, WebSocket). When Frigate restarts, its configuration is re-read: a newly added camera appears in Discovery.
Respect for Gladys limits (states, images, events per minute), to not flood the database or scenes.
A lighter Docker image of about 57 MB, and an end-to-end test that launches the complete integration against a fake Gladys before each release.
For live video, it does not go through the integration: use Gladys’s RTSP Camera service pointed to Frigate’s restream, rtsp://<frigate-ip>:8554/<camera_name>.
The complete documentation (quick start, broker ACL, troubleshooting) is accessible via the Documentation link on the integration page.
It’s all fresh: the connection to Frigate has been tested on a real installation, but not yet the sensors, switches, and scenes. Your feedback is therefore welcome, especially on Frigate 0.16 and 0.18, without MQTT broker and with multiple zones. Do not hesitate to post the connection status and the integration logs if something is stuck.
Wow, that’s exactly what I’ve been missing (I’m currently using MotionEyes, with URL invocation via a custom API, in short, a real DIY setup…).
What is the CPU/RAM and network load for this integration for a given configuration? My requirement is to be able to handle at least 4 cameras (2 nest boxes and 2 monitored locations).
Your Coral-based configuration interests me, as the machine supporting my current video processing is poor in terms of CPU and struggles quite a bit as soon as I process some streams via AI… Could you share your experience on the subject?
Small update to the Frigate integration, 0.3.1, following the first tests. Still Gladys 5.1.0 minimum and Frigate 0.16 to 0.18.
In detail:
The detection frame now appears on the phone (bug)
The typical scenario is: “Frigate: object detected”, then “attach the event image” with the frame, then “Send a camera image”. Until now, the sent photo was the live image from the camera, without the frame around the person.
The reason: “Send a camera image” does not take the image just attached; Gladys asks the integration for a live image again.
Now, for one minute after the action, it is the event snapshot (with its frame) that is sent back to Gladys. This also applies to the live view of the dashboard.
More help in the scene editor
The “Object” and “Zone” fields of the triggers explain what to enter. You need the Frigate name, in English and lowercase: person, car, dog, cat, bicycle… You will also find them among the sensors of your camera in Gladys (Person, Car…). Leave the field empty to react to any object.
The “object detected” trigger specifies that it only triggers on an object confirmed by Frigate detection, above the minimum confidence. A simple movement never triggers it: movement is the camera’s “Motion” sensor.
Less visible on the side:
If the event is already over when the scene runs, Frigate returns the snapshot it recorded. If it is too heavy for Gladys (more than 150 KB), the integration sends the event thumbnail instead of failing.
The “attach event image” action no longer fails when Gladys’ 12 images per minute limit is reached. The dashboard image is then not updated, but the send still goes through with the snapshot.
No need to click “Update” on the devices: nothing changes on their side. Just update the integration.
Thanks for the feedback, keep telling me what’s not working, with the integration logs as evidence!
I struggled for a long time with the settings in the Frigate config, the masks, the zones… and in the end I left it to Claude, who determined and drew the masks for me etc…
This saved me processor power, Google Coral latency, disk space and efficiency!
Maybe you should just use the (unofficial) nomenclature that we’ve all sort of used:
« External Integration - Frigate » and you specify it in the presentation
