Neues YouTube-Video: Visualisierung im Devices-Adapter

[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ß

[Reiner 0]

Hallo Thomas, mit der Version 1.5.4 läuft aktuell mein Kamerastream in VIS. Vielen Dank für den schnellen und guten Support. VG Reiner

[ThomasM.]

Kleine Korrektur zu meinem Beitrag oben: in der aktuellen Version 1.5.5 ist die Option in den Tab "RTSP / Stream" umgezogen (in 1.5.4 lag sie noch unter "API-Anfragen / Energiesparen"). Der Name der Option bleibt gleich: "RTSP-Endpunkt dauerhaft erreichbar halten".