Heute endlich die versprochene Integration der Loxone Intercom (Affiliate-Link) in UniFi Protect, um den Videostream hier als Überwachungskamera nutzen zu können.

Am Ende ist die Einbindung in nur wenigen Minuten erledigt, wenn man weiss, wie es geht. Ich habe hier wirklich hunderte von Stunden investiert, um diese Lösung zu finden. Wenn euch die Lösung weiterhilft und ihr euch erkenntlich zeigen möchtet, könnt ihr mir gerne etwas per Paypal rüberschieben oder den Loxkurs (externer Link) buchen – hier gibt es noch viele weitere spannende Inhalte, die euch als Loxone-User weiterhelfen.

Direkt zum Video:

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube immer entsperren

YouTube-Direktlink

Ich nutze mittlerweile einen MINIS FORUM MS-01 Mini Workstation Intel Core i9-12900H (Affiliate-Link) mit Proxmox, um alle meine Homelab-Dienste per LXC-Container bzw. Virtuelle Maschinen zu „erschlagen“.

Ein Raspberry Pi tut es bei den meisten vermutlich auch, aber ich würde euch dennoch mindestens einen Intel N100 (Affiliate-Link) empfehlen. Hier bekommt man für um die 150 Euro einen Komplettrechner, meist mit 16GB Ram und 512GB SDD. Perfekt fürs die meisten Aufgaben – und mit eingebauter Hardwarebeschleunigung im Kontext Videotranscoding – und das brauchen wir nachfolgend zwingend, um den gurkigen MJPEG-Stream der Loxone Intercom in h264 umzuwandeln, sodass ihn UniFi Protect versteht.

Debian-Umgebung erstellen (LXC-Container in Proxmox verfügbar machen)

Folgende Befehle in der Proxmox Konsole eingeben:

pveam update && \ pveam available | grep debian- | grep standard

Ausgabe in meinem Fall:

system debian-12-standard_12.12-1_amd64.tar.zst
system debian-13-standard_13.1-2_amd64.tar.zst

Dann laden wir die gewünschte (aktuellste) Version herunter:

pveam download local debian-12-standard_12.12-1_amd64.tar.zst

Jetzt den LXC-Container in Proxmox erstellen:

pct create 1001 \
  /var/lib/vz/template/cache/debian-12-standard_12.12-1_amd64.tar.zst \
  --hostname intercom \
  --password meinpasswort \
  --cores 1 \
  --memory 512 \
  --net0 name=eth0,bridge=vmbr0,ip=dhcp,type=veth \
  --rootfs local-lvm:4 \
  --unprivileged 0 \
  --start 1

In die Konsole des gerade erstellten LXC-Containers springen mit dem Befehl:

pct enter 1001

Alternativ einfach im Proxmox UI links in der Leiste den LXC-Container 1001 anklicken und >_ Console auswählen. In meinem Fall wurden hier aber keine Konsolenbefehle entgegegengenommen. Deshalb hab ich einfach mit dem „pct enter 1001“-Befehl gearbeitet…

Nun sollte

root@intercom:~#

angezeigt werden. Dann werden nachfolgende Befehl direkt im LXC-Container ausgeführt. Mit „exit“ kann man dann wieder zum Proxmox-Host zurückspringen. Das wollen wir an dieser Stelle aber noch nicht.

Mit dem Befehl

hostname -I | awk '{print $1}'

können wir erstmal die IP-Adresse des LXC-Containers checken. In meinem Fall:

192.168.3.174

Die IP notieren – wird später in UniFi Protect wichtig.

Intercom MJPEG-Stream ohne Authorization verfügbar machen

Damit go2rtc später den MJPEG-Stream der Intercom entgegen nehmen kann, musste ich die Authorization aus dem Stream über das Tool nginx entfernen – bzw. stellt nginx den Stream einfach nochmal ohne Authorization im Sinne eines Reverse Proxy bereit. Anders hab ich es einfach nicht hinbekommen. Das geht so…

Erstmal die IP-Adresse der Intercom im Browser eingeben – in meinem Fall:

