wichtiges UPDATE für controller 7.2.2 im stable

[vowill]

@Thomas-Mosandl Hallo, auch ich freue mich als langjähriger Nutzer von Bosch-Kameras (2 * Eyes-I und 1 * Innenkamera-I) darauf, dass ein Zugriff über die Schnittstelle möglich wird.
Nach Installation von v1.2.0 heute Abend lief der Adapter los und hat alle 3 Kameras erkannt. Allerdings gibt es keine DPs unter 'cameras.0', und im log erschien die Fehlermeldung
"FCM android registration failed: FCM registerToFCM failed (mode=android): HTTP 401 at https://fcmregistrations.googleapis.com/v1/projects/bosch-smart-cameras/registrations — Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.
2026-06-03 22:29:46.095 - warn: bosch-smart-home-camera.0 (195409) FCM push unavailable (FCM: Android registration failed — check network and Firebase credentials) — falling back to event polling every 30s"
Gibt es hierfür eine Abhilfe?
Danke!

[ThomasM.]

Hi @vowill, danke für die genaue Fehlermeldung, die war Gold wert.

Ich konnte das reproduzieren und die Ursache eindeutig einkreisen. Der Fehler

FCM registerToFCM failed (mode=android): HTTP 401 at
https://fcmregistrations.googleapis.com/.../registrations
— Request is missing required authentication credential.

kommt aus dem letzten Schritt der Push-Registrierung bei Google. Die verwendete FCM-Library hat im Registrierungs-Body immer den Standard-VAPID-Key mitgeschickt, und genau den weist Googles Registrations-Endpoint mit 401 ab. Dadurch wurde kein Push-Token erzeugt und der Adapter ist auf Event-Polling alle 30 s zurückgefallen.

Fix in 1.2.1: der Default-VAPID-Key wird nicht mehr mitgeschickt. Damit registriert sich Push wieder normal, Bewegungs-/Personen-/Audio-Ereignisse kommen sofort statt mit bis zu 30 s Verzögerung. Zusätzlich gibt es jetzt eine Selbstheilung: werden gespeicherte Anmeldedaten von Google abgelehnt, registriert der Adapter beim Start einmal frisch neu, bevor er auf Polling zurückfällt.

Wichtig: die Kameras selbst haben die ganze Zeit funktioniert, der Polling-Fallback hat die Events ja geliefert, nur eben verzögert. Es gingen keine Datenpunkte verloren.

Update auf 1.2.1 kommt gleich über den Adapter (Update-Button im Admin). Magst du nach dem Update kurz bestätigen, dass in den Logs FCM registered und FCM push listener started steht und der Datenpunkt info.fcm_active auf healthy springt? Dann wissen wir, dass es bei dir auch sauber durchläuft.

[ThomasM.]

Kleines Folge-Update: 1.2.2 ist raus, hauptsächlich Log-Aufräumen.

Kameras im Privacy-Modus haben das Log mit Motion config poll failed (HTTP 442) zugespammt – das wird jetzt still behandelt (HTTP 442 zählt wie Privacy, kein Fehler). Das Event-Poll-Intervall ist jetzt wie in Home Assistant (60 s statt 30 s). MJPEG-Snapshot-Soft-Fehler landen nur noch auf debug, und ein leerer Snapshot direkt nach einer Bewegung wird erneut versucht statt zu scheitern. Außerdem keine setTimeout-Warnungen mehr beim Beenden. Am Push selbst ändert sich nichts.

[vowill]

@Thomas-Mosandl Ich habe eben die V1.2.4 installiert (danke für die Updates! Die Installation klappte allerdings nicht über das reguläre Update; im admin hatte ich diese Meldung:

Daher habe ich die V1.2.0 gelöscht und die V1.2.4 aus Github neu installiert, einschl. des Einholens einer neuen URL von Bosch). Die Meldungen "FCM registered: c2hp1pVThBIN..." und "FCM push listener started" stehen im log, wie von dir angekündigt .
Allerdings habe ich nach wie vor keine Datenpunkte im Ordner 'cameras.0'; der Ordner ist angelegt, aber leer. Mein Fehler: Ich habe unter 'cameras' geschaut, nicht unter 'bosch-smart-home-camera.0.cameras'.

