Hallo zusammen! 
Ich möchte eine vollständige Erfahrungsmeldung teilen, die sich in ein Integrationsprojekt für Gladys verwandelt hat. Auf dem Programm steht: Wie ich eine Kamera, die TP-Link absichtlich eingeschränkt hat (kein RTSP, kein ONVIF), vollständig lokal zum Laufen gebracht habe, mit KI-Objekterkennung (Person, Hund, Katze… und sogar Pferd 
), alles auf einem Mini-PC, der bereits 2 Gladys und einen Home Assistant betreibt. Und am Ende der Entwicklungsvorschlag, den ich starten möchte.
Haltet euch fest, es ist etwas lang, aber alles ist reproduzierbar. 
Das Ausgangsproblem
Ich habe mehrere Tapo-Kameras, darunter eine C660 (4K, Schwenk/Neige, Solar/Batterie — aber bei mir an die Steckdose angeschlossen, die Batterie dient nur als Notfallreserve).
Ich wollte das Gleiche wie alle anderen hier: Meine Kameras steuern und Benachrichtigungen über Erkennungen (Person, Tier…) lokal in Gladys / Node-RED über MQTT erhalten, ohne von der TP-Link-Cloud abhängig zu sein.
Erste Hürde: Bei der gesamten Batterie/Solar-Reihe (C425, C460, C660, C645D, D230…), deaktiviert TP-Link RTSP und ONVIF. Das wird vom Hersteller bewusst so gemacht und dokumentiert: „Energiesparen“. Dass die Kamera dauerhaft an der Steckdose hängt, ändert nichts, das entscheidet die Firmware. 
Eine Überprüfung, die keinen Zweifel lässt:
$ nmap -Pn -p 443,554,2020,8800 10.6.0.222
PORT STATE SERVICE
443/tcp open https
554/tcp closed rtsp ← RTSP geschlossen
2020/tcp closed onvif ← ONVIF geschlossen
8800/tcp open ??? ← hmm... 👀
RTSP und ONVIF geschlossen… aber ein mysteriöser Port 8800 offen.
Zweite Hürde, die auch für Tapo-Kameras mit RTSP (meine C520WS zum Beispiel) gilt: Die Meldung von Erkennungsereignissen über ONVIF ist bei mehreren Modellen kaputt (bekannter Firmware-Bug). Also auch mit RTSP keine zuverlässigen lokalen Benachrichtigungen.
Die Umgehung: go2rtc spricht „Tapo“
Der Port 8800 ist das proprietäre TP-Link-Protokoll — das, das die Tapo-App verwendet. Und es stellt sich heraus, dass go2rtc (AlexxITs Video-Swiss-Army-Knife, eingebettet in Frigate UND in Home Assistant) es nativ über eine Quelle tapo:// sprechen kann.
Die vollständige Architektur wird:
Kamera (tapo://, rtsp://, onvif://, ...) → go2rtc → Frigate (KI-Erkennung) → MQTT → Gladys / Node-RED
Und der Schlüsselpunkt: Frigate übernimmt die Objekterkennung, nicht die Kamerasoftware. Also kein ONVIF mehr nötig, kein Cloud-Zugriff, und eine bessere Erkennung als die von TP-Link — die Tapo-App sagt mir „Tier“ für alles, Frigate unterscheidet person, dog, cat, horse (COCO-Labelmap, 91 Klassen). Ich brauche die Pferde genau zu erkennen, sagen wir mal, das ändert alles. 
Die Fallstricke (um euch Stunden an Debugging zu ersparen)
Es hat nicht beim ersten Mal funktioniert, und jede Falle ist es wert, dokumentiert zu werden:
1. Das Passwort muss URL-encodiert sein. Die Quelle ist tapo://PASSWORT@IP mit dem Passwort für Ihr Tapo-Cloud-Konto (kein „Kamera-Konto“ bei diesen Modellen). Wenn Ihr Passwort #, ^, %, @… enthält, müssen Sie es encodieren (# → %23, usw.), sonst kürzt go2rtc die URL stillschweigend ab. Tipp:
bash
python3 -c "import urllib.parse,getpass; print(urllib.parse.quote(getpass.getpass('mdp: '), safe=''))"
2. Der Haupt-4K-Stream = schwarzer Bildschirm. Bekannter Bug (SPS/PPS nicht weitergeleitet, siehe go2rtc #2202): Die Kamera sendet das Video, aber go2rtc kann es nicht parsen. Der Substream funktioniert perfekt:
tapo://ENCODIERTES_PASSWORT@10.6.0.222?channel=0&subtype=1
640×360, das sieht fürs Auge nicht gut aus, aber es ist genau das, was Frigate für die Erkennung braucht (die Modelle arbeiten ohnehin mit 300-640 px). Das 4K bleibt auf der SD-Karte der Kamera für die Wiedergabe.
3. Die schlechten Zeitstempel (DIE Falle). Der tapo-Stream erzeugt nicht monotone DTS → ffmpeg läuft auf 190 % CPU, der Frigate-Watchdog tötet es in einer Schleife, es werden keine Clips aufgezeichnet. Der Fix, der alles repariert hat:
yaml
input_args: -avoid_negative_ts make_zero -fflags +genpts+discardcorrupt -rtsp_transport tcp -use_wallclock_as_timestamps 1
Der Schlüssel ist -use_wallclock_as_timestamps 1: ffmpeg ignoriert die Zeitstempel der Quelle und generiert sie neu.
4. Der Intel-iGPU ändert alles. Mein Server ist ein bescheidener Beelink U59 (Celeron N5105), der bereits HA + 2 Gladys hostet. Als CPU-Detektor war er auf den Knien (86 % System). Nach Aktivierung von OpenVINO auf dem iGPU + VAAPI-Decodierung:
| Metrik | CPU | iGPU (OpenVINO + VAAPI) |
|---|---|---|
| Inferenz | 94,6 ms | 15,8 ms |
| Prozess-Detektor | 191,8 % | 8,5 % |
| System-CPU | 86 % | 22 % |
| Verlorene Frames | 7/s | 0 |
Ein Celeron mit 22 % CPU, der Echtzeit-Objekterkennung neben HA und 2 Gladys durchführt. 
Das Ergebnis
Über MQTT veröffentlicht Frigate alles, wovon man träumt:
frigate/c660/person → 1 / 0 (binär, perfekt für Gladys)
frigate/c660/dog → 1 / 0
frigate/events → reicher JSON (Label, Score, Box, Trajektorie, Zonen...)
frigate/reviews → Benachrichtigungen mit Thumbnail
frigate/stats → vollständige Gesundheitsdaten (fps, Inferenz, Speicher...)
Erkennung in der Praxis validiert (Person mit 0,93 Score, Hund erkannt, wo Tapo „Tier“ sagt), Clips aufgezeichnet, Snapshots, kein Cloud. Eine Kamera, die „offiziell nicht integrierbar“ ist, die lokal besser funktioniert als die „kompatiblen“ Modelle. 
:gear: Vollständige validierte Konfigurationen (docker-compose + Frigate-Konfiguration) — klicken Sie zum Aufklappen
docker-compose.yml:
yaml
services:
frigate:
container_name: frigate
image: ghcr.io/blakeblackshear/frigate:stable
restart: unless-stopped
shm_size: "256mb"
devices:
- /dev/dri/renderD128:/dev/dri/renderD128
volumes:
- ./config:/config
- ./storage:/media/frigate
- type: tmpfs
target: /tmp/cache
tmpfs:
size: 1000000000
ports:
- "8971:8971" # UI (HTTPS ab Version 0.17!)
- "8554:8554" # RTSP-Restream
- "1984:1984" # go2rtc
config/config.yml:
yaml
mqtt:
enabled: true
host: <Ihr_Mosquitto>
user: xxx
password: xxx
detectors:
ov:
type: openvino
device: GPU
model:
width: 300
height: 300
input_tensor: nhwc
input_pixel_format: bgr
path: /openvino-model/ssdlite_mobilenet_v2.xml
labelmap_path: /openvino-model/coco_91cl_bkgr.txt
go2rtc:
streams:
c660:
- tapo://URL_ENCODIERTES_PASSWORT@10.6.0.222?channel=0&subtype=1
cameras:
c660:
ffmpeg:
hwaccel_args: preset-vaapi
inputs:
- path: rtsp://127.0.0.1:8554/c660
input_args: -avoid_negative_ts make_zero -fflags +genpts+discardcorrupt -rtsp_transport tcp -use_wallclock_as_timestamps 1
roles: [detect, record]
detect:
enabled: true
fps: 5
width: 640
height: 360
objects:
track: [person, dog, cat, horse]
record:
enabled: true
retain:
days: 7
mode: motion
snapshots:
enabled: true
retain:
default: 14
Betriebsanmerkungen:
- Frigate 0.17: Die UI ist HTTPS auf Port 8971 (selbstsigniertes Zertifikat), Admin-Konto wird beim ersten Start generiert (Passwort in den Logs).
shm_size: 128 MB reichen nicht aus, nicht einmal für 1 Kamera.- Die Tapo-Kameras begrenzen gleichzeitige Streams → immer über go2rtc konsumieren (der 1 Verbindung bündelt), nie direkt.
- Kleine periodische Warnung
connection reset by peeram Port 8800: Die Kamera trennt gelegentlich, go2rtc verbindet sich automatisch wieder. Nicht blockierend.
Und dannenant : Vorschlag zur Integration von Gladys
Alles funktioniert, aber seien wir ehrlich: zwischen nmap, URL-Encoding, ffmpeg-Input-Args und der OpenVINO-Konfiguration, das ist nicht für den Durchschnittsbürger zugänglich. Und genau das ist die Art von Komplexität, die Gladys verstecken kann. 
Ich plane daher eine Integration „Lokale Videoüberwachung“ (neuer Dienst oder Erweiterung von rtsp-camera, zu diskutieren), deren Prinzip darin besteht, nicht das Rad neu zu erfinden:
- go2rtc = Protokollabstraktionsschicht (es spricht rtsp://, tapo://, onvif://, Ring, Nest, Dahua, USB… und wird von AlexxIT + einer großen Community gepflegt). Eine Integration = alle Kameras.
- Frigate = Objekterkennung + Aufnahmen + MQTT.
- Gladys = Orchestrierung, einfache Konfiguration und Bereitstellung der Funktionen.
Was die Integration tun würde
- Verwaltung der Frigate/go2rtc-Container über die Gladys-Benutzeroberfläche (Installation, Start, Neustart) — nach demselben Muster wie das, was bereits für Zigbee2MQTT existiert.
- Intelligente automatische Konfiguration: Erkennung der Hardware (Intel iGPU vorhanden? → OpenVINO + VAAPI; sonst CPU), Berechnung der
shm_sizeentsprechend der Anzahl der Kameras, stabile Standardeinstellungen — alles überschreibbar im Expertenmodus. - Einfache Kamerahinzufügung: Name, Typ (RTSP / Tapo / ONVIF…), IP, Passwort (automatisch verschlüsselt!), Auswahl der zu erkennenden Objekte (person, dog, cat, horse… Mehrfachauswahl). Die Integration generiert die Frigate-Konfiguration und wendet bekannte Korrekturen an (Tapo-Substream, input_args-Timestamps…) ohne dass der Benutzer wissen muss, dass sie existieren.
- Automatisch erstellte Gladys-Features pro Kamera:
- die klassische Live-Kamera;
- ein Erkennungsbinär pro Objekttyp (
frigate/<cam>/person→ Gladys-Anwesenheits-Sensor → Szenen!); - eine „Bildkamera“ pro Typ: das letzte erfasste Bild jeder Erkennung (wahrscheinlich ein neuer Bild-Feature-Typ, ohne Live-Ansicht — zu diskutieren).
- Gesundheit: Status pro Kamera, Reconnect-Zähler, Frigate-Statistiken.
Offene Fragen für die Community (und @pierre-gilles 
)
- Neuer Dienst oder Erweiterung von
rtsp-camera? Meine Intuition: neuer Dienst (der Umfang ist sehr unterschiedlich), aber das Bestehende sollte der einfache Weg für diejenigen bleiben, die nur einen RTSP-Stream wollen. - Neuer Feature-Typ „Bildkamera nur“ (Anzeige des letzten Bildes, kein Live-Player): Erscheint Ihnen das die richtige Modellierung für „letzte Erkennung vom Typ X“?
- Politik der Begleitcontainer: Frigate bringt seinen eigenen go2rtc mit, daher reicht ein Container. OK, dem Z2M-Muster zu folgen?
- Live-Ansicht: Integration des Web-Components
video-stream.jsvon go2rtc (WebRTC/MSE) mit Fallback-Snapshots für unzuverlässige Streams. Frage des Proxys über den Gladys-Server zu untersuchen (Mixed Content HTTPS/HTTP).
Ich beginne die Entwicklung mit einer Analysephase des Bestehenden, dann einem MVP (Container + generische RTSP-Kamera + MQTT-Erkennungsbinär), dann den erweiterten Quellen (tapo://, onvif://) und dem Live-Betrieb. PRs klein und aufgeteilt, wie üblich.
Alle Rückmeldungen sind willkommen: Anwendungsfälle, Kameras, die Sie gerne unterstützt sehen würden, Meinungen zu den oben genannten Fragen… Und wenn einige den manuellen Setup testen möchten, während sie warten, sind die vollständigen Konfigurationen im obigen Auszug — ich beantworte Fragen! 
Bis bald, Terdious
Das Symptom ist bei mehreren Nutzern dokumentiert: Die ONVIF-Verbindung wird ~10 Sekunden nach der PullMessage-Anfrage getrennt, obwohl die Ereignisse in der Tapo-App erscheinen (und Modelle wie die C110/C210 sie korrekt senden). TP-Link hat Firmware-Updates veröffentlicht, die das Problem beheben sollen (C520WS V1: 1.3.2, V2: 1.1.1), aber die Rückmeldungen bleiben zufällig.
, Gesichtserkennung, Kennzeichenerkennung…