http://192.168.3.13

Die IP-Adresse findet man entweder in der Loxone-Config beim betreffenden Intercom-Element oder eben per Netzwerkscanner.

Jetzt sollte ein Pop-Up erscheinen, in welchem man die Zugangsdaten eintragen muss:

Gewöhnlich sind das der Login des Admin-Benutzers, welcher auch Zugriff auf die Loxone Config hat – da diese automatisch beim „Anlernen“ der Intercom vom Miniserver übernommen werden.

Nach dem Login sollte der MJPEG-Stream unter dieser URL erreichbar sein:

http://192.168.3.13/mjpg/video.mjpg

Funktioniert…

Sofern der Login mit den Zugangsdaten (hier: admin und loxonepw) geklappt hat, muss diese Benutzer-Passwort-Kombination ins base64-Format gebracht werden mit dem Befehl:

echo -n "admin:loxonepw" | base64

In diesem Fall wird dann dieser String angezeigt:

YWRtaW46bG94b25lcHc=

Diesen notieren, da er gleich gebraucht wird.

Jetzt erstmal den Dienst nginx installieren, welcher den Kamerastream gleich ohne Authorization zur Verfügung stellen wird.

apt update && \
apt install -y nginx-core

Vorhandene Config sichern:

mv /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

Neue Config erstellen:

cat >/etc/nginx/nginx.conf <<'EOF'
worker_processes 1;

events {
    worker_connections 1024;
}

http {
    server {
        listen 8081;

        location /mjpg/ {
            proxy_pass http://192.168.3.13/mjpg/;
            proxy_set_header Authorization "Basic YWRtaW46bG94b25lcHc=";
            proxy_set_header Host $host;
            proxy_set_header Connection "";
            proxy_http_version 1.1;
            proxy_buffering off;
        }
    }
}
EOF

Kurzes UPDATE hinsichtlich möglichen Sicherheitsbedenken:

Wer den Reverse Proxy nach „außen“ schließen möchte, sodass nur aus dem LXC-Container raus selbst auf den Dienst zugegriffen werden darf, ändert einfach die Zeile

listen 8081;

zu

listen 127.0.0.1:8081;

Hab das selbst jetzt noch nicht getestet. Gerne Feedback per Kommentar, ob das klappt…

UPDATE ENDE

Dienst aktivieren und neustarten:

nginx -t && systemctl enable --now nginx && \
systemctl reload nginx

Mit dem Befehl

systemctl status nginx

kann man direkt checken, ob der Dienst läuft. Das sollte dann so aussehen:

root@intercom:~# systemctl status nginx ● nginx.service – A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled) Active: active (running) since Tue 2025-10-07 08:05:19 UTC; 4min 45s ago Docs: man:nginx(8) Process: 1565 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=0/SUCCESS) Main PID: 1302 (nginx) Tasks: 2 (limit: 76583) Memory: 5.5M CPU: 46ms CGroup: /system.slice/nginx.service ├─1302 „nginx: master process /usr/sbin/nginx -g daemon on; master_process on;“ └─1566 „nginx: worker process“ Oct 07 08:05:19 intercom systemd[1]: Starting nginx.service – A high performance web server and a reverse proxy server… Oct 07 08:05:19 intercom systemd[1]: Started nginx.service – A high performance web server and a reverse proxy server. Oct 07 08:05:21 intercom systemd[1]: Reloading nginx.service – A high performance web server and a reverse proxy server… Oct 07 08:05:21 intercom nginx[1491]: 2025/10/07 08:05:21 [notice] 1491#1491: signal process started Oct 07 08:05:21 intercom systemd[1]: Reloaded nginx.service – A high performance web server and a reverse proxy server. Oct 07 08:09:58 intercom systemd[1]: Reloading nginx.service – A high performance web server and a reverse proxy server… Oct 07 08:09:58 intercom nginx[1565]: 2025/10/07 08:09:58 [notice] 1565#1565: signal process started Oct 07 08:09:58 intercom systemd[1]: Reloaded nginx.service – A high performance web server and a reverse proxy server. root@intercom:~#

