HHowto

Hardcore-Tech-Howto: Quasi jeden Uralt-Kamerastream in Unifi Protect nutzbar machen (NERDALARM!)

IM EINSATZ?

Dann schau dir UNSEREN LOXKURS an und profitiere von unserem Wissen!

Heute nach langer Zeit mal wieder ein absolutes NERD-Tech-Howto mit dem Wissen und dem Schweiss mehrerer steiniger Monate des Recherchieren, Konzeptionierens und Ausprobierens, um alles zum Laufen zu kommen. Mit Abstand das aufwändigste und ausufernste „Projekt“ seit über zwei Jahren, als ich damals meinen netzdienlichen 100kWh DIY-Batteriespeicher (Details hier) realisiert habe. Aber ohne solche Projekte wäre das Technik-Dasein ja auch irgendwie langweilig.

Euch sagen Begriffe wie MJPEG-Stream, GPU-Transcoding, go2rtc, ffmpeg, Frigate oder ONVIF noch nichts? Nicht schlimm! Aber lest bitte nur weiter, wenn ihr euch bereit dafür fühlt…

Worum geht es hier überhaupt?

Kurzzusammenfassung (oder auch etwas länger – wie man es sieht): Ich nutze verschiedene Tools, um die MJPEG-Streams meiner uralten Mobotix-Kameras (s15d) über Frigate mithilfe von go2rtc und ffmpeg in butterweiche rtsp-Streams im h264-Format umzuwandeln und diesen Stream dann noch über einen ONVIF-Server so zu maskieren, sodass dieser in Unifi Protect als ONVIF-fähige Kamera eingebunden und genutzt werden kann – inklusive der Möglichkeit über einen Unifi AI Port erweiterte Bildauswertungen zu ermöglichen (u.A. Gesichts- und Nummernschilderkennung).

Ein AI Port (externer Link) kann dabei übrigens mit einer aktuellen Firmware drei Unifi-fremde Kameras gleichzeitig AI-fähig machen – bis 1080p und max. 30fps, was ich total feiere. Weiterhin wird noch der http-Stream einer Loxone Intercom (Affiliate-Link) ONVIF-fähig gemacht, was durch die zwingende Nutzung von Zugangsdaten erschwert wird, weshalb hier nochmal ein go2rtc-Server vorgeschaltet wird, der diese Zugangsdaten per Base24-String bereithält.

Jetzt alles klar?!

Also sagen wir mal so: Ich beschäftige mich jetzt gefühlt seit Monaten mit diesem Sh*t, da ich eigentlich schon seit etwa einem Jahr meine „externen“ Kameras in Unifi Protect nutzen möchte – bspw. eigentlich schon seit acht Jahren eine vernünftige DVR-Möglichkeit suche, um meine Mobotix-Kameras sinnvoll nutzen zu können.

Oder mal einen sinnvollen Einsatzzweck für meinen 40″ ELO-Touchscreen in der Diele – dann als Unifi-Protect-Viewer…

Aber erstmal zurück auf Los…

Über einen „Umweg“ per Frigate habe ich die letzten Monate nach und nach gelernt, wie ich meine Mobotix Kameras (mit dem nervigen MJPEG-Stream) per ffmpeg-go2rtc-Kombi in einen „modernen“ h264-Stream umwandeln kann.

Nach gefühlt hunderten Stunden der Internetrecherche und konzeptionellem Verständnis der „bells and whistles“ konnte ich dann mit Hilfe von ChatGPT (Anfangs mit dem Modell GPT-4o, dann o4-mini-high und nun 4.1) nach und nach alles so zum Laufen bringen, wie unten beschrieben. Aber glaubt nicht, dass der Weg bis zum Ziel trotz KI-Support einfach war. Er war hart und steinig – insbesondere auch aufgrund von Detailproblemen, wie dem Einsatz einer „zu neuen“ Intel CPU (Gen 15 Core U7), dessen fancy QuickSync-GPU-Transcoding-Features weder nativ in Proxmox (akuelle Version 8.4.1) per LXC-Container noch per Debian-VM (Version 12.irgendwas) genutzt werden können. Und das ist sinnvoll, um das notwendige Videotranscoding von MJPEG zu h264 effizient und vorallem auch skalierbar (habe mehrere dieser Kameras) handhaben zu können.

Nachfolgend also eine komplette Nerd-Anleitung, primär für mich als Doku, da ich sonst verzweifle, wenn ich das Ganze nochmal komplett „blank“ in einigen Monaten bei einem potenziellen Reinstall des ganzen Setups aufbauen möchte/muss. Und natürlich für Jonas und Lucien, die ihre Loxone Intercom ebenfalls in Unifi Protect einbinden möchten – und natürlich für jeden sonst, der so nerdig ist bzw. sein möchte… 😀

Übrigens: Ich freue mich immer auf Austausch mit Gleichgesinnten und Feedback von anderen Anwendern…

Genutzte Hardware – ASUS NUC 15 Pro 4thewin!?

Lange habe ich recherchiert und dann schlussendlich zugeschlagen:

Genutzt wird bei dieser Anleitung ein taufrischer ASUS NUC 15 Pro Slim Kit RNUC15CRKU700002 (Affiliate-Link) mit gleichzeitig potentem sowie stromsparendem Intel Core u7 Ultra 255H (externer Link), der mein neuer Homelab-Server für alles Mögliche (NodeRED, EVCC, HomeAssistant, InfluxDB, Grafana, EOS, Loxberry, Win10 VM für Loxone Config, …) sein wird.

Die in Q1 2025 releaste CPU hat insgesamt 16 physische Kerne (6P, 8E, 2LE), taktet mit bis zu 5,1 Ghz, fette 24M Cache und bringt eben auch noch eine aktuelle Intel Arc 140T iGPU (mit auf der CPU) mit, um hardwarebasiertes Transcoding per Intel QuickSync mit bis zu 2,25 GHz realisieren zu können. Zusätzlich gibts auch noch NPU-Funktionen im Sinne von Intel AI Boost. Kein Plan, was man damit noch irgendwann machen kann…

Als Arbeitsspeicher nutze ich zwei relativ hochpreisige Speicherriegel vom Typ Kingston ValueRAM 32GB 6400MT/s DDR5 Non-ECC CL52 CSODIMM KVR64V52BS8-32 (Affiliate-Link), da gefühlt alle anderen günstigen Speicher „nur“ bis 5600MT/s laufen, was den Intel NUC ausbremsen würde. Mit 64GB sollte das Setup dann genug Ressourcen für alle möglichen Virtualisierungen mitbringen. Die CPU unterstützt sogar bis 128GB, was perspektivisch evtl. sogar irgendwann sinnvoll sein könnte.

Und damit das System vernünftige Lese- und Schreibgeschwindigkeit erlaubt, ist eine Crucial T500 SSD 2TB PCIe Gen4 NVMe M.2 Interne SSD (Affiliate-Link) mit bis zu 7400 MB/s verbaut. Ich hab mir wirklich schon lange keine „normale“ PC-Hardware gekauft (eben nur den Mac Mini M4 Pro letztes Jahr) und war jetzt völlig erstaunt, welche Specs die neuen Gerätchen haben. Über 7GB/s bei einem NVMe in diesem Preissegment… WTF?! Es gibt sogar noch krankere mit doppelter Speed, das wäre aber doppelter Overkill, zumal es der verbaut Arrow-Lake-Chipsatz gar nicht unterstützen würde.

Kurze Info aus der Zukunft: Das Proxmox-System auf obiger Hardware verbraucht im Idle übrigens unter 10W, wenn gar nichts läuft eher nur 6W. Im laufenden Betrieb mit einem halben Dutzend Kamerastreams (dazu unten dann mehr) und entsprechenden Transcodings etc. sind es dann im Schnitt 30W.

Nicht wenig, aber für die gebotene Leistung meiner Meinung nach dennoch unschlagbar – zumindest derzeitig.

Proxmox Hypervisor per USB-Stick installieren

Genutzt habe ich den Proxmox VE 8.4 ISO Installer (Direkt-Download), welcher auf der offiziellen Proxmox-Downloadseite (externer Link) zur Verfügung gestellt wird.

Dann ab damit per Balena Etcher (externer Link) auf einen USB-Stick und in den Intel NUC, um das Installations-Setup durchzuspielen. Ich weiss, Balena Etcher steht zurecht in der Kritik bzgl. Datenkrake, aber ich nutze das einfach schon seit… IMMER. 😀

Je nachdem, wie die Nachfrage ausfällt, werde ich dazu evtl. noch ein eigenes Video (bzw. eine Videoreihe zu dem Thema) machen. Schreibt gerne in die Kommentare, ob euch das interessieren bzw. weiterhelfen würde.

Login in Proxmox Hypervisor

Nachdem die frische Proxmoy-Installation auf dem Intel NUC gebootet ist, logge ich mich direkt per ssh ein:

ssh root@192.168.3.2

Da die Fehlermeldung

@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @

angezeigt wird, musste ich noch das hier eingeben, um den Key zu löschen:

ssh-keygen -R 192.168.3.2

No valid subscription Meldung ausblenden:

Dazu einfach das Script PVE Post Install (externer Link) nutzen.

Hierzu wird nachfolgender Code in der Shell des Proxmox Host ausgeführt

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh)"

Im Rahmen des Wizards kann man alle unerwünschten Notifications entfernen und sogar die im nachfolgenden Schritt angesprochenen „Updates ohne Subscriptions“ umstellen. Dadurch braucht man das gar nicht mehr manuell umstellen. Ich lasse den Punkt dennoch drin, damit man sieht, wie man das auch händisch machen kann…

Updates ermöglichen ohne Subscription:

Jetzt geht weiter im Proxmox-UI unter: https://192.168.3.2:8006

Datecenter -> pve (Hostname) -> Updates -> Repositories

Die beiden Einträge mit „enterprise“ in der URL anklicken und per „Disable“ ausgrauen.

Auf „Add“ klicken und das Repository „No-Subscription“ auswählen und „Add“ klicken.

Zurück auf „Updates“ klicken, danach auf „Refresh“ und warten bis im neuen Fenster „TASK OK“ steht. Fenster schließen und auf „Upgrade“ klicken. Im neuen Fenster mit „Y“ (Taste y) bestätigen und die Enter-Taste drücken. Warten…

Seems you installed a kernel update - Please consider rebooting
this node to activate the new kernel.

starting shell
root@pve:/#

Wenn in der Konsole wieder Eingaben möglich sind, wird das System neugestartet:

reboot

Zu beachten ist, dass solche no-subscription-Updates laut der Info im Proxmox-UI nicht für den produktiven Betrieb gedacht sind und theoretisch zu Problemen/Fehlern führen können. Keine Ahnung, ob da etwas dran ist. Rein technisch sind die Pakete anscheinend identisch, nur kommen neue Updates in der Free-Variante erst etwas zeitverzögert.

Kernel-Update durchführen

Nach dem Neustart wieder per ssh verbinden:

ssh root@192.168.3.2

Bei Eingabe von

uname -r

wird in meinem Fall

6.8.12-11-pve

angezeigt, da ich noch auf Proxmox 8.4.0 unterwegs bin (aktueller Stand 17.07.2025).

