Neues YouTube-Video: Visualisierung im Devices-Adapter

[ThomasM.]

@jaschkopf Ja, da bin ich dran, da muss noch ein Endpoint geändert werden. Ich bin da schon dran. Das dauert leider, da es nicht in meiner Hand ist. Deshalb dieser "manuelle" Weg erstmal.

[Jaschkopf]

Hallo Thomas, glaube ich hab heute einen neuen Bug gefunden. Kameras liefen ganz normal, habe dann über die App den privacy mode aktiviert, weil ich im Garten gearbeitet habe und nonstop Bewegungen getriggert hab. Habe den privacy mode dann später auch über die App wieder deaktiviert, aber BlueIris und auch VLC kann über die Stream und Substream-URL keine Verbindung aufbauen, bzw. meldet "Check Port/User/Password" bzw in VLC wird nach User und PW gefragt. Habe den Adapter dann gerade neu gestartet, danach waren die Streams wieder online. Log packe ich dir in den Anhang. Bringt es für die Zukunft einen Vorteil für dich wenn ich den Adapter auf Debug-Level stelle? Bosch Error Log 2026_05_23.txt

[ThomasM.]

Hallo Jaschkopf,

danke für den präzisen Bericht — der Bug war reproduzierbar und der Fix ist gerade in v0.7.12 raus (Tag gepusht, CI publiziert in den nächsten paar Minuten auf npm).

Root cause: jeder Privacy-Edge auf der Kamera (ON→OFF oder OFF→ON) rotiert Bosch-seitig die Digest-Credentials der RTSP-Stream-URL. Unser _liveSessions-Cache hielt aber innerhalb des 60s-TTL-Fensters die Vor-Toggle-Credentials fest. Der cameras.<id>.stream_url-DP publishte damit weiter die alten Zugangsdaten — BlueIris/VLC bekommen 401, der Adapter selbst ist unauffällig. Restart leerte den Cache, deswegen war das der "Workaround".

Fix: _pollSingleCameraState() erkennt jetzt jede Privacy-Transition über das Cloud-Polling und macht zwei Dinge:

1. Löscht die gecachte LiveSession aus _liveSessions
2. Setzt cameras.<id>.stream_url + cameras.<id>.stream_url_sub auf ""

Damit holt der nächste ensureLiveSession()-Call (Stream-Toggle, Snapshot, RCP-Write, Watchdog-Tick) frische Credentials per PUT /connection und re-publisht die URLs. Externe Clients sehen sofort einen leeren stream_url-DP statt stale-401 zu spammen.

Beide Edges sind abgedeckt, weil Bosch in beiden Richtungen rotiert.

Regression-Tests: 4 Pin-Tests in test/unit/main_privacy_toggle_invalidates_session.spec.ts für ON→OFF / OFF→ON / unverändert / kein Cached-Session. Full Suite jetzt 600 passing.

Update läuft automatisch über die ioBroker-Repos sobald CI durch ist (~5 Min nach diesem Post). Bei Update auf 0.7.12 dann kurz testen ob BlueIris/VLC nach einem Privacy-Cycle stabil bleibt — falls nicht, einen Debug-Log nachschießen, dann schaue ich nochmal.

Wer's auf GitHub trackt: würde mich freuen wenn du den Bug-Report dort als Issue dokumentierst (github.com/mosandlt/ioBroker.bosch-smart-home-camera/issues/new) — Forum-Posts gehen mir bei der nächsten Major-Release-Recherche schneller verloren als getrackte Issues.

— Thomas

[Jaschkopf]

Hab es jetzt zwei Mal getestet, beim ersten mal kam der Stream von beiden Cams nicht wieder, hab dann auf Debug Level geswitched und nochmal probiert, jetzt kam eine von beiden Cams wieder live. Im Anhang das Log vom 2. Test. 21:54 privacy on, 21:55 privacy off. Log.txt

[ThomasM.]

Hi Jaschkopf,

dein Log aus Post #42 hat die Wurzel des Problems sehr deutlich gezeigt. v0.7.13 ist gerade auf npm und sollte den Bug vollständig schließen.

Was wirklich los war

v0.7.12 hat zwar die _liveSessions-Cache geleert und die stream_url-DPs auf "" gesetzt, aber der TLS-Proxy selbst hatte seine Digest-Credentials schon beim Proxy-Start in einer Closure gefangen. Auf dem Re-Use-Pfad (gleiche Remote-Adresse, Sticky-Port) wurde der Proxy weiterbenutzt ohne dass seine internen Creds aktualisiert wurden. In deinem Log steht das exakt drin:

21:55:07.945  TLS proxy E8376BA3: reusing port 33201 (remote unchanged 192.168.178.135:443)
21:55:18.286  RTSP auth E8376BA3: auth dance done (status 401), entering INJECTING mode
21:55:41.767  RTSP auth E8376BA3: auth dance done (status 401), entering INJECTING mode
21:56:11.815  RTSP auth E8376BA3: auth dance done (status 401), entering INJECTING mode