Noch eine weitere Frage: Wie kann ich auf die Streams zugreifen? Mein go2rtc meldet beständig "connection refused" ...
In den DPs "bosch-smart-home-camera.0.cameras.xxx.stream_url" gibt es keinen Eintrag.

Danke!

[ThomasM.]

@vowill Danke fürs Dranbleiben. Zwei Dinge, einmal warum das Update so umständlich war und einmal zum leeren stream_url.

Zum Update: dass du den Adapter löschen und neu hinzufügen musstest, lag nicht an einem Fehler, sondern daran wie ioBroker mit GitHub-Installationen umgeht. In deinem Screenshot stand 1.2.0+8896176 und „nicht gewartet". Das +8896176 ist der Git-Commit, den ioBroker anhängt, wenn ein Adapter direkt von GitHub installiert wurde (Octocat/URL) und nicht aus dem offiziellen Repository. Dieser Commit war genau der Stand kurz vor 1.2.1, also package.json auf 1.2.0. Für solche GitHub-Installationen bietet ioBroker bewusst keinen Update-Knopf an, es merkt sich nur „von GitHub installiert" und kann keine neue Version anbieten. Daher die Markierung „nicht gewartet" und kein Update, der einzige Weg zu einer neueren Version ist erneut von GitHub installieren oder eben löschen und neu hinzufügen.

Sauber wird das, sobald der Adapter im offiziellen ioBroker-Repository ist. Die Aufnahme ist beantragt und liegt beim Repo-Team, danach erscheint er im Katalog, die Markierung verschwindet und Updates laufen ganz normal per Klick.

Zum leeren stream_url und go2rtc connection refused: das hängt zusammen und ist ebenfalls kein Defekt, sondern der Default. Der Livestream ist opt-in und standardmäßig aus. Jede offene Session zählt gegen das LOCAL-Session-Limit der Kamera (das teilen sich App, HA, Python und der Adapter), deshalb startet der Adapter den Dauerstream nicht von allein. Solange er aus ist, lauscht der TLS-Proxy nicht, cameras.<id>.stream_url bleibt leer, und alles was den Port anspricht bekommt connection refused. Snapshots und Bewegungsmeldungen laufen trotzdem.

So kommst du an den Stream:

1. cameras.<deine-id>.livestream_enabled auf true setzen (pro Kamera). Damit öffnet sich die Session, der Proxy lauscht und cameras.<id>.stream_url wird gefüllt.
2. Diese URL in go2rtc bzw. iobroker.cameras eintragen.
3. Falls go2rtc auf einem anderen Host läuft als ioBroker: der Proxy bindet standardmäßig auf 127.0.0.1 und ist von außen nicht erreichbar, dann kommt weiter connection refused. In dem Fall in den Adapter-Einstellungen Expose RTSP proxy to LAN aktivieren und die LAN-IP des ioBroker-Hosts als External hostname eintragen, dann steht in der URL deine LAN-IP statt 127.0.0.1.

In 1.2.5 weist der Adapter beim Start jetzt einmal im Log auf genau diesen Punkt hin, solange noch keine Kamera den Livestream an hat, und der Datenpunkt-Name von stream_url sagt jetzt direkt, dass er bis livestream_enabled=true leer bleibt. Im README gibt es dazu einen neuen Abschnitt „stream_url is empty / go2rtc says connection refused".

Sag gern Bescheid, ob das Stream-Bild bei dir damit ankommt.

[vowill]

@Thomas-Mosandl Danke für deinen Support und die zusätzlichen Erläuterungen!
Ja, jetzt kommt der Stream - einfach super. Weißt du, wie hoch das "LOCAL-Session-Limit" ist?
Bei der Innenkamera (Gen. 1) funktioniert auch der Button "bosch-smart-home-camera.0.cameras.xxx.privacy_enabled": Er schaltet die Kamera zuverlässig ein und aus
Lass mich gerne wissen, wenn ich weiter unterstützen/testen kann.