Dadurch wird die Intel Quicksync GPU (vaapi) nicht korrekt erkannt. Das sieht man daran, dass der Befehl

ls /dev/dri/

lediglich

by-path  card0

zurückgeliefert, der Eintrag „renderD128“ fehlt jedoch bei der Ausgabe… Da liegt daran, dass erst ab 6.10.x der noch recht neue Arrow-Lake-Chipsatz meines Intel-NUCs unterstützt wird.

Deshalb muss jetzt eine neu Kernel-Update durchgeführt werden mit:

apt update

apt install -y proxmox-kernel-6.14

Nach einer Weile sollten die Konsolenbefehle mit

Setting up proxmox-kernel-6.14 (6.14.5-1~bpo12+1) ...
root@pve:~#

enden. Jetzt direkt ein erneutes:

reboot

Und wieder einloggen:

ssh root@192.168.3.2

Jetzt sollte der Befehl

ls /dev/dri/

zu der Ausgabe

by-path  card1 renderD128

führen. Passt. Leider kann Proxmox in der oben genannten Version die GPU dennoch nicht nutzen, da der Treiber schlicht noch nicht aktualisiert wurde. Deshalb kann ich keinen LXC-Container nutzen und stattdessen eine eingenständige Debian-VM installieren…

Wenn ihr Proxmox in Zukunft updatet, werden automatisch neue Kernel-Versionen installiert, die vermutlich standardmäßig nach einem Reboot geladen werden. Die verfügbaren Kernel-Versionen könnt ihr so einsehen:

proxmox-boot-tool kernel list

Die Ausgabe sieht bei mir so aus derzeitig:

Manually selected kernels:
None.

Automatically selected kernels:
6.14.5-1-bpo12-pve
6.14.8-1-bpo12-pve
6.8.12-12-pve

Um jetzt wieder die neueste Version als „default“ zu setzen, hilft dieser Konsolenbefehl:

proxmox-boot-tool kernel pin 6.14.8-1-bpo12-pve

Anderenfalls gibt es beim nächsten Reboot wieder Probleme mit der QuickSync-GPU-Geschichte (also zumindest bei dem oben erwähnten 2025-er Intel NUC, dessen Hardware noch „zu neu“ ist).

Ubuntu-VM erstellen in Proxmox

Da Debian keine passenden Treiber hat für die hier eingesetzte iGPU, muss ich doch Ubuntu installieren. Am Ende vermutlich ziemlich egal, ich würde dennoch Debian bevorzugen, sofern möglich…

Hier gibts da notwendige iso-File:

https://ftp.tu-chemnitz.de/pub/linux/ubuntu-releases/25.04/ubuntu-25.04-live-server-amd64.iso

Ubuntu-VM erstellen in Proxmox mit „Create VM“:

General – VM ID: 400
General – Name: Cam-Main
General – Start at boot: ja („Advanced“ muss unten aktiviert sein)
OS – ISO image: ubuntu-25.04-live-server-amd64.iso
System – Machine: q35
System – Gemu Agent: ja
Disks – Storage: 32 GiB
CPU – Cores: 4
Memory – Memory (MiB): 8192
Confirm – „Start after created“: ja

VM unter „Datacenter“ -> „pve“ -> „400 (Cam-Main) auswählen und auf „Console“ klicken. Ubuntu-Installation durchführen…

Manuelle iPv4 Adresse:
Subnetz: 192.168.3.0/24

SSH configuration:
* OpenSSH-Server installieren (x setzen mit Leertaste)

Weitere Software:
* docker (Sternchen setzen mit Leertaste)

Beim Proxmox-Host einloggen:

ssh root@192.168.3.2

Die iGPU kann auch nochmal mit dem Befehl

lspci | grep -i vga

geprüft werden. Hier sollte dann

00:02.0 VGA compatible controller: Intel Corporation Arrow Lake-P [Intel Graphics] (rev 03)

ausgespuckt werden.

Jetzt musst das Passthrough aktiviert werden:

nano /etc/pve/qemu-server/400.conf

Hier steht bei mir in der letzten Zeile:

hostpci0: 0000:00:02

Diese Zeile ersetzen mit:

hostpci0: 00:02.0,pcie=1

Speichern mit: Ctrl + o -> ENTER-Taste
Beenden mit: Ctrl + x

Am besten blacklistet man jetzt noch i915 am Host mit:

echo "blacklist i915" > /etc/modprobe.d/blacklist-i915.conf

update-initramfs -u

Damit wird die IGPU gar nicht mehr im Host eingebunden.

System neustarten:

reboot

Jetzt in der VM einloggen:

ssh jay@192.168.3.31

Checken, ob das Durchreichen der GPU funktioniert hat:

lspci | grep -i vga

Jetzt sollte diese Rückmeldung kommen:

00:01.0 VGA compatible controller: Device 1234:1111 (rev 02)
01:00.0 VGA compatible controller: Intel Corporation Arrow Lake-P [Intel Graphics] (rev 03)

Wichtig ist der zweite Eintrag.

Nun noch die notwendigen Treiber installieren:

sudo apt update

sudo apt install -y intel-media-va-driver vainfo

Kurz noch direkt die Guest-Tools installieren:

sudo apt install -y qemu-guest-agent

sudo systemctl enable --now qemu-guest-agent

Sofern man das Blacklisting wieder entfernen möchte, macht man auf dem Proxmox Host (hier ssh root@192.168.3.2):

NUR AUSFÜHREN, WENN MAN DIE IGPU WIEDER IM HOSTSYSTEM (PROXMOX) NUTZEN MÖCHTE:
#######################################
rm /etc/modprobe.d/blacklist-i915.conf
#######################################
update-initramfs -u
#######################################
reboot
#######################################

Docker in der Ubuntu-VM konfigurieren

Installiert wurde Docker ja bereits im Rahmen der Ubuntu-Installation. Jetzt müssen aber noch ein paar Anpassungen vorgenommen werden:

sudo groupadd docker

sudo usermod -aG docker jay

sudo chown root:docker /var/run/docker.sock

exit

Neu einloggen:

ssh jay@192.168.3.31

In der VM ausführen:

sudo apt-get update

sudo apt-get install -y ca-certificates curl gnupg

Nun erstmal einen Snapshot der VM machen unter Datacenter -> pve -> 400 (Cam-Main) -> Snapshots -> Take Snapshot

Wenn dabei der Fehler „ASK ERROR: VM 400 qmp command ’savevm-start‘ failed – 0000:00:02.0: VFIO migration is not supported in kernel“ angezeigt wird, einfach die VM mit dem Shutdown-Button beenden und den Snapshot erneut erzeugen.

Frigate unter Docker auf der Debian VM laufen lassen

mkdir -p ~/frigate/config

Docker compose-File für Frigate anlagen:

nano ~/frigate/docker-compose.yml

In die Datei einfügen:

services:
  frigate:
    container_name: frigate
    restart: unless-stopped
    image: ghcr.io/blakeblackshear/frigate:stable
    shm_size: "2g"
    mem_limit: 12g
    mem_reservation: 6g
    devices:
      - /dev/dri:/dev/dri
    group_add:
#      - "render"
      - "video"
    environment:
      - TZ=Europe/Berlin
    volumes:
      - ./config:/config
      - ./media:/media
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "5000:5000"
      - "8554:8554"
      - "1984:1984"
#      - "8899:8899"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000"]
      interval: 60s
      timeout: 5s
      retries: 3
      start_period: 30s

Speichern mit: Ctrl + o -> ENTER-Taste
Beenden mit: Ctrl + x

Frigate config.yml öffnen:

nano ~/frigate/config/config.yml

Hier Config einfügen:

mqtt:
  enabled: False

go2rtc:
  streams:
    mobotix-park:
       - ffmpeg:rtsp://loxoneuser:loxonepw@192.168.3.22:554/stream0/mobotix.mjpeg#video=h264#audio=copy#hardware

cameras:
  park:
    enabled: true
    ffmpeg:
      hwaccel_args: preset-vaapi
      inputs:
        - path: rtsp://localhost:8554/mobotix-park
    record:
      enabled: false    # keine Aufnahme
    detect:
      enabled: false    # keine Bewegungserkennung
    snapshots:
      enabled: false    # keine Snapshots


version: 0.15-1
mqtt:
  enabled: False

go2rtc:
  streams:
    mobotix-park:
       - ffmpeg:rtsp://admin:meinpw@192.168.3.22:554/stream0/mobotix.mjpeg#video=h264#audio=copy#hardware
    mobotix-balkon:
      - ffmpeg:rtsp://admin:meinpw@192.168.3.23:554/stream0/mobotix.mjpeg#video=h264#audio=copy#hardware
    mobotix-hochbeet:
      - ffmpeg:rtsp://admin:meinpw@192.168.3.24:554/stream0/mobotix.mjpeg#video=h264#audio=copy#hardware
    mobotix-haustuer:
      - ffmpeg:rtsp://admin:meinpw@192.168.3.25:554/stream0/mobotix.mjpeg#video=h264#audio=copy#hardware
    mobotix-terrasse:
      - ffmpeg:rtsp://admin:meinpw@192.168.3.26:554/stream0/mobotix.mjpeg#video=h264#audio=copy#hardware
    mobotix-parkplatz:
      - ffmpeg:rtsp://admin:meinpw@192.168.3.27:554/stream0/mobotix.mjpeg#video=h264#audio=copy#hardware
    #läuft eigentlich auf der selben maschine - jedoch hat lediglich die angabe der ip bisher bei mir geklappt...
    loxone-intercom:
      - ffmpeg:rtsp://192.168.3.31:8553/http_mjpeg#video=h264#audio=copy#hardware

cameras:
  park:
    enabled: true
    ffmpeg:
      hwaccel_args: preset-vaapi
      inputs:
        - path: rtsp://localhost:8554/mobotix-park
    record:
      enabled: false    # keine Aufnahme
    detect:
      enabled: false    # keine Bewegungserkennung
    snapshots:
      enabled: false    # keine Snapshots
  balkon:
    enabled: true
    ffmpeg:
      hwaccel_args: preset-vaapi
      inputs:
        - path: rtsp://localhost:8554/mobotix-balkon
    record:
      enabled: false    # keine Aufnahme
    detect:
      enabled: false    # keine Bewegungserkennung
    snapshots:
      enabled: false    # keine Snapshots
  hochbeet:
    enabled: true
    ffmpeg:
      hwaccel_args: preset-vaapi
      inputs:
        - path: rtsp://localhost:8554/mobotix-hochbeet
    record:
      enabled: false    # keine Aufnahme
    detect:
      enabled: false    # keine Bewegungserkennung
    snapshots:
      enabled: false    # keine Snapshots
  haustuer:
    enabled: true
    ffmpeg:
      hwaccel_args: preset-vaapi
      inputs:
        - path: rtsp://localhost:8554/mobotix-haustuer
    record:
      enabled: false    # keine Aufnahme
    detect:
      enabled: false    # keine Bewegungserkennung
    snapshots:
      enabled: false    # keine Snapshots
  terrasse:
    enabled: true
    ffmpeg:
      hwaccel_args: preset-vaapi
      inputs:
        - path: rtsp://localhost:8554/mobotix-terrasse
    record:
      enabled: false    # keine Aufnahme
    detect:
      enabled: false    # keine Bewegungserkennung
    snapshots:
      enabled: false    # keine Snapshots
  parkplatz:
    enabled: true
    ffmpeg:
      hwaccel_args: preset-vaapi
      inputs:
        - path: rtsp://localhost:8554/mobotix-parkplatz
    record:
      enabled: false    # keine Aufnahme
    detect:
      enabled: false    # keine Bewegungserkennung
    snapshots:
      enabled: false    # keine Snapshots
  intercom:
    enabled: true
    ffmpeg:
      hwaccel_args: preset-vaapi
      inputs:
        - path: rtsp://localhost:8554/loxone-intercom
    record:
      enabled: false    # keine Aufnahme
    detect:
      enabled: false    # keine Bewegungserkennung
    snapshots:
      enabled: false    # keine Snapshots