Das reusing port oben war der Schlüssel — danach hat der Proxy bei jedem Auth-Dance die alten Pre-Toggle-Creds eingesetzt und 401 kassiert. Die andere Cam (970E981A) hatte schlicht Glück, dass ihr erster Client-Connect noch in der ersten Session-Phase landete, bevor der Re-Use-Pfad griff.

Was v0.7.13 ändert

1. digestAuth lebt im Proxy jetzt in einem mutable Holder. Neue Methode updateDigestAuth(user, password) rotiert die Creds zur Laufzeit ohne Listener-Restart; Sticky-Port und bereits publizierte stream_url bleiben unangetastet.
2. upsertSession() ruft die Methode bei jedem Session-Refresh auf, auch auf dem Re-Use-Pfad.
3. Bei ON->OFF und aktivem livestream_enabled triggert der Adapter sofort eine frische ensureLiveSession(), damit die rotierten Creds beim Proxy ankommen bevor dein BlueIris reconnectet.
4. Zusätzlich als Defense-in-depth: falls trotzdem 401 in der Auth-Dance zurück kommt, leitet der Proxy das jetzt ehrlich an den Client weiter und schließt die Verbindung, statt blind in INJECTING-Mode mit kaputten Creds zu gehen.

Test bitte

Update auf v0.7.13, Privacy ein/aus über die Bosch-App und dann auf beiden Cams BlueIris/VLC reconnecten. Bei aktiviertem Debug-Log siehst du beim Toggle jetzt zwei neue Log-Lines pro Cam:

Privacy toggled externally for ... - dropped cached LiveSession ...
TLS proxy ...: refreshed Digest creds (user=cbs-...) - next client connection will use rotated creds

Interessant wäre insbesondere ob die zweite Kamera jetzt auch ohne Verzögerung wieder verfügbar ist. Falls trotzdem noch was hängt, melde dich.

Für künftige Bug-Reports gerne direkt auch über GitHub Issues, dann ist die Diskussion an der Codebasis verankert: https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/issues

[Jaschkopf]

Danke, Fehler scheint mit 0.7.13 behoben zu sein. Gerate getestet, Stream kommt zuverlässig wieder online und BlueIris connectet automatisch wieder. Zukünftige Bugs werde ich über Github reporten ;)

[ThomasM.]

Kurzes Follow-up zu meinem Reply oben: v0.7.14 ist gerade auf npm. Nichts direkt zum Privacy-Toggle, der v0.7.13-Fix bleibt unverändert. Nach dem Release habe ich nochmal einen breiteren Audit-Lauf gegen meine Innenkamera (Gen2 Indoor II, FW 9.40.102) gemacht und dabei acht latente Bugs in der Data-Plane gefunden, die teils seit v0.7.7 drin waren.

Was sich beim Update ändert:

1. wifi_signal_pct zeigt jetzt den echten Prozentwert. Die Bosch-API liefert signalStrength als Prozent 0-100, nicht dBm wie v0.7.7 angenommen hatte; das Lookup nach signalStrengthPercentage hatte ins Leere gegriffen. Verifiziert live mit Innenbereich=100 und Terrasse=86.
2. Der fehlerhaft als "dBm" gelabelte wifi_signal_strength DP wird beim ersten Start per Migration entfernt.
3. trouble_disconnect und andere Connectivity-Status-Events werden nicht mehr als Motion klassifiziert. Sie triggern kein motion_active und keinen Auto-Snapshot mehr.
4. Stale-Event-Filter: Events älter als 15 Minuten aktualisieren last_motion_at weiterhin als historischen Wert, feuern aber keine Seiteneffekte mehr. Bisher wurde nach jedem Adapter-Restart der jeweils jüngste gecachte Cloud-Event neu verarbeitet, bei mir hat das alle 27 Tage alten trouble_disconnect-Events der offline Gen1-Cams bei jedem Restart wieder als Motion durchgeschickt.
5. lan_reachable wird jetzt bei jedem State-Poll aktualisiert, nicht nur bei Cloud-Ausfällen. Vorher blieb der DP bei der Default-false hängen, obwohl die Kamera erreichbar war.
6. online schaltet auch dann auf true, wenn die Kamera im Privacy-Modus ist und der LAN-Ping durchgeht. Vorher zeigte online=false, weil der Snapshot-basierte Reachability-Check im Privacy-Modus einen leeren Body zurückbekommt.
7. intrusion_sensitivity und intrusion_distance werden jetzt aus der Cloud gespiegelt statt nur Default-Werte zu zeigen. Wer die Werte in der Bosch-App geändert hat, sieht ab v0.7.14 die echten Werte im Adapter.
8. Intrusion-Writes funktionieren wieder. Die alte Logik schickte nur das geänderte Feld, Bosch lehnt das mit HTTP 400 ab. v0.7.14 holt zuerst die volle Config, merged die Änderung lokal und PUTet den vollständigen Body.