[ThomasM.]

Kein Problem. Am besten einfach alle Bugs oder Feature-Requests melden, am besten über GitHub. Leider habe ich nur HA und keinen IOB, deswegen kann ich euch nur hier supporten. Kenne mich aber nicht so gut damit aus.

Lokale Session Limit gibt es keines. Also du kannst so viel lokal streamen wie du willst.

[Reiner 0]

Hallo Thomas, vielen Dank für die Arbeit an diesem Adapter. Ich habe ihn ausprobiert und konnte meine Kameras im Objektbaum finden. Auch ein Snapshot konnte ich bereits in die VIS-GUI importieren. Jedoch scheitere ich daran, den Stream in iobroker.cameras zu importieren. Könntest Du mir eine Beispiel-Konfiguration zukommen lassen? Wohin soll in der Camera-Instanz die Stream-URL kopiert werden?

[ThomasM.]

Hi Reiner,

iobroker.cameras nimmt die fertige rtsp://-URL leider nicht in einem einzelnen Feld entgegen, sondern setzt sie aus mehreren Einzelfeldern zusammen. Deshalb muss man die stream_url aufteilen. Zwei Dinge sind dabei wichtig: als Typ RTSP (die generische ffmpeg-Variante) wählen und das Transport-Protokoll von UDP auf TCP umstellen, der Proxy spricht nämlich ausschließlich TCP.

So gehst du vor:

1. Stream zuerst aktivieren: cameras.<id>.livestream_enabled auf true setzen. Dann startet der Proxy und cameras.<id>.stream_url füllt sich, z. B.:

rtsp://127.0.0.1:8554/rtsp_tunnel?inst=1&enableaudio=1&fmtp=1&maxSessionDuration=3600

(Der Port ist bei dir ein anderer, bleibt aber über Neustarts stabil.)

2. In der cameras.0-Instanz eine Kamera anlegen, Typ RTSP, und die Felder aus genau dieser URL übernehmen:

Feld in cameras	Wert
Camera IP	127.0.0.1 (gleicher Wert, wenn cameras und der Bosch-Adapter auf demselben ioBroker laufen)
Port	8554 (der Port aus deiner stream_url)
Protocol	TCP (wichtig, das Feld steht standardmäßig auf UDP)
Path	/rtsp_tunnel?inst=1&enableaudio=1&fmtp=1&maxSessionDuration=3600 (alles hinter dem Port, inkl. ?-Teil, 1:1 kopieren)
Username / Password	leer lassen (der Proxy macht die Bosch-Anmeldung transparent)

Damit du die stream_url nicht selbst zerlegen musst, legt der Adapter seit Version 1.2.7 die drei Teile fertig als eigene Datenpunkte an:

cameras.<id>.stream_host  ->  Camera IP
cameras.<id>.stream_port  ->  Port
cameras.<id>.stream_path  ->  Path

(Das Protocol musst du weiterhin selbst auf TCP stellen.)

3. Speichern. iobroker.cameras liefert dann das Snapshot-Bild unter http://<iobroker-host>:8082/cameras.0/<kameraname> und bietet über sein eigenes Vis-Widget die Live-MJPEG-Kachel an.

Wenn cameras auf einem anderen Rechner als der Bosch-Adapter läuft, statt 127.0.0.1 die LAN-IP des ioBroker-Hosts eintragen und im Bosch-Adapter die Option "Expose RTSP proxy to LAN" aktivieren.

Noch eine Anmerkung zur Erwartung: iobroker.cameras gibt dir Snapshots bzw. eine MJPEG-Kachel, keinen echten H.264-Livestream mit Ton. Für flüssiges Live mit Audio ist go2rtc der richtige Weg; go2rtc nimmt die stream_url direkt entgegen. Das mitgelieferte VIS-2-Widget des Bosch-Adapters zeigt aktuell ebenfalls nur Snapshots.

Viele Grüße
Thomas