version: 0.15-1

Speichern mit: Ctrl + o -> ENTER-Taste
Beenden mit: Ctrl + x

Jetzt ins Verzeichnis von Frigate wechseln und den Docker Container starten mit (Frigate starten):

cd ~/frigate

docker compose up -d

Sobald Docker den Container gestartet hat, sollte Frigate per Browser erreichbar sein:

http://192.168.3.31:5000

Die Systemauslastung kann man hier einsehen je Kamera:

http://192.168.3.31:5000/system#cameras

Der go2rtc Service ist hier erreichbar:

http://192.168.3.31:1984

Stoppen kann man den Container übrigens wieder mit (Frigate stoppen)

cd ~/frigate

docker compose down

Den Health-Status von Frigate kann man so checken (Frigate Health):

docker inspect --format='{{.State.Health.Status}}' frigate

Debian VM erstellen für ONVIF-Server

Der ONVIF-Server schnappt sich den RTSP-Stream im mp4-Format und maskiert diesen als ONVIF-Kamera, sodass eine Integration in Unifi Protect möglich ist.

Hier gehts zum Github-Repo:

https://github.com/daniela-hase/onvif-server

Der ONVIF-Server wird pro Kamera benötigt und sollte als Service in jeweils einer Debian-VM laufen, da er eigene eigene UUID und Mac-Adresse benötigt. Geht sicher auch irgendwie anders, aber ich mache es eben so…

Erstmal Debian-VM erstellen in Proxmox mit „Create VM“:

General – VM ID: 401
General – Name: Cam-Park
General – Start at boot: ja („Advanced“ muss unten aktiviert sein)
OS – ISO image: debian-12.11.0-amd64-netinst.iso
System – Machine: q35
System – Gemu Agent: ja
Disks – Storage: 8 GiB
CPU – Cores: 1
Memory – Memory (MiB): 512
Confirm – „Start after created“: ja

VM unter „Datacenter“ -> „pve“ -> „401 (Cam-Park) auswählen und auf „Console“ klicken. Debian-Installation durchführen…

Datacenter -> pve -> 401 (Cam-Park) anklicken und „Hardware“ wählen. „CD/DVD Drive (ide2)“ auswählen und „Remove“ klicken.

Debian-VM manuelle IP-Adresse verpassen

Bei Datacenter -> pve -> 401 (Cam-Park) sollte bei „Summary“ unter „IPs“ die per DHCP zugewiesene Adresse stehen. Hier: 192.168.3.116

Jetzt per ssh auf der VM einloggen:

ssh jay@192.168.3.116

ssh-keygen -R 192.168.3.116 (sofern Remote-Host-Identification Error)

Zu sudo wechseln mit

su

sudo installieren mit:

apt-get update && apt install -y sudo

User jay sudo-Rechte geben:

sudo usermod -aG sudo jay

Zwei mal

exit

eingeben, um die VM zu verlassen.

Erneut per ssh einloggen:

ssh jay@192.168.3.116

Dann in diese Datei rein:

sudo nano /etc/network/interfaces

Den Absatz:

allow-hotplug enp6s18
iface enp6s18 inet dhcp
# This is an autoconfigured IPv6 interface
iface enp6s18 inet6 auto

ersetzen durch:

auto enp6s18
iface enp6s18 inet static
    address 192.168.3.32
    netmask 255.255.255.0
    gateway 192.168.3.1
    dns-nameservers 192.168.3.1 8.8.8.8
iface enp6s18 inet6 auto

Netzwerkdienst neu starten mit

sudo systemctl restart networking

Neue ssh-Session mit neuer IP öffnen:

ssh jay@192.168.3.32

ssh-keygen -R 192.168.3.32 #sofern notwendig

VM-Snapshot machen…

ONVIF-Server installieren

sudo apt update && sudo apt install curl -y

curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -

sudo apt install -y nodejs git
cd ~

git clone https://github.com/daniela-hase/onvif-server.git

cd onvif-server
npm install
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp6s18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:7d:da:0e brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.32/24 brd 192.168.3.255 scope global enp6s18
       valid_lft forever preferred_lft forever
    inet6 fd48:5aa8:e9be:0:be24:11ff:fe7d:da0e/64 scope global dynamic mngtmpaddr 
       valid_lft 6857sec preferred_lft 3257sec
    inet6 2003:c8:1f4a:6d00:be24:11ff:fe7d:da0e/64 scope global dynamic mngtmpaddr 
       valid_lft 6857sec preferred_lft 1163sec
    inet6 fe80::be24:11ff:fe7d:da0e/64 scope link 
       valid_lft forever preferred_lft forever

bc:24:11:7d:da:0e ist dann die mac-Adresse, die wir gleich im Config-file brauchen bei „mac: bc:24:11:7d:da:0e“

sudo apt install -y uuid-runtime && uuidgen

Jetzt wird ein zufälliger String ausgegeben

c3f5d123-4567-89ab-cdef-1234567890ab

welcher gleich als „uuid: c3f5d123-4567-89ab-cdef-1234567890ab“ in der Config-Datei genutzt werden muss.

nano ~/onvif-server/config.yaml
onvif:
  - mac: bc:24:11:53:a7:91
    ports:
      server: 8899
      rtsp: 8556
      snapshot: 8580
    name: MobotixPark
    uuid: c3f5d123-4567-89ab-cdef-1234567890ab
    highQuality:
      rtsp: /mobotix-park
      snapshot: /api/haustuer/latest.jpg?height=640
      width: 1920
      height: 1080
      framerate: 15
      bitrate: 8192
      quality: 4
    lowQuality:
      rtsp: /mobotix-park
      snapshot: /api/haustuer/latest.jpg?height=320
      width: 1920
      height: 1080
      framerate: 15
      bitrate: 8192
      quality: 1
    target:
      hostname: 192.168.3.31
      ports:
        rtsp: 8554
        snapshot: 5000

Manuell starten zum Testen:

cd ~/onvif-server

node main.js config.yaml

Als Service laufen lassen:

sudo nano /etc/systemd/system/onvif-server.service
[Unit]
Description=ONVIF Server
After=network.target

[Service]
WorkingDirectory=/home/jay/onvif-server
ExecStart=/usr/bin/node /home/jay/onvif-server/main.js /home/jay/onvif-server/config.yaml
Restart=always
User=jay
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload

sudo systemctl enable --now onvif-server
sudo systemctl status onvif-server

Service neustarten:

sudo systemctl restart onvif-server

Stoppen lässt sich der Service sofort und dauerhaft mit:

sudo systemctl disable --now onvif-server

Wer übrigens den Kameranamen bzw. das Kameramodell vor dem „Anlernen“ in Unifi Protect ändern möchte, kann das über diese Datei tun:

nano ~/onvif-server/src/onvif-server.js

Hier gibt es mehrere Zeilen, die man anpassen muss:

Name: 'CardinalHqCameraConfiguration',

Name: 'CardinalLqCameraConfiguration',

Manufacturer: 'Onvif',

Model: 'Cardinal',

onvif://www.onvif.org/name/Cardinal

Das hab ich mal umgestellt auf:

Name: 'ParkHqCameraConfiguration',

Name: 'ParkLqCameraConfiguration',

Manufacturer: 'Park',

Model: 'Mobotix',

onvif://www.onvif.org/name/MOBOTIXS15

Dann die Datei speichern und den Dienst neustarten mit:

sudo systemctl restart onvif-server

Bei der in Unifi Protect neu erkannten Kamera steht dann bei „Name“ „MOBOTIXS15“ und bei „Model“ ebenfalls MOBOTIXS15″. Wenn man dann „Click to Adapt“ auswählt, ändert sich der angezeigte Name in „Park Mobotix“ und bei Model wird nach ca 5-10s auch korrekt „MOBOTIXS15“ angezeigt.

Geschickter habe ich es dann auch nicht mehr hinbekommen, jedenfalls besser als Cardinal als „Model“ zu haben, was man nicht mehr im Unif-Protect-UI kann.

Ich habe dabei darauf geachtet auf Leer- und Sonderzeichen zu verzichten, um möglichen Problemen vorzubeugen.

Memo an mich selbst

TODO: ONVIF-Server als Docker-Container laufen lassen inkl. Watchdog (per Sidecar-Container), um Container automatisch neuzustarten, sofern der Dienst keinen Output mehr liefert - evtl. lässt sich mit einem CLI-Tool ermitteln, ob der Dienst läuft oder nicht...

TESTING (interne Infos)
jay@cam-park:~$ ss -tulpn | grep 8899
tcp   LISTEN 0      511     192.168.3.32:8899       0.0.0.0:*    users:(("node",pid=477,fd=23))
jay@cam-park:~$ lsof -i :8899
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
node    477  jay   23u  IPv4  14403      0t0  TCP 192.168.3.32:8899 (LISTEN)
Mal sehen, wie bzw. ob sich die Response ändert, wenn sich Unifi nicht mehr zur Kamera connecten kann...

evtl. kann man mitt ffprobe auch noch was rausholen...
ffprobe -v error -show_streams -rtsp_transport tcp rtsp://192.168.3.32:8556/mobotix-park

Vorhandene ONVIF-Server-VM klonen für weitere Kamera(s)

SSH-Login auf geklonter VM:

ssh jay@192.168.3.32

An nachfolgenden Stellen gewünschte Netzwerk-IP und Namen anpassen (alte IP +1 hochgezählt):

sudo nano /etc/network/interfaces

sudo nano /etc/hostname

sudo nano /etc/hosts

sudo hostnamectl set-hostname cam-haustuer

IP-v6 herausfinden für onvif-server config.yaml:

ip a

Neue UUID generieren für onvif-server config.yaml:

uuidgen

onvif-server config.yaml anpassen:

nano ~/onvif-server/config.yaml

Debian-VM neustarten:

sudo reboot

Loxone Intercom Integration

UPDATE VOM 07.10.2025: Die neue Anleitung für die Loxone Intercom (inkl. Video) findet ihr hier: Howto: Loxone Intercom Videofeed in UniFi Protect einbinden UPDATE ENDE

Base24-String generieren aus Loxoneuser und Passwort (Login-Daten vom Miniserver, welche von der Loxone Intercom mit genutzt wird):

echo -n "loxoneuser:loxonepw" | base64

Mit auf die Cam-Main-VM (von weiter oben mit der 192.168.3.31) installieren:

Ordner erstellen und darin Configdatei öffnen:

mkdir -p ~/go2rtc-auth

cd ~/go2rtc-auth

nano go2rtc.yaml

Inhalte für die Config-Datei:

streams:
  http_mjpeg: "http://192.168.3.13/mjpg/video.mjpg#header=Authorization: Basic YWRtaW46anVuZTExbG94b25l"

rtsp:
  # Enable the RTSP server functionality
  listen: ":8553" # Port go2rtc listens on for RTSP connections (default: 8554)

go2rtc möchte auf Port 1984 laufen, weshalb wir das gleich berücksichtigen werden. Da auf der VM jedoch bereits go2rtc läuft von der Frigate-Instanz, hab ich den Port 1983 zugewiesen von aussen…)

Hier nutzen wir auch Docker-Compose, da wir gleich auch noch einen Watchdog per Sidecar-Container implementieren werden.

nano ~/go2rtc-auth/docker-compose.yml
services:
  go2rtc-auth:
    container_name: go2rtc-auth
    image: alexxit/go2rtc:latest
    restart: unless-stopped
    ports:
      - "1983:1984"
      - "8553:8553"
    devices:
      - /dev/dri:/dev/dri
    environment:
      - TZ=Europe/Berlin
    volumes:
      - ./go2rtc.yaml:/config/go2rtc.yaml
      - /etc/localtime:/etc/localtime:ro

  go2rtc-watchdog:
    container_name: go2rtc-watchdog
    image: docker:latest
    restart: unless-stopped
    entrypoint: [ "sh", "-c", "apk add --no-cache jq wget && sh /watchdog.sh" ]
    depends_on:
      - go2rtc-auth
    environment:
      - TZ=Europe/Berlin
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./watchdog.sh:/watchdog.sh:ro
      - /etc/localtime:/etc/localtime:ro

Jetzt noch den Watchdog füttern:

nano ~/go2rtc-auth/watchdog.sh
#!/bin/sh

# ==== EINSTELLUNGEN FÜR DEN ANWENDER ====
WATCHDOG_ENABLED=1
STREAM="http_mjpeg"                   # Name des Streams wie in go2rtc.yaml
CHECKURL="http://go2rtc-auth:1984/api/streams"
EXPECTED_REMOTE="172.19.0.1"

SLEEP_INTERVAL=30                     # Hauptwartezeit (Sekunden)
SLEEP_COMPARE=10                      # Wartezeit zwischen Messpunkten (Sekunden)
SLEEP_STARTUP=60                      # Initiales Warten (Sekunden)
SLEEP_AFTER_RESTART=300               # Wartezeit nach Restart (Sekunden)

restart_container_explicit() {
  name="$1"
  echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] Container '$name' wird neu gestartet..."
  docker restart "$name"
}

if [ "$WATCHDOG_ENABLED" -ne 1 ]; then
  echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] AUSGESCHALTET – Watchdog wird NICHT gestartet!"
  exit 0
fi

echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] Warte $SLEEP_STARTUP Sekunden auf ersten Stream-Aufbau..."
sleep $SLEEP_STARTUP

while true; do
  STREAM_JSON=$(wget -qO- "$CHECKURL")
  if [ -z "$STREAM_JSON" ] || ! echo "$STREAM_JSON" | jq -e . >/dev/null 2>&1; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] Fehler: API nicht erreichbar oder liefert ungültiges JSON!"
    restart_container_explicit "go2rtc-auth"
    restart_container_explicit "frigate"
    echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] Warte $SLEEP_AFTER_RESTART Sekunden nach Restart..."
    sleep $SLEEP_AFTER_RESTART
    continue
  fi

  # Prüfe, ob der gewünschte Stream überhaupt existiert
  if ! echo "$STREAM_JSON" | jq -e --arg STREAM "$STREAM" 'has($STREAM)' >/dev/null; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] Fehler: Stream '$STREAM' nicht vorhanden!"
    restart_container_explicit "go2rtc-auth"
    restart_container_explicit "frigate"
    echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] Warte $SLEEP_AFTER_RESTART Sekunden nach Restart..."
    sleep $SLEEP_AFTER_RESTART
    continue
  fi

  BYTES1=$(echo "$STREAM_JSON" | jq -r --arg STREAM "$STREAM" '.[$STREAM].producers[0].bytes_recv // 0')
  sleep $SLEEP_COMPARE
  STREAM_JSON2=$(wget -qO- "$CHECKURL")
  BYTES2=$(echo "$STREAM_JSON2" | jq -r --arg STREAM "$STREAM" '.[$STREAM].producers[0].bytes_recv // 0')

  # Clients extrahieren (kann null sein, also robust abfangen)
  CONSUMER_IPS=$(echo "$STREAM_JSON2" | jq -r --arg STREAM "$STREAM" '.[$STREAM].consumers // [] | map(.remote_addr // empty) | .[]' | cut -d: -f1)
  if [ -z "$CONSUMER_IPS" ]; then
    CONSUMER_IPS="(keine)"
  fi

  FOUND_EXPECTED=0
  for IP in $CONSUMER_IPS; do
    if [ "$IP" = "$EXPECTED_REMOTE" ]; then
      FOUND_EXPECTED=1
      break
    fi
  done

  # Fehlerfall: Kein Stream, kein Traffic, oder erwarteter Client fehlt
  if [ -z "$BYTES1" ] || [ -z "$BYTES2" ] || [ "$BYTES1" = "$BYTES2" ] || [ "$FOUND_EXPECTED" -ne 1 ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] WARNUNG: Stream $STREAM steht oder $EXPECTED_REMOTE ist nicht verbunden (Clients: $CONSUMER_IPS)"
    echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] Starte go2rtc-auth und frigate neu..."
    restart_container_explicit "go2rtc-auth"
    restart_container_explicit "frigate"
    echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] Warte $SLEEP_AFTER_RESTART Sekunden nach Restart..."
    sleep $SLEEP_AFTER_RESTART
  else
    echo "$(date '+%Y-%m-%d %H:%M:%S') [WATCHDOG] Stream $STREAM läuft, alles ok ($BYTES2 Bytes empfangen, Clients: $CONSUMER_IPS)"
    sleep $SLEEP_INTERVAL
  fi
done

Kurzzusammenfassung des Scripts:

  • Das Script prüft regelmäßig, ob ein bestimmter Kamerastream läuft und Daten liefert.
  • Es schaut, ob der gewünschte “Verbraucher” (zum Beispiel Frigate) mit der erwarteten IP verbunden ist.
  • Wenn der Stream nicht läuft, keine neuen Daten kommen, oder der richtige Client nicht verbunden ist, werden automatisch beide Dienste (go2rtc-auth und Frigate) neu gestartet. Frigate wird deshalb auch gleich mitgestartet, weil dessen Watchdog sowieso nach einem go2rtc-Neustart triggern würde, um Frigate neuzustarten – aber eben zeitverzögert. Das lässt sich somit beschleunigen.
  • Nach jedem Neustart wartet das Script einige Minuten, bevor es wieder prüft.
  • Jeder Schritt (Überprüfung, Neustart etc.) wird mit einem Zeitstempel ins Log geschrieben, damit man jederzeit nachverfolgen kann, was gerade passiert.

Wenn ihr den Watchdog (temporär) nicht nutzen möchtet, könnt ihr die Variable WATCHDOG_ENABLED=0 setzen.

Jetzt noch die notwendige Dateiberechtigung setzen mit:

chmod +x ~/go2rtc-auth/watchdog.sh

Den go2rtc-auth Docker Container-Stack starten mit (go2rtc-auth starten):

cd ~/go2rtc-auth/ && docker compose up -d

Das Log vom Watchdog lässt sich danach so einsehen:

docker logs -f go2rtc-watchdog

Und hier eine Beispielausgabe des Log:

[WATCHDOG] Warte 90 Sekunden nach Restart...
fetch https://dl-cdn.alpinelinux.org/alpine/v3.22/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.22/community/x86_64/APKINDEX.tar.gz
OK: 42 MiB in 78 packages
[WATCHDOG] Warte 60 Sekunden auf ersten Stream-Aufbau...
[WATCHDOG] Stream http_mjpeg läuft, alles ok (68678031 Bytes empfangen, Client: 172.19.0.1:41682)
[WATCHDOG] WARNUNG: Stream http_mjpeg steht oder falscher Client (unbekannt). Starte go2rtc-auth neu...
go2rtc-auth
[WATCHDOG] Warte 90 Sekunden nach Restart...
[WATCHDOG] Stream http_mjpeg läuft, alles ok (354064089 Bytes empfangen, Client: 172.19.0.1:49850)
[WATCHDOG] Stream http_mjpeg läuft, alles ok (563787293 Bytes empfangen, Client: 172.19.0.1:49850)
[WATCHDOG] Stream http_mjpeg läuft, alles ok (774113258 Bytes empfangen, Client: 172.19.0.1:49850)
[WATCHDOG] Stream http_mjpeg läuft, alles ok (984532153 Bytes empfangen, Client: 172.19.0.1:49850)
[WATCHDOG] Stream http_mjpeg läuft, alles ok (1195089203 Bytes empfangen, Client: 172.19.0.1:49850)

Mit „Strg + c“ lässt sich die Log-Ausgabe wieder schließen.

Nur zu Debugging-Zwecken, um zu sehen, ob eine Rückmeldung der API kommt:

docker exec -it go2rtc-watchdog sh

wget -qO- http://go2rtc-auth:1984/api/streams | jq .
Kurze Randnotiz:

Wenn der per go2rtc eingebundene non-auth-RTSP-Stream der Loxone Intercom einmal abreisst für mehr als einige Sekunden, verliert Frigate diesen Stream meistens komplett. In diesem Fall ist dann ein kompletter Frigate-Restart notwendig.

Anders verhält es sich bei ausfallenden Mobotix-RTSP-Streams (z.B. aufgrund eines Reboot der Kamera). Diese werden von Frigate wieder korrekt eingebunden, sobald sie wieder verfügbar sind - und das auch nach längerer Downtime.

Anscheinend "pusht" Mobotix den Stream hier irgendwie anders, sodass er in Frigate wieder zum Leben erweckt werden kann...

Und nun ist der RTSP-Stream abrufbar:

http://192.168.3.31:1983

Nur zwecks Vollständigkeit: Docker Container stoppen:

docker stop go2rtc-auth

docker stop go2rtc-watchdog

ODER ALLE Container des Stacks (der Docker-Compose stoppen):

cd ~/go2rtc-auth/ && docker compose stop

Und Docker Container löschen (go2rtc-auth löschen):

docker rm go2rtc-auth

docker rm go2rtc-watchdog

ODER ALLE Container des Stacks (der Docker-Compose löschen):

cd ~/go2rtc-auth/ && docker compose down

Danach noch die Debian VM hinzufügen (wie oben), um diesen RTSP-Stream zusätzlich per ONVIF-Server aufzubereiten…

Streaming-URLs der Loxone Intercom auf dem Weg zum Unifi Protect Dienst

Nachfolgend alle verfügbaren Streams auf dem Weg zum Ziel:

Kamera direkt MJPEG - per Browser oder per VLC aufrufbar -> Ablage -> Netzwerk öffnen
http://loxoneuser:loxonepasswort@192.168.3.13/mjpg/video.mjpg

Kamera go2rtc UI - per Browser aufrufbar
http://192.168.3.31:1983

kamera go2rtc mjpeg -> rtsp - per vlc aufrufbar -> Ablage -> Netzwerk öffnen
rtsp://192.168.3.31:8553/http_mjpeg

kamera frigate go2rtc - per browser aufrufbar
http://192.168.3.31:1984

kamera frigate ui - per browser aufrufbar
http://192.168.3.31:5000/#intercom

kamera frigate jpg - per browser aufrufbar
http://192.168.3.31:5000/api/intercom/latest.jpg

kamera frigate rtsp mp4 - per vlc aufrufbar -> Ablage -> Netzwerk öffnen
rtsp://192.168.3.31:8554/loxone-intercom

kamera onvif server - in unifi protect integrierbar
port 8899 (glaub ich)

Abschließende Integration in Unifi Protect

Achso – one more thing: Wie bindet man den nun ONVIF-fähigen Kamerastream in Unifi Protect ein? Easy: Die Kamera taucht automatisch in der Liste mit dem Namen „Cardinal“ auf.

Auf „Click to Adopt“ drücken, einfach irgendwas bei Benutzer und Passwort eingeben (es reicht jeweils ein Buchstabe) und auf „Confirm“ klicken.

Nach 1-2 Minuten sollte das Kamerabild spätestens angezeigt werden (aber es dauert immer etwas). In den Kameraeinstellungen kann jetzt ein sprechender Name vergeben werden.

Wenn nur alles im Leben so einfach wäre wie dieser letzte Schritt.. :DD

Die Latenz ist übrigens so 1-2s, was ich völlig vertretbar finde.

UPDATE VOM 23.07.205:

Wirklich Spaß macht es übrigens erst, wenn die externe Kamera(s) per Unifi AI Port verwaltet wird/werden. Denn dann wird der Kamera-Stream instant angezeigt, wenn man bspw. mit der Smartphone-App zugreift. Ohne AI Port dauert das teilweise ewig oder lief bei meinen Tests sogar teilweise in einen Timeout – zumindest bei meinen „workaround“-mäßig eingebundenen Mobotix-Kameras ist das so. Deshalb mein Tipp: am besten IMMER einen AI Port nutzen – damit kann man dann bis zu 3 externe Kameras AI-fähig machen (bis 1080p und 30fps) und erspart sich Frustrationen bei der App-Nutzung. Und mal ganz ehrlich: Die AI-Funktionen (Gesichtserkennung etc.) machen das Unifi-Protect-System doch erst sexy… UPDATE ENDE

Ich bin wirklich happy! Jetzt kann ich meine vor über acht Jahren installierten Mobotix-Kameras endlich so nutzen, wie ich es mir schon immer irgendwie vorgestellt habe – inklusive smoothstem Scrubbing in der Timelime und AI-basierter Eventüberwachung.

Hier übrigens ein Bild einer der Mobotix-Aussenkameras aus dem Blogpost Operation Gegensprechanlage – Am Ende wird doch noch alles gut vom 26.03.2018

Man kann über die offene API von Unifi Protect mittlerweile übrigens ganz einfach Webhooks erstellen, um bspw. die Info in Richtung NodeRED oder auch Home Assistant zu pushen, wenn ein Paket auf dem Bild erkannt wird – Stichwort: Benachrichtigung bei Ankunft eines Paketboten.

Um es auf die Spitze zu treiben, kann man dann sogar noch den AI Key (externer Link) integrieren, welcher bis zu 1.000 AI-Events (Kameraanzahl ist egal) verarbeiten kann und quasi jedes erkannte Event „labelt“ – inklusiver textueller Bildbeschreibung, nach der man filtern kann. So kann man – dank fortlaufend trainierter KI – bspw. passgenau ein externes Notify triggern (bspw. per Telegram-Nachricht), wenn ein DHL-Auto vorfährt und sich der Paketbote mit Paket unterm Arm der Haustür nähert. Und das alles ohne Cloud-Nutzung – komplett mit lokaler AI.

Zu nerdig? Nicht für mich. Ich möchte den AI Key definitiv in meinem Setup haben, auch wenn er schweine teuer ist. Der Spass ist es mir allemal wert. Nur leider ist der AI Key (externer Link) – im Unifi Store erhältlich – aktuell ausverkauft…

Vielleicht kann ich ja auch Unifi „anhauen“ mir einen AI Key für einen „Langzeittest“ zur Verfügung zu stellen. 😀 Lets see…

War/ist es dieser Aufwand wirklich wert am Ende des Tages?

Mit dieser Frage beschäftige ich mich tatsächlich immer häufiger. Mich begeistern solche aufwändigen Projekte, bei denen man alleine schon so viele technische Zusammenhänge lernt, aber nach wie vor enormst. Vielleicht wird das mal anders – hoffe ich aber ehrlich gesagt nicht. Gerade bei diesem Projekt war das Ziel von Anfang an klar, nur der Weg nicht so wirklich. Bzw. musste ich echt viele Wege beschreiten und einfach aufprobieren, um zu einer validen Lösung zu kommen.

Das ist einerseits echt frustrierend und ich wollte mehrfach einfach aufgeben – und habe das Thema auch wieder länger zur Seite gepackt – aber wenn man dranbleibt und es am Ende dann doch noch klappt, ist das schon ein cooles Gefühl. Und noch cooler, dass ich mit meinem Nerd-Wissen auch anderen Nerds weiterhelfen kann, die ähnliche „First-World-Problems“ lösen möchten. In diesem Sinne – lasst gerne einen Kommentar da, was euer größtes Nerd-Projekt in letzter Zeit war.

Nerd-Liste – nur für meine Doku…

Proxmox-ID - IP der Proxmox-VM - cam-name - Cam-IP - VM-MAC - UUID
400 192.168.3.31 cam-main
401 192.168.3.32 cam-park 192.168.3.22 bc:24:11:7d:da:0e c3f5d123-4567-89ab-cdef-1234567890ab
402 192.168.3.33 cam-balkon 192.168.3.23 bc:24:11:d6:a9:60 3a897b43-6345-482b-8897-dd909f1d97ea
402 192.168.3.34 BEREITS ANDERWEITIG VERGEBEN
403 192.168.3.35 cam-hochbeet 192.168.3.24 bc:24:11:68:20:ed 13919541-ce52-4e3a-8792-1a921662a5b2
404 192.168.3.36 cam-haustuer 192.168.3.25 bc:24:11:da:72:7d 3f9b16d5-1f44-4019-9eed-21254aa06c95
405 192.168.3.37 cam-terrasse 192.168.3.26 bc:24:11:2f:bb:6c c1a3bb18-6693-47fb-b877-358a8cbb1293
406 192.168.3.38 cam-parkplatz 192.168.3.27 bc:24:11:49:93:1e a9a4d13f-8d4c-4161-abd3-df626a13ccf6
402 192.168.3.39 BEREITS ANDERWEITIG VERGEBEN
402 192.168.3.40 BEREITS ANDERWEITIG VERGEBEN
402 192.168.3.41 BEREITS ANDERWEITIG VERGEBEN
407 192.168.3.42 cam-intercom 192.168.3.13 bc:24:11:e3:3d:28 b65d1426-1423-4f38-8257-a7124ad13ed3

Next steps (TODO)

  • Sicherstellen, dass das Gesamtsetup 100%ig stabil läuft über einen längeren Zeitraum. Evtl. braucht es hier noch Überwachungsmechanismen, um temporär ausgefallene Streams in Frigate zu „reaktivieren“ – z.B. beim Kamera-Neustart. Unifi Protect scheint hier schon mal relativ stressfrei zu sein, wenn Kameras zwischendrin mal nicht erreichbar sind. UPDATE: Bereits Watchdogs per Container-Sidecar eingebunden für frigate und go2rtc-auth – die onvif-server-Dienste fehlen noch, hier den Dienst erstmal per Docker lauffähig machen – evtl. sogar in der selben VM mit virtuellen Netzwerkverbindungen zwecks eindeutiger IP und MAC?…
  • Apple Homekit Integration – Alle Kameras über Homebridge für Apple Home bereitstellen (wollte ich schon immer mal machen)
  • Umzug auf Dream Machine Pro Max (externer Link) – Primär als Routerfunktion, aber dann eben auch als Unifi Protect Device – Pro Max weil das Modell flockige 8GB Ram hat.
  • Versuchen den Audiostream der externen Kameras in Unifi Protect nutzen zu können – Das wäre wirklich nice – finde dazu aber einfach nichts, in welchem Format/Codec der Audiostream vorliegen muss – und kann der ONVIF-Server-Dienst überhaupt das Audio durchreichen? Fragen über Fragen…
  • Abgreifen des Audiostreams der Loxone Intercom (externer Link) – kann man den überhaupt bei der neuen Intercom per SIP abgreifen? Finde dazu einfach nichts…
  • Einbindung des Unifi AI Key (externer Link) zur Live-Bildauswertung und Notifications (z.B. DHL fährt auf die Einfahrt) – Besorgen sobald wieder verfügbar…
  • Weitere(n) AI Port(s) (externer Link), um alle „dummen“ Kameras AI-fähig zu machen. Hat in meinem Setup auch den Vorteil, dass die Zugriffszeit auf den Kamerastream beschleunigt wird.

UPDATE VOM 22.07.2025

Über Nacht ist der Intercom-Kamerafeed abgerissen und Unifi Protect hat einfach das zuletzt übermittelte Frame dauerhaft angezeigt. Als ich im Frigate-Container dann den Terminal-Befehl

curl -s http://localhost:5000/api/stats | jq '.cameras.intercom.camera_fps'

abgesetzt habe, um über die Frigate-API (…/api/stats) den FPS-Wert abzuholen, kam als Rückmeldung „105.1“. Realistisch über 30 Frames? Ne, nicht wirklich.

Daran erkennt man also direkt, dass etwas faul ist und der Stream nicht mehr korrekt verarbeitet bzw. aufbereitet wird. Nach einem Reboot lieferte obiger Befehl dann wieder „5“ zurück. 5 Frames/s sind eigentlich auch Quatsch, da es laut „Medieninformationen“ in VLC eigentlich 20 FPS (bzw. 19.666666) sein müssten, aber das erkennt Frigate irgendwie nicht korrekt. Egal, jedenfalls habe ich jetzt einen Watchdog im Sinne eines Docker-Sidecar-Containers gebaut, welcher parallel zum Frigate-Container mitläuft und diesen Wert überwacht. Wenn der ausgelesene FPS-Wert über 50 ist, wird der Frigate-Container neugestartet – und damit eben auch der Frigate-Dienst (denn nur einen Kamerastream kann man leider per API nicht neustarten – deshalb diese Holzhammer-Methode). Das Ganze triggert dann maximal alle 10 Minuten – kein Plan, ob diese Zeit gut gewählt ist. Tendenziell müsste man diese Wohl mindestens auf eine Stunde erhöhen, oder?…

Erstmal die passende docker-compose.yml öffnen:

nano ~/frigate/docker-compose.yml