Jetzt sollte über den Browser der Intercom-Stream ohne Authorization erreichbar sein über die URL:

http://192.168.3.174:8081/mjpg/video.mjpg

192.168.3.174 ist in diesem Fall natürlich die IP des LXC-Containers, auf dem jetzt nginx läuft und als Reverse Proxy arbeitet…

Juhu!

Schon mal die halbe Miete…

Hardwareressourcen korrekt an den LXC-Container durchreichen

Jetzt müssen wir aus dem oldschool MJPEG-Stream mit Hilfe von go2rtc einen passenden h264-Stream machen, damit ihn UniFi-Protect auch versteht.

Vorher müssen wir aber noch sicherstellen, dass der LXC-Container korrekten Zugriff auf die Hardwareressourcen hat. Konkret auf die iGPU des Intel-Chips, welche hardwareseitig beim Transcoding (Umwandeln von MJPEG zu h264) unterstützt. Macht man das nicht, erzeugt man unnötig CPU-Last.

Die nachfolgenden Befehle sind NUR für Intel-Rechner mit kompatibler CPU notwendig!

Evtl. liefere ich auch noch weitere Infos nach, wie man es auf einem Raspberry Pi 4 macht…

Erstmal im LXC-Container checken, ob die Ressourcen evtl. schon vorhanden sind:

pct enter 1001  && \
ls -l /dev/dri

In meinem Fall kommt dann direkt:

root@intercom:~# ls -l /dev/dri ls: cannot access ‚/dev/dri‘: No such file or directory

Dann mit

exit

auf die Konsole des Proxmox-Host wechseln.

Auf dem Proxmox-Host checken, ob Ressourcen verfügbar sind:

ls -l /dev/dri || true

Da sollte dann sowas hier angezeigt werden:

root@proxi:~# ls -l /dev/dri || true total 0 drw-rw—- 2 root root 80 Aug 21 00:22 by-path crw-rw—- 1 root video 226, 1 Aug 21 00:22 card1 crw-rw—- 1 root render 226, 128 Aug 21 00:22 renderD128

Wenn card1 und renderD128 angezeigt werden, kann man mit den folgenden Schritten weitermachen.

Jetzt /dev/dri für VAAPI an den LXC durchreichen (Befehle auf dem Proxmox-Host ausführen!)

pct stop 1001

printf '%s\n' \
'lxc.cgroup2.devices.allow: c 226:* rwm' \
'lxc.mount.entry: /dev/dri dev/dri none bind,optional,create=dir' \
>> /etc/pve/lxc/1001.conf

pct start 1001 && \
pct enter 1001

Jetzt sollte der Befehl

ls -l /dev/dri

das hier ausgeben:

root@intercom:~# ls -l /dev/dri total 0 drw-rw—- 2 root root 80 Aug 20 22:22 by-path crw-rw—- 1 root video 226, 1 Aug 20 22:22 card1 crw-rw—- 1 root 993 226, 128 Aug 20 22:22 renderD128

Nun notwendige APT-Repository-Einträge für Debian 12 ergänzen und die passende Pakete und Treiber installieren, damit die Hardwareressource auch genutzt werden kann:

cat >/etc/apt/sources.list <<'EOF'
deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb http://security.debian.org bookworm-security main contrib non-free non-free-firmware
EOF
apt update && \
apt install -y wget ffmpeg vainfo intel-media-va-driver-non-free

Ob alles geklappt hat, erfährt man mit dem Befehl:

vainfo --display drm | head -n 20

Es sollte dann sowas hier ausgegeben werden:

root@intercom:~# vainfo –display drm | head -n 20 libva info: VA-API version 1.17.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_17 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.17 (libva 2.12.0) vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics – 23.1.1 () vainfo: Supported profile and entrypoints VAProfileNone : VAEntrypointVideoProc VAProfileNone : VAEntrypointStats VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSliceLP VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSliceLP VAProfileJPEGBaseline : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointEncPicture VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP VAProfileVP8Version0_3 : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSliceLP VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSliceLP

Jetzt sind alle vorbereitenden Schritte abgeschlossen und wir können go2rtc installieren…

Loxone MJPEG-Stream per go2rtc in h264 umwandeln

go2rtc herunteralden und Dateirechte anpassen:

wget -O /usr/local/bin/go2rtc https://github.com/AlexxIT/go2rtc/releases/latest/download/go2rtc_linux_amd64 && \
chmod +x /usr/local/bin/go2rtc

Config schreiben:

cat >/etc/go2rtc.yaml <<'EOF'
streams:
  intercom: "ffmpeg:http://localhost:8081/mjpg/video.mjpg#video=h264#width=1280#height=720#raw=-r 20#raw=-maxrate 5000#raw=-bufsize 10000#raw=-g 20#hardware=vaapi"

rtsp:
  listen: ":8554"
EOF

Config, um bspw. eine Mobotix-Kamera direkt ohne NGINX Reverse Proxy einzubinden (NICHT NUTZEN, WENN EINE LOXONE INTERCOM EINGEBUNDEN WIRD!!!):

cat >/etc/go2rtc.yaml <<'EOF'
streams:
  park: "ffmpeg:rtsp://mobotixuser:mobotixpw@192.168.3.22:554/stream0/mobotix.mjpeg#video=h264#width=1280#height=720#raw=-r 20#raw=-maxrate 5000#raw=-bufsize 10000#raw=-g 20#hardware=vaapi"

rtsp:
  listen: ":8554"
EOF

Systemd-Service anlegen und starten:

cat >/etc/systemd/system/go2rtc.service <<'EOF'
[Unit]
Description=go2rtc RTSP bridge
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStartPre=/bin/sleep 10
ExecStart=/usr/local/bin/go2rtc -config /etc/go2rtc.yaml
Restart=always

[Install]
WantedBy=multi-user.target
EOF

Dienst laden, aktivieren, starten, prüfen:

systemctl daemon-reload && \
systemctl enable --now go2rtc && \
systemctl status go2rtc --no-pager

Nun sollte go2rtc per Web-UI erreichbar sein über den Port 1884:

http://192.168.3.174:1984

Hier sollte dann auch direkt der „intercom“-Eintrag vorhanden sein:

Hier könnt ihr auf „stream“ klicken und es sollte sich nach kurzer Bedenkzeit der Stream im Browser – jetzt im h264-Format öffnen:

Geschafft!

Als letzten Test kann man jetzt noch den VLC (Mediaplayer) anschmeissen und über den Menüpunkt -> Ablage -> Netzwerk öffnen -> URL

rtsp://192.168.3.174:8554/intercom

eintragen und auf „Öffnen“ klicken.

Whoohooo!

Dieser Feed wird dann gleich in UniFi Protect verwendet werden können.

UPDATE bzgl. möglichen Sicherheitsbedenken

Der gleich genutzte go2rtc-Port 1984 zwecks Einbindung in UniFi Protect ist nicht passwortgeschützt. go2rtc bietet diese Funktion zum aktuellen Zeitpunkt leider nicht. Wer hier einen Schutz benötigt, muss an dieser Stelle noch einen Reverse Proxy „vorschalten“…

UPDATE ENDE

Nochmal kurz eine Notiz am mich selbst, da ich noch ausprobieren möchte, ob die Integration mit dem "ONVIF-Server" Progrämmchen (wie im Blogpost Hardcore-Tech-Howto: Quasi jeden Uralt-Kamerastream in UniFi Protect nutzbar machen (NERDALARM!) beschrieben) doch nochmal besser funktioniert, was die Kombination mit dem AI-Port angeht. Dabei benötigt man die Snapshot URL der Kamera, welche im Fall von go2rtc so aussieht:
http://192.168.3.174:1984/api/frame.jpeg?src=intercom