[ThomasM.]

Update: Version 1.3.0 ist auf npm.

Das Highlight ist ein neues VIS-2-Widget ("Bosch Camera", React), das man direkt auf eine VIS-2-Ansicht ziehen kann — ohne JSON-Import.

Drei Anzeige-Modi je Karte:

• Snapshot (Near-Live-Bild, pollt den Snapshot-HTTP-Server)
• Live (MJPEG) — der Play-Button startet den Livestream und zeigt das Video direkt in der Karte (FFmpeg liest den lokalen RTSP-Proxy, Frames per Canvas)
• go2rtc/WebRTC — niedrige Latenz inkl. Ton, wenn ihr go2rtc auf die stream_url zeigt

Bedienleiste im iOS/Android-Stil mit Buttons für Privacy, Livestream, Licht, Snapshot, Schwenken (nur 360°-Innenkamera), Privacy-Ton und Sirene. Im Privatsphäre-Modus sind die Aktionen deaktiviert — nur der Privacy-Schalter und Vollbild bleiben aktiv. Vollbild legt sich über die ganze Seite, Offline-Kameras bekommen eine klare "Offline"-Kachel.

Außerdem ein Stabilitäts-Fix: der RTSP-Proxy wird nicht mehr ~60 s nach dem Start abgebaut, wenn man den Livestream während eines Snapshots einschaltet. VLC/Recorder/das Widget bekommen also kein "connection refused" mehr.

Einbauen: VIS-2-Editor öffnen, Widget "Bosch Camera" auf die Ansicht ziehen, als "Camera datapoint" einen Datenpunkt unter bosch-smart-home-camera.0.cameras.<UUID> wählen (z. B. .name) und den Modus auswählen. Für Live (MJPEG) muss FFmpeg auf dem ioBroker-Host vorhanden sein.

Viel Spaß damit — Rückmeldungen gerne hier.

[ThomasM.]

Update: Version 1.4.0 ist auf npm.

Zwei größere Sachen und zwei Fixes:

Neues Widget "Bosch Camera Overview" — ein Mehrkamera-Raster. Es findet alle
Kameras einer Adapter-Instanz automatisch, sortiert sie (online zuerst, dann
Privatsphäre, dann offline) und zeigt je Kachel einen Snapshot plus Schnell-Toggles
für Privacy und Licht. Ein Klick auf eine Kachel öffnet die Kamera als volle
"Bosch Camera"-Karte im Vollbild. Keine Einzelkonfiguration je Kamera nötig.

Die Einzelkamera-Karte ist jetzt auf dem Stand der Home-Assistant-Karte.
Statt des bisherigen WebRTC-iframes läuft jetzt ein echtes Video-Element über
go2rtc (RTCPeerConnection mit HLS-Fallback). Damit gibt es Ton-Umschalter,
Lautstärkeregler, einen Pause-Guard und digitalen Zoom. Der komplette
Funktionsumfang sitzt jetzt in einem aufklappbaren Bottom-Sheet (Zahnrad) statt
einer festen Liste, dazu modellabhängiges Schwenken, Bewegungszonen- und
Privacy-Masken-Overlays und Status-Badges.

Fix: Kameras im Privatsphäre-Modus werden jetzt korrekt als "online" angezeigt.
Eine erreichbare Kamera in Privacy galt vorher fälschlich als offline; der Status
wird jetzt über die Cloud abgeglichen.

Fix: Beim Verlassen des Privatsphäre-Modus blitzte kurz das kaputte
"Bild-nicht-verfügbar"-Symbol auf, bevor das erste Bild geladen war. Jetzt liegt
solange eine Lade-Anzeige über der Kachel, und das Bild wird sofort neu geholt.

Fix: Innenkameras aktualisieren ihr Standbild jetzt automatisch, solange die
Kachel sichtbar ist (die 360°-Innenkamera alle 5 s, die Innenkamera der zweiten
Generation alle 10 s). Vorher fror das Bild zwischen zwei Bewegungen ein, obwohl
die Kamera schwenkt oder sich im Bild etwas bewegt. Außenkameras bleiben
unverändert.

