New comprehensive Frigate binding

Thank you for the detailed steps! I have checked my setup and it follows your exact structure:

  1. My MQTT Broker is installed, online, and working.

  2. My frigateSVR Server is also online and bridged correctly to the MQTT broker.

  3. The 4 cameras that I installed before the update are completely online and working perfectly fine. So the underlying system and the nested bridge architecture are definitely running.

However, my issue happens when I try to add something new. If I go to Things → click the ‘+’ sign → select the ‘Frigate NVR Binding’, I do not get the options you mentioned in steps 2 or 3. I don’t see , and I cannot scan for anything.

Instead, the UI simply shows the message: “No thing types can be added with this binding.”

The menu is completely empty except for that message, so I am blocked from adding any new cameras manually or via scan."

That is fantastic news, thank you! I’m really looking forward to it.

To give you some context on why a native Audio Sink would be such a game-changer for me: I am using Dahua cameras, and unfortunately, I never managed to get WebRTC working properly within openHAB. Because of that, I had to build a rather complex, custom workaround just to get TTS (Text-to-Speech) working on the camera speakers.

I thought I’d share my current setup with you, just in case you are interested in how I currently “brute-force” the audio return channel.

Here is my current architecture:

1. Virtual Soundcards (ALSA) I use the ALSA loopback kernel module (snd-aloop) to create a virtual audio device for each camera on my openHAB system (e.g., hw:eingang, hw:garage, hw:briefkasten).

2. Exposing to openHAB (Squeezelite) To make these virtual soundcards available as Audio Sinks in openHAB, I run a dedicated Squeezelite instance for each camera as a systemd service. Example for the Front Door (Eingang):

Ini, TOML

[Unit]
Description=Squeezelite Player Eingang
After=network.target

[Service]
ExecStart=/usr/bin/squeezelite -n "Audio_Kamera_Eingang" -o plughw:CARD=eingang,DEV=0 -m 00:00:00:00:00:14
Restart=always
User=openhabian

[Install]
WantedBy=multi-user.target

3. The “VOX-Watcher” (Bash Script & Curl) Finally, I have a bash script running as a background service. It uses sox to constantly listen to the virtual ALSA device. As soon as openHAB sends a TTS message to the Squeezelite player, sox detects the audio, writes it to the RAM disk (/dev/shm), encodes it to G.711A (.alaw), and immediately pushes it to the Dahua camera’s API via curl.

Bash

#!/bin/bash
# Trap to handle safe exit
trap "echo -e '\n[!] Script terminating...'; exit" SIGINT SIGTERM

echo "========================================================="
echo " VOX-Watcher started."
echo " Waiting for audio on (plughw:eingang,1,0)..."
echo "========================================================="

RAM_FILE="/dev/shm/tts_eingang.alaw"
COUNTER=0 

while true; do
    # 1. Listen via sox (VOX detection)
    sox -S -t alsa plughw:eingang,1,0 -t raw -r 8000 -c 1 -e a-law $RAM_FILE silence 1 0.1 0.1% 1 1.5 0.1% vol 10.0

    # 2. Check if file is created and not empty
    if [ -s "$RAM_FILE" ]; then
        ((COUNTER++))
        FILESIZE=$(stat -c%s "$RAM_FILE")
        
        echo "[$(date +'%H:%M:%S')] Audio #$COUNTER detected! ($FILESIZE Bytes)"
        echo "-> Pushing to Dahua Camera API..."

        # 3. Push file to Camera via curl
        curl -s --max-time 20 --digest -u 'admin:PASSWORD' -X POST -H "Content-Type: Audio/G.711A" --data-binary @$RAM_FILE "http://192.168.178.61/cgi-bin/audio.cgi?action=postAudio&httptype=singlepart&channel=1" > /dev/null

        if [ $? -eq 0 ]; then
            echo "-> Successfully pushed!"
        else
            echo "-> [!] ERROR sending to camera!"
        fi

        # 4. Clean up RAM
        rm -f $RAM_FILE
    else
        sleep 1
    fi
done

As you can see, it completely works, but it’s a massive and clunky workaround relying on virtual loopbacks, external players, and bash scripts polling for audio.

Having this handled natively within your Frigate binding would clean up the system architecture tremendously! Thanks again for considering it for the to-do list.

Interesting - I can’t replicate this behaviour in the test environment.

If I click on ‘+’ in Things, I wouldn’t see the Frigate NVR binding directly. Instead, I first click on ‘MQTT Binding’· In the list that appears then, I should see the frigate Thing options.

Can you try selecting the MQTT Binding first and see if the Frigate bindings appear in the sub-menu?

Interesting – you are completely right!

If I select the ‘MQTT Binding’ first, the Frigate options (frigateSVR Server and Camera) appear perfectly in the sub-menu, just as you described.

I actually already have the server and my cameras set up and running successfully in the background. I was just completely confused by the UI behavior. I didn’t understand that it is entirely normal for the main ‘Frigate NVR Binding’ entry to show absolutely nothing when you click on it directly.

Because that menu was empty, I wrongly assumed there was a bug in my setup, or that the binding was looking for an old server name from a previous installation and therefore failing to load the UI elements.

Thanks for clearing up this UI logic for me! It makes total sense now that they are grouped as MQTT sub-components.

Thanks! Methinks I need to update the documentation to clarify this :slightly_smiling_face:

The changes came with the new architecture using nested bridges, and it isn’t obvious at first glance. Glad it’s working now.

Oh, I missed this too !
Sorry for the inconvenience and thanks again.

Then it helps anyway this binding is a great piece of work and I thank for it

First of all thank you for the great work you did on this!

Is there a channel to enable/disable cameras in frigate?
My usecase is my 3d printer camera which is only online when the printer is actually powered on.
So I’d like to automate enabling/disabling it via an openhab rule.

Klipper based camera? Or a separate camera?

I am using GitHub - mainsail-crew/crowsnest: Webcam Service for multiple Cams · GitHub
to display an usb webcam connected to the raspberry pi running the klipper stack

Not in the current version of the binding: however the Frigate API does allow for it so I could add this easily if it is useful, but a current solution would be to simply have your rule disable the Camera Thing attached to your 3D printer camera: something like things.getThing(‘3d_printer_camera_id’).setEnabled(false) to turn it off, and then re-enable it by changing the boolean to true. I’m honestly not sure if this works with RulesDSL or Blockly as I only use JS rules here - but worth a try.

My intention was actually to have it auto disabled/enabled in frigate to stop it from trying to connect to the cam and spam the log - so disabling in openhab would be only mildly useful :smiley:

It should be an easy add, as the enable/disable is accessible from the MQTT API. I will look at adding it shortly

Just added this for you as a new channel - try the v3.02 release now available on Github and shortly on the Marketplace.

Thanks a bunch! I appreciate it!