Und dann mit dem zusätzlichen Service namens „frigate-watchdog“ ausstatten:

services:
  frigate:
    container_name: frigate
    restart: unless-stopped
    image: ghcr.io/blakeblackshear/frigate:stable
    shm_size: "2g"
    mem_limit: 12g
    mem_reservation: 6g
    devices:
      - /dev/dri:/dev/dri
    group_add:
#      - "render"
      - "video"
    environment:
      - TZ=Europe/Berlin
    volumes:
      - ./config:/config
      - ./media:/media
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "5000:5000"
      - "8554:8554"
      - "1984:1984"
#      - "8899:8899"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000"]
      interval: 60s
      timeout: 5s
      retries: 3
      start_period: 30s

  frigate-watchdog:
    image: docker:latest
    container_name: frigate-watchdog
    restart: unless-stopped
    entrypoint: [ "sh", "/watchdog.sh" ]
    depends_on:
      - frigate
    networks:
      - default
    environment:
      - TZ=Europe/Berlin
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./watchdog.sh:/watchdog.sh:ro
      - /etc/localtime:/etc/localtime:ro

Kurze Zusammenfassung des Scripts:

  • Dienste-Erreichbarkeit: Prüft regelmäßig, ob Frigate und go2rtc erreichbar sind – wenn einer ausfällt, wird kein Restart ausgelöst, sondern nur eine Logmeldung geschrieben und der Check wiederholt.
  • CPU-Last: Restart von Frigate, wenn die CPU für längere Zeit über dem eingestellten Grenzwert liegt.

Anmerkung: Hatte das Problem jetzt schon mehrfach in längeren Abständen, dass sich irgendwas „frisst“ – vermutlich ein Stream – und dann nach ner halben Stunde etwa der gesamte Server – inklusive Proxmox-Host abschmiert. Dann hilft nur ein hartes Strom weg, Strom ran… Hier sieht man das ganz gut:

Mir fällt gerade auf, dass der Network traffic kurz vor der massiven Zunahme der CPU-Last einbricht. Das sollte auch im Watchdog überwacht werden…

  • Netzwerkverkehr: Restart von Frigate, wenn der eingehende Netzwerktraffic über ein bestimmtes Zeitfenster stagniert (aktuell nur RX überwacht, TX wird lediglich im Log angezeigt – hoffe das reicht so).
  • Kamera-FPS: Restart von Frigate, wenn die FPS der definierten Kamera zu hoch oder zu niedrig sind. (<1fps und >50fps)
  • Restart-Cooldown: Verhindert zu häufige Neustarts (max. 1 Restart pro Cooldown-Zeitraum).
  • Log-Ausgabe: Gibt aktuellen Status und Messwerte (CPU, Traffic, FPS) im Log aus – jeweils mit Zeitstempel.
  • Alle Schwellenwerte sind vom User einfach oben im Script einstellbar.

Jetzt also die Bashscript-Datei für den Watchdog-Service öffnen:

nano ~/frigate/watchdog.sh

Und mit dem gerade beschriebenen Inhalt füllen:

#!/bin/sh

# ==== EINSTELLUNGEN FÜR DEN ANWENDER ====
WATCHDOG_ENABLED=1
COOLDOWN=600
FRIGATE_URL="http://frigate:5000/api/stats"
GO2RTC_URL="http://192.168.3.31:1983/"
CPU_THRESHOLD=50
SLEEP_INTERVAL=60
NET_IDLE_TIMEOUT=60
CAM="intercom"
MIN_FPS=1
MAX_FPS=50

if [ "$WATCHDOG_ENABLED" -ne 1 ]; then
  echo "$(date '+%F %T') [WATCHDOG] AUSGESCHALTET – Watchdog wird NICHT gestartet!"
  exit 0
fi

apk add --no-cache curl jq bc

LAST_RESTART_FILE=/tmp/frigate_watchdog_last_restart

NET_PREV_RECV=""
NET_LAST_CHANGE=$(date +%s)

parse_bytes() {
  VAL=$(echo "$1" | sed 's/[^0-9.,eE+-]//g' | tr ',' '.')
  UNIT=$(echo "$1" | sed 's/[0-9.,eE+-]*//g' | tr -d ' ' | tr '[:lower:]' '[:upper:]')
  # Einheiten auf Bytes umrechnen, Zahl immer als Integer in Bytes!
  case "$UNIT" in
    GB) echo $(printf "%.0f" "$(echo "$VAL * 1024 * 1024 * 1024" | bc -l)") ;;
    MB) echo $(printf "%.0f" "$(echo "$VAL * 1024 * 1024" | bc -l)") ;;
    KB) echo $(printf "%.0f" "$(echo "$VAL * 1024" | bc -l)") ;;
    B|BYTE|BYTES|"") echo $(printf "%.0f" "$VAL") ;;
    *) echo 0 ;;
  esac
}

while true; do
  NOW_HUMAN="$(date '+%F %T')"

  if ! curl -sf "$GO2RTC_URL" > /dev/null; then
    echo "$NOW_HUMAN [WATCHDOG] go2rtc ($GO2RTC_URL) nicht erreichbar, überspringe diesen Zyklus."
    sleep $SLEEP_INTERVAL
    continue
  fi

  FRIGATE_RAW=$(curl -sf "$FRIGATE_URL")
  if ! echo "$FRIGATE_RAW" | jq empty 2>/dev/null; then
    echo "$NOW_HUMAN [WATCHDOG] Konnte von Frigate keine gültigen Daten lesen!"
    sleep $SLEEP_INTERVAL
    continue
  fi

  CPU=$(echo "$FRIGATE_RAW" | jq -r '.cpu_usages["frigate.full_system"].cpu // empty' | tr ',' '.')
  FPS=$(echo "$FRIGATE_RAW" | jq ".cameras.$CAM.camera_fps")
  NETIO=$(docker stats --no-stream --format "{{.NetIO}}" frigate 2>/dev/null)
  NET_RECV=$(echo "$NETIO" | awk -F/ '{print $1}' | xargs)
  NET_SENT=$(echo "$NETIO" | awk -F/ '{print $2}' | xargs)
  NET_RECV_NUM=$(parse_bytes "$NET_RECV")
  [ -z "$NET_RECV_NUM" ] && NET_RECV_NUM=0

  NOW=$(date +%s)
  RESTART_REASON=""

  # --------- Netzwerktraffic korrekt überwachen ----------
  if [ -z "$NET_PREV_RECV" ]; then
    NET_PREV_RECV=$NET_RECV_NUM
    NET_LAST_CHANGE=$NOW
    # Debug-Ausgabe: Zeige beide Werte, wenn frisch initialisiert
    # echo "$NOW_HUMAN [DEBUG] NET_PREV_RECV initialisiert: $NET_PREV_RECV ($NET_RECV)"
  else
    # echo "$NOW_HUMAN [DEBUG] Vergleich NET_RECV_NUM=$NET_RECV_NUM zu NET_PREV_RECV=$NET_PREV_RECV ($NET_RECV)"
    if [ "$NET_RECV_NUM" -gt "$NET_PREV_RECV" ]; then
      NET_LAST_CHANGE=$NOW
      NET_PREV_RECV=$NET_RECV_NUM
    fi
    if [ $((NOW - NET_LAST_CHANGE)) -ge $NET_IDLE_TIMEOUT ]; then
      RESTART_REASON="Kein Netzwerktraffic-Anstieg seit $NET_IDLE_TIMEOUT Sekunden (RX: $NET_RECV)"
    fi
  fi

  # CPU-Überwachung
  if [ "$CPU" != "" ] && [ "$(echo "$CPU > $CPU_THRESHOLD" | bc -l)" -eq 1 ]; then
    RESTART_REASON="CPU-Last kritisch ($CPU %)"
  fi

  # Kamera-FPS überwachen
  if [ "$FPS" != "" ] && [ "$FPS" != "null" ]; then
    if [ "$(echo "$FPS > $MAX_FPS" | bc -l)" -eq 1 ] || ( [ $MIN_FPS -ge 0 ] && [ "$(echo "$FPS < $MIN_FPS" | bc -l)" -eq 1 ] ); then
      RESTART_REASON="Kamera-FPS kritisch ($FPS)"
    fi
  fi

  if [ -n "$RESTART_REASON" ]; then
    if [ -f $LAST_RESTART_FILE ]; then
      LAST_RESTART=$(cat $LAST_RESTART_FILE)
      DIFF=$((NOW - LAST_RESTART))
    else
      DIFF=$COOLDOWN
    fi
    if [ $DIFF -ge $COOLDOWN ]; then
      echo "$NOW_HUMAN [WATCHDOG] Fehler! $RESTART_REASON. Frigate wird neu gestartet. (Traffic RX: $NET_RECV, TX: $NET_SENT, FPS: $FPS)"
      docker restart frigate
      echo $NOW > $LAST_RESTART_FILE
      NET_PREV_RECV=""          # Nach Restart: zurücksetzen!
      NET_LAST_CHANGE=$NOW
    else
      echo "$NOW_HUMAN [WATCHDOG] Fehler! $RESTART_REASON, aber letzter Restart erst vor $DIFF Sekunden, warte noch. (Traffic RX: $NET_RECV, TX: $NET_SENT, FPS: $FPS)"
    fi
  else
    echo "$NOW_HUMAN [WATCHDOG] OK. CPU: $CPU % | Traffic RX: $NET_RECV, TX: $NET_SENT | FPS: $FPS"
  fi

  sleep $SLEEP_INTERVAL
done

Die Datei zum Schluss noch ausführbar machen mit:

chmod +x watchdog.sh

Den Frigate-Container-Stack (Frigate + Watchdog) stoppen und neu starten mit:

cd ~/frigate

docker compose down

docker compose up -d

Sobald alles läuft, kann man dann noch das Watchdog-Log checken mit:

docker logs frigate-watchdog

ODER EINEN dauerhaft aktiven und sich aktualisierenden Log anzeigen lassen mit:

docker logs -f frigate-watchdog

Dann sollte sowas in der Art angezeigt werden:

2025-07-24 23:20:59 [WATCHDOG] OK. CPU: 19.7 % | Traffic RX: 507MB, TX: 319MB | FPS: 5.0
2025-07-24 23:22:01 [WATCHDOG] OK. CPU: 19.3 % | Traffic RX: 555MB, TX: 349MB | FPS: 5.0

Ich hoffe mal stark, dass der Watchdog im Falle eines Streaming-Problems durch den automatisierten Frigate-Neustart zu einer Besserung bringt.

BTW: Parallel ist mir auch noch etwas aufgefallen, was zusätzlich zu Problemen geführt hat – vielleicht gibt es einen Zusammenhang, vielleicht auch nicht… Mein „Haustür“-Stream, der von einer Mobotix-Kamera (MJPEG) stammt und eigentlich nur 720p hat, wurde in Unifi-Protect plötzlich als 4k-Stream deklariert. Infolgedessen hat der AI Port, welcher diesen Stream „smart“ macht, rumgezickt, da dieser so eingestellt ist, dass er drei Kamerastreams verarbeitet (Maximum bis 1080p und 30fps bei Nicht-Unfi-Kameras). Da jetzt aber einer dieser Streams als 4k ausgewiesen wurde, blieb der Haustür-Stream auch als Standbild hängen. Und an diesem AI-Port hängt auch der aufgehangene Stream der Loxone Intercom. Evtl. hat sich der Intercom-Stream überhaupt erst deshalb zerschossen, weil der AI Port rumgezickt hat wegen der 4k-Geschichte!? Wie auch immer, ich werde es beobachten, ob es jetzt sauber läuft.