Rückmeldungen gerne hier.

[Reiner 0]

@ThomasM.

Hallo Thomas, vielen Dank für die detaillierte Beschreibung. Ich konnte in VIS den Livestream darstellen. Ich musste jedoch die maxSessionDuration auf 5000 erhöhen, weil ich sonst einen Timeout erhalten habe.

Ein neues Problem ist nun jedoch aufgetreten. Nach einiger Zeit stoppt der bosch-smart-home-kameras-Adapter das Update der Snapshotbilder und vermutliche auch den Livestream. Die Werte z.B. z.B. "last_event_image_at" oder "last_motion_at" ändert sich nicht mehr, obwohl in der Bosch-App Bewegungen an der Kamera erkannt wurden. Eine Fehlermeldung habe ich nicht gefunden.

Als ich "nur" den iobroker-camera-Adapter neu startete, habe ich folgende Warnung vom bosch-smart-home-kameras-Adapter erhalten:

RTSP auth 87CC5265: camera rejected our Digest creds (status 401) — forwarding 401 + closing client so it reconnects with refreshed creds
(Ob diese Meldung etwas mit dem Fehlverhalten zu tun hat, kann ich nicht sagen)

Wenn ich den bosch-smart-home-kameras-Adapter neu starte, funktioniert es für einige Zeit wieder, aber dann stoppt das Updaten wieder.

Ich benutze die Version 1.2.5+main auf einem Raspberrypi.

An was könnte dieses Verhalten liegen?

VG

Reiner

[ThomasM.]

@Reiner-0 Danke für die genaue Beschreibung, das war sehr hilfreich. Es waren drei Dinge, alle in Version 1.5.0 (gerade auf npm) adressiert:

1. Der Hauptpunkt — dass nach einiger Zeit last_motion_at / last_event_image_at einfrieren, obwohl die Bosch-App noch Bewegung sieht: Das lag an der FCM-Push-Verbindung. Die verwendete FCM-Bibliothek meldet einen stillen Abriss der TCP-Verbindung nicht nach oben — die Verbindung gilt intern weiter als "gesund", obwohl keine Push-Nachrichten mehr ankommen. Das Event-Polling lief bisher nur als Fallback, wenn FCM schon beim Start fehlschlug — bei einem stillen Tod danach sprang es nicht an. Genau dein Symptom.
   Der Fix orientiert sich an Home Assistant: Es läuft jetzt immer ein Sicherheitsnetz-Polling. Solange FCM Push liefert, fragt es nur etwa alle 5 Minuten nach (schont die Bosch-Anfragen); sobald keine Pushes mehr kommen, holt es die Events im Poll-Intervall. Bewegung friert damit nie länger als das Sicherheitsfenster ein, egal was FCM macht — ohne Neustart.

2. maxSessionDuration: Du musstest sie auf 5000 erhöhen. Das geht jetzt direkt in den Einstellungen (Tab "RTSP / Stream" → "Max session duration"). Default 0 = der von der Kamera gemeldete Wert (3600 s); trag dort z. B. 5000 ein, dann musst du die URL nicht mehr von Hand anpassen. Hintergrund: Bei einem dauerhaften go2rtc-Abruf kann die Session an der 3600-s-Grenze auslaufen, bevor die intern erneuerte Session übernimmt — ein höherer Wert überbrückt das.

3. Die Warnung "camera rejected our Digest creds (status 401)": Das ist erwartetes Verhalten und nicht die Ursache. Bosch rotiert die Stream-Zugangsdaten serverseitig (z. B. bei der Session-Erneuerung); der Proxy reicht die 401 durch, der Client verbindet sich mit frischen Daten neu. Damit es nicht wie ein Fehler aussieht, steht die Meldung jetzt auf Debug statt Warn.

Du bist auf 1.2.5 — bitte auf 1.5.0 aktualisieren, dann sollten Punkt 1 und 2 erledigt sein. Falls dir danach wieder etwas einfriert, sag Bescheid, dann schauen wir mit den Logs (Debug) weiter.