Einige Zeit später... ALSO...
Ja, in Kombination mit dem ONVIF-Server Zusatzprogramm läuft die Integration in UniFi Protect besser. Hier kann man wieder alle AI-Funktionen im Kombination mit dem AI Port (und dann weiterführend mit dem AI Key) nutzen. Wie man den OVIF-Server installieren kann, habe ich zwar bereits im Blogpost https://meintechblog.de/2025/07/18/hardcore-tech-howto-quasi-jeden-uralt-kamerastream-in-unifi-protect-nutzbar-machen-nerdalarm/ beschrieben, aber der Vollständigkeit halber am Ende des Blogposts nochmal im Detail (jetzt als root-User)...

Intercom in UniFi Protect hinzufügen

In UniFi Protect ist das Hinzufügen jetzt ganz einfach.

Schritt 1

Erstmal in die Liste aller Devices reingehen. Dann sollte links oben (die Stelle ändert sich manchmal je nach Softwareversion) ein Button mit einem „?“ vorhanden sein.

Schritt 2

Hier draufklicken und beim nächsten Auswahlmenü unten „try advanced adoption“ anklicken

Schritt 3

Hier dann die IP-Adresse samt Port eingeben vom go2rtc-Dienst (hier 192.168.3.174:1984) und bei Username und Passwort einfach ein „a“ eintragen.

Schritt 4

Jetzt auf „Confirm“ klicken und nach einigen Sekunden sollte ein neues Device namens „go2rtc“ in der Liste auftauchen.

Einmal mit der Maus drüber hovern und es sollte das Live-Bild angezeigt werden.

Der Name lässt sich dann natürlich noch anpassen und sofern man einen AI-Port hat, lassen sich auch AI-Funktionen (Gesichtserkennung etc.) hinzufügen.

Wobei in der aktuellen Protect Version 6.1.7.8 die Jungs von UniFi da etwas kaputtgebastelt haben. In dieser Version läuft die Kamera bei mir ohne AI-Port-Integration zwar absolut zuverlässig, jedoch kann ich nach der Zuweisung zu einem AI-Port keine AI-Funktionen nutzen – lediglich Bewegungserkennung. Und der Stream bricht auch hin und wieder ab.

In der Softwareversion zuvor lief es ohne AI-Port nicht zuverlässig, dafür aber mit AI-Port-Support absolut stabil und inklusive AI-Funktionen. Naja, anscheinend passiert da einiges unter der Haube von Update zu Update – warten wir ab, ob es beim nächsten Update wieder tut. (BTW: Mit meiner „regulär“ per Onvif eingebundenen Mobotix S15d klappt die Integration per AI-Port perfekt – inkl. Erkennung von Personen, Tieren, Gesichtern, Nummernschildern, etc… Es liegt also anscheinend an der hier gezeigten Integrationsmethode ohne die im vorherigen Blogpost Hardcore-Tech-Howto: Quasi jeden Uralt-Kamerastream in Unifi Protect nutzbar machen (NERDALARM!) beschriebenen Methode per dediziertem Onvif-Server)

UPDATE: Nachfolgend noch die Installation der ONVIF-Server Applikation, da damit die Integration in UniFi Protect doch besser ist (AI-Port-Integration und Automatische Adoption inkl. definierbarer Kameranamensdetails):

ONVIF-Server installieren

apt update && apt install curl -y && \
curl -fsSL https://deb.nodesource.com/setup_lts.x | bash - && \
apt install -y nodejs git

cd ~ && \
git clone https://github.com/daniela-hase/onvif-server.git && \
cd onvif-server  && \
npm install

mac-Adresse anzeigen lassen mit:

ip link show eth0 | awk '/ether/ {print $2}'

In meinem Fall wird dann angezeigt:

bc:24:11:0f:a9:01

Alternativ mit:

ip a

Sowas kommt dann zurück:

root@intercom:/# 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: eth0@if924: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether bc:24:11:0f:a9:01 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 192.168.3.174/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 19102sec preferred_lft 19102sec inet6 fd05:7a73:7762:4841:be24:11ff:fe0f:a901/64 scope global dynamic mngtmpaddr valid_lft 1680sec preferred_lft 1680sec inet6 fe80::be24:11ff:fe0f:a901/64 scope link valid_lft forever preferred_lft forever