UPDATE ENDE

WAS IST EIN AFFILIATE-LINK?

Wenn du auf einen Affiliate-Link klickst und über diesen Link einkaufst, bekomme ich vom betreffenden Online-Shop oder Anbieter eine Provision, was mich u.A. bei den laufenden Kosten den Blogs unterstützt. Für dich verändert sich der Preis nicht.

Ich habe meintechblog.de ins Leben gerufen, um meine Technikbegeisterung und Erkenntnisse mit dir teilen zu können. Ich veröffentliche regelmäßig Inhalte aus allen möglichen Technikbereichen, die mich aktuell beschäftigen. Mehr Infos zu mir

31 Kommentare

  1. Hallo Jörg,
    puh, ganz schön harte Kost und viel Input 😀
    Vielen Dank für deine Mühe das alles aufzuschreiben!

    Mir würde es gerade schon genügen, die Loxone Intercom in Protect reinzubringen, aber hier scheitere ich schon. Habe die Schritte soweit durchgeführt, ab „Debian VM erstellen für ONVIF-Server“, aber die Kamera bekomm ich nicht ins Protect rein – mir wird da leider nichts angezeigt.
    Kannst du mir nochmal kurz schreiben, welche Schritte dazu notwendig sind? Hab ich was übersehen?

    Antworten

    1. Hi Michael,
      ich glaube dazu werde ich nochmal ein neues Tutorial schreiben, um exakt die dafür notwendigen Schritte zu erklären. Dann werden alle notwendigen Services über ein Docker-Compose definiert und gut ist. Das sollte die Einrichtung dann maßgeblich erleichtern. Also bitte noch etwas Geduld.

      Viele Grüße
      Jörg

    2. Hi Jörg,

      das wäre mega!
      Man verliert dabei echt die Übersicht. Hatte es zwischenzeitlich auch mit dem go2rtc Addon für Homeassistant probiert, leider ebenfalls ohne Erfolg – in Protect wurde der stream nicht wiedergegeben…

      Viele Grüße
      Michael

    3. Ja ich werde meine Erkenntnisse der letzten Tage definitiv nochmal in einem Update-Blogpost teilen, sobald alles sauber läuft. Aber das dauert einfach, da ich mehrere Tage testen möchte, ob es wirklich stabil läuft.

      Dann wird die Einrichtung über ein Docker Compose einfacher – und der Betrieb nochmal stabiler dank Watchdog(s) per NodeRED-Container…

  2. Hallo Jörg,
    mal wieder ein sehr spannendes Thema! Für das ich wohl leider etwas mehr Zeit mitbringen muss, um alles bei mir umzusetzen, aber insbesondere meine beiden loxone Intercoms MUSS ich Dank dir jetzt einbinden 😀

    Blöde frage vllt.: Warum der ganze Umweg über zusätzlichen onvif Server etc., wenn die mobotix doch selber bereits onvif bieten? Zumindest tat es das meine ehemalige T26. Oder liegt es daran, dass die Drittanbieter onvif Anbindung bei Unifi eben doch nicht so einfach funktioniert und es so direkt nicht lief?
    Daran scheitere ich nämlich seit einer Weile. Während meine Hikvision Kamera per onvif in der synology surveillance Station tadellos lief, bekomme ich bei unifi einfach keinen stream ans laufen.

    Beste Grüße,
    Jens

    Antworten

    1. Hi Jens,
      danke dir!

      Ja da kann man viel Zeit versenken. Aber wenns am Ende wenigstens läuft…

      Meine Mobotix S15-Kameras sind einfach schon zu alt, dass sie weder ONVIF noch h264 als Codec mitbringen. Deshalb der Aufriss hier. Aber ohne die Erarbeitung des beschriebenen „Worklow“ hätte ich vermutlich auch nie die Loxone Intercom zum Laufen gebracht, da diese ja auch nur einen MJPEG-Stream mitbringt per http mitbringt – was es sogar schwieriger macht hat am Ende – wegen des http-Auth…

      Viele Grüße und Erfolg bei der Umsetzung
      Jörg

      PS: Ich bin immer noch etwas am Rumbasteln an dem ganzen Zeug. Vermutlich werde ich jetzt ALLES mit einem Docker-Compose als „Stack“ laufen lassen – dann mit virtuellen MAC-Adressen etc. Und dann wird auch noch NodeRED zum Einsatz kommen, um ein automatisches Error-Handling zu ermöglichen, wenn man ein Stream oder was auch immer zwickt. Aber gut Ding und so…

  3. Hi Jörg,

    bist Du mit dem Nuk denn eigentlich nachhaltig zufrieden? Läuft darauf auch dein Homeassistant und dein Windows für Loxone wie angekündigt?

    Ich baue gerade und überlege ob das nicht ein guter Allround Homeserver sein kann um zB später auch Spiele über Steam am TV zu spielen etc etc.
    Wie siehst Du das?

    Ausserdem habe ich eine Loxone-spezifische Frage: Ich bin ja Neuling und hab noch nicht viel probiert. Eine grosse Enttäuschung meines Spieltriebs war der Fakt, dass Steckdosen die über Relais angesteuert sind keinen Energieverbrauch zu messen scheinen. Du zeigst in einem Screenshot, dass Du den Energieverbrauch über Grafana misst – Kannst Du mir sagen wie? Vermute über irgendeinen Stecker?

    Tobi

    Antworten

    1. Hi Tobi,
      der verlinkte NUC ist leistungstechnisch einfach DER HAMMER. Bin sehr zufrieden!

      Es sollen alle „Dienste“ wie HomeAssistant und Co. darauf laufen, klar. Aktuell hab ich aber nur ne Win10 VM und eben den ganzen Kamerakram drauf laufen weil Frigate aktuell nicht 100%ig stabil durchläuft über mehrere Tage. Das liegt wohl an den MJPEG-Streams, die sehr fragil sind. Und teilweise ist mir der NUC trotz Virtualisierung dann komplett ausgestiegen nach einiger Zeit, nachdem ein Service gecrasht ist. Bin da gerade dabei über NodeRED eine Art Watchdog zu bauen, welcher den/die abgeschmierten Services rechzeitig stoppt und neustartet. Aber da möchte ich konzeptionell auch nochmal etwas umbauen und jede Kamera „einzeln“ anbinden. Also pro Kamera ein getrennter Container für Frigate und ONVIF-Server. Und für die Loxone Intercom dann eben noch ein GO2RTC-Server. Mehr dazu in einem kommenden Blogpost.

      Jedenfalls: Wenn das 100%ig rund läuft (muss ich eben noch etwas basteln), ziehe ich meine ganzen anderen Services einfach von meinem alten Intel NUC um auf den neuen. Denn Power hat der mehr als genug für ALLES. Das geht dann dank Proxmox und den automatischen Backups in wenigen Minuten. Das zeige ich evtl. auch nochmal im Detail. Habe jetzt nämlich auch endlich den Proxmox Backup Server am Laufen auf meinem QNAP NAS als VM. Der speichert jetzt täglich sämtliche VMs und LXC-Container platzsparend (durch inkrementelle Backups) ab und hält Backups für mindestens 30 Tage bereit. Aber auch wieder ein anderes Thema… 😀

      Inkl. Steam weiss ich aber nicht, ob das dann klappt. Denn diese VM bräuchte dann zwingend Zugriff auf die iGPU. Und diese ist – zumindest in meinem Fall – bereits gebunden an die VM, auf der die Frigate-Instanz(en) läuft/laufen. Aber evtl. kann man auf dieser VM auch Steam mit laufen lassen. Setzt voraus, dass Steam bspw. auf Ubuntu läuft. Da kenne ich mich aber nicht mit aus…

      Für die Leistungsmessung gibt es verschiedene Möglichkeiten. Es gibt bspw. KNX-Schaltaktoren mit Wirkleistungsmessung, wie den MDT AZI-0616.03 (externer Link), von dem ich glaub mittlerweile vier im Einsatz habe. Er hat sechs Kanäle und kostet pro Kanal knapp 40 Euro. Es gibt auch zig andere KNX-Aktoren mit Leistungsmessung. Aber wichtig ist, dass es Wirkleistungsmessung ist, da sonst nur die Scheinleistung gemessen werden kann. Und das hilft einem im Normalfall nicht so viel. Alternativ gibt es auch Hutschienenmodule mit Stromzangen, welche dann einfach über die zu messenden Phasen geklickt werden – so wie oftmals bei ein-/dreiphasigen Smartmetern. Da hab ich gerade das Modell Acrel ADW210 DI/DO (Aliexpress Link) geordert mit 12 Kanälen für knapp 240 Euro (mit Rabatten). Also nur knapp 20 Euro/Kanal. Hier lässt sich aber nur messen, nicht schalten. Diesen klemme ich dann selektiv hinter die bereits vorhandenen Schaltaktoren, die ich eben messen möchte. Die Schnittstelle ist dabei Modbus RTU, also braucht man noch einen „Übersetzer“ auf Modbus TCP, welcher nochmal knapp 20-30 Euro kostet. Aber mit dem Adapter kann man dann auch mehrere dieser Messadapter anbinden. Mal sehen, wie gut das perfomancetechnisch dann läuft, wenn ich alle Messwerte sekündliche abrufe…

      Dazu kommen sicher auch noch weitere Inhalte im Blog. Also gerne ein E-Mail-Abo dalassen und ein YouTube-Kanal-Abo (externer Link) kann natürlich auch nicht schaden, um neue Inhalte nicht zu verpassen… 😀

      Viele Grüße
      Jörg

  4. Danke Jörg. Abo auf beiden wegen ist erledigt 🙂

    @Frigate Instabil:
    Also ich komme aus der Software und für mich klingt das nach wahnsinnig viel Komplexität für eigentlich nicht so viel Ergebnis? (Soll nicht Klugscheisserisch klingen :-))
    Insbesondere Frigate würde ich loswerden wollen. Lt. meinem Kurzcheck mit GPT 4o bekomme ich auch ONVIF und RTSP aus go2rtc (dann über ffmpeg).
    Fehlt dann noch was?
    Meine Cases übrigens: Ich will die Unifi Doorbell in protect haben. Ausserdem gerne die Protect Streams in Loxone um am Wall-Tablet darauf zugreifen zu können. Apropos: Du hast ja dein 40″ Touch Display erwähnt – Du nutzt die Loxone Visualisierung oder nicht? Frage mich die ganze Zeit ob man das eigentlich will oder ob zB Homeassistant nicht eigentlich sogar besser ist.

    @Energiemessung: Danke!

    @Gaming: Ich bin auch kein Gamer, kann mir aber vorstellen das ab und zu mal zocken auch cool sein kann. Falls es Dich interessiert: Es gibt sogar eine Steam AppleTV App um von einem anderen Device mit Steam Server zu streamen. Der Server läuft wohl auch auf Ubuntu.

    Tobi

    Antworten

    1. hi Tobias,
      hast völlig recht bzgl. Komplexität mit Frigate. Dachte ich nutze das evtl. noch für erweiterte Erkennungen in Kombination mit dem Google TPU-Stick. Aber in diesem Kontext hier ist es echt Overkill. Zumal man Frigate immer nochmal später hinter die RTSP-Streams klemmen kann, welche von go2rtc aufbereitet werden. Habe jetzt schon wieder eine neue Installationsroutine ohne Frigate gebaut. Auch ohne ONVIF-Server, denn das braucht man tatsächlich auch nicht. Unifi Protect reicht tatsächlich einfach der RTSP-Stream, welcher per h264 bereitgestellt wird. Läuft damit auch wesentlich stabiler – zumindest bei meinen bisherigen Tests. Musste da bissl tricksen, um mehrere Kameras vernünftig integrieren zu können. Nutze dazu jetzt doch meinen älteren Intel NUC mit iGPU, welche direkt im Proxmost-Host genutzt werden kann. Aufgrund der ganzen Abhängigkeiten, die benötigt werden, nutze ich jetzt pro Kamera einen LXC-Container mit eigener IP und individueller MAC (wichtig für die Integration in Unifi Protect), welcher dann die notwendigen Dienste bereitstellt. Ist zwar nicht sauber (ich weiss), da man in einem LXC-Container keine Docker-Container laufen lassen soll, aber besser wirds jetzt nicht – da ich ja die iGPU zum Transkoding für jede Kamera benötige. Und das wird dann mit einer VM nichts – zumindest nicht so einfach. Naja egal. Eine Anleitung ist im Bau und wird die Tage dann veröffentlicht. Wenn man nur eine Kamera (z.B. die Loxone Intercom) integrieren möchte, ist das Setup jedenfalls sehr sehr einfach geworden…

  5. Voll super, danke! bin gespannt. Hab mein Proxmox setup gerade aufgesetzt und schaue mal was da so geht.
    Was sagst Du zu meiner Visualisierungsfrage? Nutzt Du das von Loxone? Will man das? 🙂

    Antworten

    1. Immer gerne Jonas!

      Wobei du schon den neuen verbesserten „Cam-Integrations-Stack“ quasi als Sneak-Peek-Beta-Tester bekommen hast. Wir dann bald gut formatiert auch als neuer Blogost veröffentlich für alle Interessierten. Hoffe das läuft jetzt auch bei mir 100$%ig stabil mit jetzt insgesamt sieben 3rd-Party-Kameras (1x Loxone Intercom und 6x Mobotix S15)…

      Viele Grüße
      Jörg

    2. Hey Jörg,
      Also ich kann mich da gerne auch als Beta-Tester des Docker Stacks für die loxone Intercom anbieten 😉
      Alles in Docker zu packen war da auch eh mein Ziel.

      Mit meiner Hikvision scheitere ich leider weiterhin, was aber glaube ich letztlich an dem stream der Kamera selber liegt…
      Wie hast du denn in protect einen reinen rtsp stream, ohne onvif, genau eingebunden (bekommen)?
      Während es per onvif bei mir grundsätzlich, zumindest mit der Authentifizierung und Listung, klappt, nimmt protect die credentials des rtsp streams nicht an.

      Naja, die eine Hikvision Kamera neige ich dazu abzuschreiben, aber die loxone Intercoms müssen rein 🙂

  7. Bei mir klappt es übrigens auf Teufel komm raus nicht mit dem Blacklisten des Grafikkartentreibers…

    root@proxmox:~# lspci -nnk -d 8086:7dd1
    00:02.0 VGA compatible controller [0300]: Intel Corporation Arrow Lake-P [Intel Graphics] [8086:7dd1] (rev 03)
    DeviceName: Onboard – Video
    Subsystem: ASUSTeK Computer Inc. Arrow Lake-P [Intel Graphics] [1043:88fe]
    Kernel driver in use: vfio-pci
    Kernel modules: i915, xe

    Antworten

  8. Hallo Jörg,
    wenn Windows 11 als VM auf Proxmox installiert wird kann ich die USB Schnittstelle des Rechners ganz normal nutzen?
    Bin am Überlegen ob ich evcc und so Weiter vom Raspi auf ein mini PC mit Proxmox umziehe aber ich Windows ja auch für meine Victron Anlage benötige.

    Viele Grüße

    Antworten

    1. Klar. Einfach das gewünschte USB-Device übers Proxmox-Menü an die VM weiterreichen – das ist absolut kein Stress. Runterfahren und Neustart der VM nicht vergessen, denn erst das wird das Device durchgereicht…

  9. Also echt harte Kost für den Abend, aber da ich schon mal auf dem Frigate Trip war nachvollziehbar.
    Was spricht eigentlich dagegen anstatt Frigate gleich vollständig auf eine Lösung von Ubiquiti zu setzen?
    UI UNVR Pro
    UI Protect 6.1
    UI AI Key (Verfügbarkeit aktuell bei 0)
    Bin nämlich auch gerade am überlegen gleich auf eine fertige UI Hardware zu wechseln, anstatt mein altes ebenfalls „wackeliges“ Frigate System auf neuer Hardware aufzusetzen.
    Gerade die Themen wie Benachrichtigungs-Trigger für z.B. Paketbote, Gesichtserkennung und bestimmte KFZ-Kennzeichen wären meine Prio 1 Themen.

    Antworten

    1. Hi Martin!
      Hab bei mir mittlerweile alles softwareseitig neu gemacht ohne Frigate und nur mit go2rtc. Das läuft jetzt nochmal stabiler und mit weniger „Overhead“. Anleitung kommt die Tage…

      Hinsichtlich „Hardwarestack“ möchte ich nach und nach weiter in Richtung Unifi migrieren. Aber meine Kameras an der Hauswand (aktuell Mobotix) kann ich leider nicht so einfach austauschen. Deshalb der hier beschriebene „Umweg“, um die Drittanbieterkameras für Unifi Protect zu „pimpen“.

      Bezüglich der Benachrichtungssache möchte ich definitiv auch auf den Cloud Key setzen. Hoffe der ist irgendwann wieder mal verfügbar. Warte hier gefühlt schon seit Monaten auf dessen Wiederverfügbarkeit. Frigate möchte ich mir dennoch offenhalten für irgendwelche „abgefahrenen“ Bildanalysesachen, die nicht in Unifi Protect möglich sind. Aber wenn der rtsp-Stream erstmal über Unifi-Protect verfügbar ist, ist die spätere Integration in Frigate ja auch kein Thema mehr. Lets see…

      Viele Grüße
      Jörg

  10. Hallo Jörg, dank dir vielmals für deine Arbeit.

    Möchte auch meine Loxone Intercom in mein Unifi Protect integrieren.
    Hauptsächlich um das Bild von der Intercom als zusätzliche (neben der Eingabe eines Codes am NFC Code Touch) Freigabe für das Öffnen der Tür und das Ausschalten der Alarmanlage zu nutzen.
    Denkst du das dies durch einen AI Port möglich ist? Warte schon auf sehnsüchtig auf deine aktualisierte Anleitung

    Antworten

    1. Klar geht das – eigentlich 🙂
      Habe ich neulich schon kurz in diesem YT-Short gezeigt: https://www.youtube.com/shorts/u2jC1qsYoaM

      Nach dem aktuellen Protect-Update steigt bei mir jedoch das Live-Bild mancher extern eingebundener Kameras randommäßig aus. Ich versuche gerade das Problem einzugrenzen. Hoffe ich löse das bald, dann gibt es das versprochene Update hier im Blog. Ach und – warum auch immer – wird mir die AI-Erkennung bei den selbst erzeugten Kamerastreams trotz AI-Port nicht mehr angezeigt bei der aktuellen Softwareversion. Lediglich die Bewegungserkennung wird aktuell unterstützt – da hat Unifi beim aktuellen Update irgendwas geändert/zerschossen. Denke aber, dass das nur temporärer Natur ist. Unifi ändert da aktuell wahnsinnig viel von Version zu Version…

      Viele Grüße
      Jörg

  11. Dank dir vielmals. Ich bin gerade am Überlegen ob ich mir den Ai Port zulege. Habe noch ein paar G4 Kameras am Haus verbaut. Bist du ansonsten mit der Ai Port Performance zufrieden?

    Antworten

    1. Die AI-Ports machen ultra Spass – und mit den Unifi-Kameras läuft das alles absolut reibungsfrei mit nur wenigen Klicks.

      Ultra cool ist dabei auch, dass man mit einem AI-Port mittlerweile bis zu fünf Unifi-Kameras „smart“ machen kann. Vorausgesetzt man stellt die Auflösung auf 1080p ein. Bei höherer Auflösung sind es dann weniger Kameras pro AI-Port. Bei 2k sind es glaub noch drei Unifi-Kameras, bei 4k nur noch eine Unifi-Kamera.

      So oder so: Die Erkennung ist wirklich top, wenn auch nicht perfekt. Aber man merkt buchstäblich, die Unifi das von Update zu Update immer weiter verbessert. Manchmal auch etwas verschlimmbessert – und dabei auch noch zig UI-Elemente ändert, wodurch man erstmal wieder suchen muss, wo alles ist – aber der Weg scheint mir insgesamt der Richtige zu sein.

      Viele Grüße
      Jörg

  12. Ich muß ehrlich sagen, dass ich zutiefst beeindruckt bin, was Ubuquiti da an Hardware und Software raushaut.
    Da kann sich so manche Firma eine Scheibe von Abschneiden (u.a. auch Loxone 😉 ).

    Antworten

    1. Kann ich nur 100% zustimmen. DER ABSOLUTE WAHNSINN, was Unifi da permanent raushaut an neuen Devices. Meine Wishlist wird zunehmend größer. 😀

      BTW: Die haben mittlerweile sogar eine Multi-Room-Audio-Lösung, die echt sexy aussieht. Bin ich neulich durch Zufall mal drübergestolpert -> https://ui.com/us/en/integrations/premium-iot/premium-audio

      Und sogar ne EV-Ladelösung sehe ich gerade. Brutal… :DDD

  13. Super Beitrag! Aber wann kommt der Teil mit der expliziten Loxone Integration wie in deinem Short gezeigt? https://www.youtube.com/shorts/u2jC1qsYoaM
    Die Trigger in Loxone zu verarbeiten wäre das Highlight!

    Antworten

  14. Sooo, also ich habe mittlerweile ein paar Monate den Nuc. Leider habe ich nie die GPU ans laufen gebracht (trotz deiner genauen Anleitung – sie will einfach nicht). Hast Du noch irgendwelche guten Referenzen dazu?

    Antworten

    1. Referenzen: ChatGPT fragen… 😀

      Kein Scherz, da bekommt man mit etwas Gefummel im Terminal sowas mit Sicherheit zum Laufen! Präzise Fragen stellen und ChatGPT bitten immer nur einen Schritt zu debuggen und auf Rückmeldung von dir warten. Dann Schritt für Schritt im Ping-Pong das Problem ausfindig machen und lösen.

      Viele Grüße und Erfolg
      Jörg

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Das könnte dir auch gefallen