Zusätzlich: HTTP 443 vom Bosch-Cloud-Endpoint meldet jetzt klar, dass die Kamera im Privacy-Modus ist (statt einer generischen axios-Fehlermeldung). Das ist der gleiche Status, den HA als privacy_blocked interpretiert.

Test-Suite jetzt bei 610 grün. Update läuft automatisch ein, die wifi_signal_strength-Migration ist einmalig per Adapter-Start.

[ThomasM.]

Bosch Smart Home Camera Adapter — Feedback und Feature-Wünsche

Kurzes Update und eine Bitte um Rückmeldung an alle, die den Adapter iobroker.bosch-smart-home-camera einsetzen.

Gerade ist Version 1.0.4 erschienen. Das ist ein reines Hardening-Release ohne funktionale Änderungen: Alle Poll- und Watchdog-Timer laufen jetzt über den Adapter-Core und werden beim Entladen zuverlässig abgebrochen (keine verwaisten Intervalle mehr), die HTTP-Timeouts nutzen AbortSignal.timeout, und es gibt eine neue CI-Security-Schicht (CodeQL, gitleaks Secret-Scan, Dependency-Review). Unter der Haube läuft der Adapter dadurch sauberer, an der Bedienung ändert sich nichts.

Mich würde interessieren, wie der Adapter bei euch im Alltag läuft:

• Gibt es Fehler oder Verhalten, das ihr nicht erwartet hättet? Besonders rund um Live-Stream-Sessions, die FCM-Push-Events und die Schreib-Pfade (Privacy, Licht, Audio, Pan, Intrusion).
• Welche Funktionen fehlen euch noch? Wenn ihr etwas Konkretes braucht, schreibt es gerne hier rein.
• Welche Kamera-Modelle nutzt ihr, und mit welcher Firmware?

Konkrete Bugs lassen sich am besten auf GitHub nachverfolgen, da bleibt nichts liegen:
https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/issues

Logs bei einem Problem bitte mit aktiviertem Debug-Level und, wenn möglich, der Adapter-Version dazu. Danke für jedes Feedback.

[ThomasM.]

v1.1.0 ist auf npm — ein Feature- und Stabilitäts-Release. Es schließt den größten Teil der Lücke zur Home-Assistant-Integration bei den Steuerungen und behebt ein paar Stream-/Push-Eigenheiten, die den Adapter über die Zeit unbemerkt verschlechtern konnten.

VIS / Snapshots
Es gibt jetzt einen lokalen HTTP-Snapshot-Server: einfach in den Instanz-Einstellungen snapshot_http_port setzen (z. B. 8095), dann liefert der Adapter das aktuelle JPEG je Kamera unter http://<iobroker-host>:<port>/<camId>.jpg. Der Datenpunkt snapshot_url hat die Rolle url.cam, damit erkennt der Type-Detector die Kamera und VIS-Image-/Kamera-Widgets binden direkt — ohne Token, ohne File-Store-Gefummel. Zusätzlich gibt es sendTo("bosch-smart-home-camera.0", "snapshot", {camId}), das ein frisches JPEG als Buffer/Base64 zurückgibt, z. B. für Telegram oder Signal.

Neue Steuerungen (HA-Parität)
Push-Benachrichtigungen global an/aus plus sechs Typ-Schalter (Bewegung, Person, Audio, Störung, Kamera-Alarm, Störung-E-Mail). Bewegungserkennung an/aus, Empfindlichkeit und Erkennungsmodus (Gen2: alle Bewegungen / nur Personen / Zonen). Tonaufnahme. Alarmsystem für Indoor II (scharf/Modus/Vor-Alarm + Status-Sensor). Status-LED, Zeitstempel-Overlay, Power-LED-Helligkeit; für Outdoor II Bewegungslicht und Ambiente-Licht. Gegensprechen (Gen2) und ein commissioned-Sensor. Alle neuen Admin-Texte sind in 11 Sprachen übersetzt.

Stabilität
Push überlebt jetzt den stündlichen Token-Refresh (vorher konnte er danach dauerhaft ausfallen). Die Stream-Session-Erneuerung wurde gehärtet: ein während der Erneuerung beendeter Stream wird nicht mehr wiederbelebt, kurzlebige Sessions werden nicht zu früh abgebaut, und ein externer Privacy-Wechsel räumt den Watchdog auf, sodass keine Bosch-Session serverseitig hängen bleibt. Bei einem CBS-Registrierungsfehler fällt der Adapter auf Event-Polling zurück, statt ohne Event-Quelle dazustehen.

Update läuft normal über den Adapter-Reiter. Es gibt keine Breaking Changes — neue Datenpunkte erscheinen automatisch, modellabhängige (Gen2 / Indoor / Outdoor) nur auf passenden Kameras, und der HTTP-Snapshot-Server bleibt aus, bis snapshot_http_port gesetzt ist.

Details und vollständige Liste: https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/releases/tag/v1.1.0
Fragen/Ideen gern hier oder unter https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/discussions/26 — Fehler bitte als GitHub-Issue.

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