bc:24:11:0f:a9:01 ist dann die mac-Adresse, die wir gleich im Config-file brauchen bei „mac: bc:24:11:0f:a9:01“

apt install -y uuid-runtime && \
uuidgen

Jetzt wird ein zufälliger String ausgegeben in dieser Form:

86036b62-626e-483d-9ae1-d751a23b0c12

Dieser wird gleich als „uuid: 86036b62-626e-483d-9ae1-d751a23b0c12“ in der Config-Datei genutzt…

cat <<'EOF' > ~/onvif-server/config.yaml
onvif:
  - mac: bc:24:11:0f:a9:01
    ports:
      server: 8899
      rtsp: 8556
      snapshot: 8580
    name: Intercom
    uuid: 86036b62-626e-483d-9ae1-d751a23b0c12
    highQuality:
      rtsp: /intercom
      snapshot: /api/frame.jpeg?src=intercom
      width: 1280
      height: 720
      framerate: 20
      bitrate: 8192
      quality: 4
    lowQuality:
      rtsp: /intercom
      snapshot: /api/frame.jpeg?src=intercom
      width: 1280
      height: 720
      framerate: 20
      bitrate: 8192
      quality: 1
    target:
      hostname: localhost
      ports:
        rtsp: 8554
        snapshot: 1984
EOF

Mit nano in die Datei rein und gewünschte Paramater anpassen:

nano ~/onvif-server/config.yaml

Manuell starten zum Testen:

cd ~/onvif-server && \
node main.js config.yaml

Kann mit CTRL + c beendet werden.

Als Service laufen lassen:

cat >/etc/systemd/system/onvif-server.service <<'EOF'
[Unit]
Description=ONVIF Server
After=go2rtc.service network-online.target
Wants=go2rtc.service network-online.target

[Service]
Type=simple
WorkingDirectory=/root/onvif-server
ExecStartPre=/bin/sleep 12
ExecStart=/usr/bin/node /root/onvif-server/main.js /root/onvif-server/config.yaml
Restart=always
User=root
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload && \
systemctl enable --now onvif-server

Service Status checken:

systemctl status onvif-server --no-pager

Service neustarten:

systemctl restart onvif-server

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

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: 'IntercomHqCameraConfiguration',

Name: 'IntercomLqCameraConfiguration',

Manufacturer: 'Intercom',

Model: 'Loxone',

onvif://www.onvif.org/name/LoxoneIntercom

Das geht bspw. mit nur einem Befehl auch so:

sed -i \
  "s/CardinalHqCameraConfiguration/IntercomHqCameraConfiguration/g; \
   s/CardinalLqCameraConfiguration/IntercomLqCameraConfiguration/g; \
   s/Manufacturer: 'Onvif'/Manufacturer: 'Intercom'/g; \
   s/Model: 'Cardinal'/Model: 'Loxone'/g; \
   s|onvif://www.onvif.org/name/Cardinal|onvif://www.onvif.org/name/LoxoneIntercom|g" \
  ~/onvif-server/src/onvif-server.js

Dann die Datei speichern und den Dienst neustarten mit:

systemctl restart onvif-server

Wenn bei UniFi Protect unter Settings -> General -> Discover 3rd-Party Cameras der Haken gesetzt wird, sollte die gerade eingerichtete Kamera in wenigen Sekunden automatisch in der Device-Liste als „Cardinal“ auftauchen mit der Option zum Hinzufügen.

Bei der in UniFi Protect neu erkannten Kamera steht dann bei „Name“ „Cardinal“ und bei „Model“ ebenfalls „LoxoneIntercom“. Wenn man dann „Click to Adapt“ auswählt (bei User und Passwort jeweils a eintragen), ändert sich der angezeigte Name in „Loxone Intercom“ und bei Model wird nach ca 5-10s auch korrekt „LoxoneIntercom“ angezeigt. (kann sein, dass das je nach Version anders ist)

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.