[Jaschkopf]

Hallo Thomas. Gibt es schon Pläne den Adapter ins beta Repo aufzunehmen?

LG

[ThomasM.]

@Jaschkopf Ja, der Antrag läuft schon seit Mitte Mai: https://github.com/ioBroker/ioBroker.repositories/pull/5983

Alle automatischen Checks (Adapter-Checker, Object-Structure-Check) sind inzwischen grün, es steht nur noch das manuelle Review durch das Repo-Team aus. Dafür ist aktuell Mitte Juli als Wiedervorlage eingetragen. Sobald der Adapter im Beta-Repo (latest) auftaucht, schreibe ich es hier in den Thread. Bis dahin klappt die Installation wie gehabt über die GitHub-URL im Admin oder npm.

[Jaschkopf]

Perfekt, das sind super Nachrichten. Danke für deine Arbeit!

[Reiner 0]

Hallo Thomas, nun habe ich Probleme mit das Update v1.5.2 zum Laufen zu bekommen.
Folgende Fehlermeldung erhalte ich nach dem Anmelden:

bosch-smart-home-camera.0
2026-06-12 18:13:30.189 error No persisted camera state found — cannot start in cloud-degraded mode. Adapter will wait for cloud to recover.

bosch-smart-home-camera.0
2026-06-12 18:13:29.610 warn Camera discovery failed on startup (Cameras API network error: unable to get issuer certificate) — attempting cloud-degraded startup from persisted state

bosch-smart-home-camera.0
2026-06-12 18:13:29.280 info Valid tokens found in state storage — skipping login

bosch-smart-home-camera.0
2026-06-12 18:13:28.819 info Bosch Smart Home Camera adapter starting…

