Neues YouTube-Video: Visualisierung im Devices-Adapter

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