bosch-smart-home-camera.0
2026-06-12 18:13:28.755 info starting. Version 1.5.2 (non-npm: mosandlt/ioBroker.bosch-smart-home-camera#main) in /opt/iobroker/node_modules/iobroker.bosch-smart-home-camera, node: v22.22.3, js-controller: 7.1.2

bosch-smart-home-camera.0
2026-06-12 18:13:18.467 error Cannot find view "system" for search "folder" : Connection is closed.

bosch-smart-home-camera.0
2026-06-12 18:13:18.392 warn get state error: Connection is closed.

bosch-smart-home-camera.0
2026-06-12 18:13:18.389 warn Could not perform strict object check of state bosch-smart-home-camera.0.info.connection: DB closed

bosch-smart-home-camera.0
2026-06-12 18:13:18.347 warn Camera discovery failed on startup (Cameras API network error: unable to get issuer certificate) — attempting cloud-degraded startup from persisted state

[ThomasM.]

@Reiner-0 Erstmal Entschuldigung — der Fehler liegt klar bei mir, nicht bei deinem System.

Was passiert ist: In v1.5.1 habe ich eine sicherheitskritische Lücke geschlossen (CWE-295 / GHSA-6qh5-x5m5-vj6v). Vorher hat der Adapter bei den Bosch-Cloud-Verbindungen das TLS-Zertifikat überhaupt nicht geprüft — im selben Netz war damit ein Abgreifen der OAuth-Tokens möglich. Das musste raus, und zwar zügig.

Der Fix pinnt die private Bosch-CA. In der Python- und der Home-Assistant-Variante funktioniert das sauber, weil OpenSSL dort ein PARTIAL_CHAIN-Flag kennt, mit dem man die Kette an einem Zwischenzertifikat verankern kann. Node.js hat dieses Flag nicht (ist seit Jahren ein offener Feature-Request, nodejs/node#36453). Dadurch konnte Node die Zertifikatskette nicht abschliessen und jeder Cloud-Handshake scheiterte mit genau deiner Meldung:

Camera discovery failed on startup (Cameras API network error: unable to get issuer certificate)
No persisted camera state found — cannot start in cloud-degraded mode.

Solange ein gültiger gespeicherter Stand vorhanden war, ist es nicht aufgefallen — bei einem frischen Start ohne den fiel die Kamera-Erkennung dann komplett aus. Mein Fehler war, den Node-Pfad nicht gegen die echte Cloud gegengetestet zu haben.

In v1.5.3 prüfe ich das Zertifikat jetzt selbst nach: Hostname, Gültigkeit, und ob das Zertifikat entweder von der gepinnten Bosch-CA signiert ist oder zu einem vertrauenswürdigen System-Root führt (das braucht der Let's-Encrypt-Login-Host). Der MITM-Schutz aus v1.5.1 bleibt damit vollständig erhalten — selbstsignierte, abgelaufene, falsche oder nicht vertrauenswürdige Zertifikate werden weiterhin abgewiesen. Habe es gegen die echte Bosch-Cloud verifiziert (Discovery findet die Kameras wieder) und Regressionstests ergänzt.

Update zieht über GitHub (mosandlt/ioBroker.bosch-smart-home-camera#main) bzw. npm sobald die Version durch ist. Sag bitte kurz Bescheid, ob es bei dir wieder durchläuft.

[Reiner 0]

Hallo Thomas, nun läuft der bosch-smart-home-camera-Adapter wieder. Danke für den schnellen Fix.
Jedoch klappt nun die Verbindung zum iobroker.cameras-Instanz nicht mehr. Ich erhalte folgenden Fehlermeldung:

error Cannot get image: [tcp @ 0x557ca7db00] Connection to tcp://127.0.0.1:42307?timeout=0 failed: Connection refusedrtsp://127.0.0.1:42307/rtsp_tunnel?inst=2&enableaudio=1&fmtp=1&maxSessionDuration=5000: Connection refused

[ThomasM.]

Hallo Reiner,

das "Connection refused" ist kein Zertifikats- oder SSL-Problem (sonst käme ein TLS-Fehler, nicht ein abgewiesener TCP-Connect). Ursache ist, wie der lokale RTSP-Proxy bisher gearbeitet hat: Er hat seinen Port nur geöffnet, solange ein Livestream lief. iobroker.cameras holt sich das Bild aber in eigenen Intervallen. Fällt so ein Abruf in einen Moment, in dem der Stream gerade aus ist, ist der Port zu und ffmpeg meldet Connection refused. Nach jedem Adapter-Neustart, Privacy-Wechsel oder Ablauf einer Sitzung war der Port zudem wieder zu bzw. die Portnummer hatte sich geändert, weshalb die fest eingetragene 42307 irgendwann nicht mehr gepasst hat.

In v1.5.4 gibt es dafür eine saubere Lösung: eine neue Option "RTSP-Endpunkt dauerhaft erreichbar halten" unter Einstellungen → API-Anfragen / Energiesparen. Wenn aktiv, hält der Adapter den Port pro Kamera dauerhaft offen, auch wenn kein Livestream läuft. Die eigentliche Kamera-Sitzung wird erst dann aufgebaut, wenn iobroker.cameras sich verbindet, und nach einer kurzen Leerlaufzeit (Standard 60 s) ohne Verbindung wieder freigegeben. So ist der Endpunkt jederzeit erreichbar, ohne dauerhaft eine der 3 gleichzeitigen Sitzungen zu belegen.

Einrichtung:

1. Adapter auf v1.5.4 aktualisieren.
2. In den Adapter-Einstellungen "RTSP-Endpunkt dauerhaft erreichbar halten" einschalten und speichern.
3. cameras.<id>.stream_host / stream_port / stream_path in iobroker.cameras eintragen (Protokoll auf TCP stellen). Die drei Werte sind ab Adapter-Start gesetzt und bleiben über Neustarts stabil. livestream_enabled musst du dafür nicht mehr anfassen.

Falls du nicht updaten möchtest, ist der schnelle Workaround weiterhin: cameras.<id>.livestream_enabled = true setzen und dann den aktuell angezeigten stream_port (der ist nicht mehr 42307) in iobroker.cameras übernehmen. Das hält aber nur, solange der Stream läuft.

Gruß