Neues YouTube-Video: Visualisierung im Devices-Adapter

[Jaschkopf]

SO Adapter ist installiert. Beide Kameras werden erkannt. FW beider Cams ist 7.91.56. Allerdings werden beide als online=false angezeigt. Hier das Log nach dem Adapterrestart mit Callback-URL:

bosch-smart-home-camera.0
2026-05-13 18:22:57.867	info	Bosch Smart Home Camera adapter ready — 2 camera(s) active

bosch-smart-home-camera.0
2026-05-13 18:22:57.865	error	FCM start failed: FCM: both iOS and Android registration failed — check network and Firebase credentials

bosch-smart-home-camera.0
2026-05-13 18:22:51.168	info	Found 2 camera(s)

bosch-smart-home-camera.0
2026-05-13 18:22:50.963	info	Valid tokens found in state storage — skipping login

bosch-smart-home-camera.0
2026-05-13 18:22:50.909	info	Bosch Smart Home Camera adapter starting…

bosch-smart-home-camera.0
2026-05-13 18:22:50.903	info	starting. Version 0.3.2 (non-npm: mosandlt/ioBroker.bosch-smart-home-camera#main) in /opt/iobroker/node_modules/iobroker.bosch-smart-home-camera, node: v22.18.0, js-controller: 7.0.7

bosch-smart-home-camera.0
2026-05-13 18:22:46.545	info	terminating

bosch-smart-home-camera.0
2026-05-13 18:22:46.394	warn	setTimeout called, but adapter is shutting down

bosch-smart-home-camera.0
2026-05-13 18:22:46.284	info	Found 2 camera(s)

bosch-smart-home-camera.0
2026-05-13 18:22:46.166	info	Login successful — tokens stored. Adapter is now connected.

bosch-smart-home-camera.0
2026-05-13 18:22:46.044	info	Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason

bosch-smart-home-camera.0
2026-05-13 18:22:46.044	info	terminating

bosch-smart-home-camera.0
2026-05-13 18:22:46.043	info	Bosch Smart Home Camera adapter stopped

bosch-smart-home-camera.0
2026-05-13 18:22:46.043	info	Got terminate signal TERMINATE_YOURSELF

bosch-smart-home-camera.0
2026-05-13 18:22:45.785	info	Bosch Smart Home Camera adapter starting…

bosch-smart-home-camera.0
2026-05-13 18:22:45.778	info	starting. Version 0.3.2 (non-npm: mosandlt/ioBroker.bosch-smart-home-camera#main) in /opt/iobroker/node_modules/iobroker.bosch-smart-home-camera, node: v22.18.0, js-controller: 7.0.7

bosch-smart-home-camera.0
2026-05-13 18:22:41.505	info	terminating

bosch-smart-home-camera.0
2026-05-13 18:22:41.004	info	Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason

bosch-smart-home-camera.0
2026-05-13 18:22:41.003	info	terminating

bosch-smart-home-camera.0
2026-05-13 18:22:41.003	info	Bosch Smart Home Camera adapter stopped

bosch-smart-home-camera.0
2026-05-13 18:22:41.003	info	Got terminate signal TERMINATE_YOURSELF

FCM start failed: FCM: both iOS and Android registration failed — check network and Firebase credentials

Der Datenpunkt fcm_active steht auf error. Im Anhang screenshots von allen Datenpunkten. Brauchst du sonst noch was?

Bilder:

Spoiler

[ThomasM.]

Hi @Jaschkopf,

danke fürs Testen — dein Log hat tatsächlich zwei verschiedene Probleme aufgedeckt. Habe gerade v0.3.3 released:

Was sich ändert für dich:

1. online=false ist behoben. Der Adapter zieht beim Start jetzt einen Snapshot pro Kamera, dadurch flippt cameras.<id>.online sofort vom Default false auf den echten Zustand. War vorher by-design false bis zum ersten manuellen
   Snapshot-Trigger — schlechte UX, ist jetzt raus.

2. fcm_active=error wird nicht mehr "error", sondern "polling". Die Push-Registrierung scheitert tatsächlich (gleich für beide Modi, gleich bei mir auf 4 Cams), aber der Adapter fällt jetzt automatisch auf /v11/events-Polling alle 30 Sekunden
   zurück — Bewegungs-/Audio-Events kommen weiter, nur mit ~30 s Latenz statt ~2 s mit Push. Verhalten wie die HA-Integration im fcm_push_mode=polling-Modus.

3. Echter FCM-Fehlergrund steht jetzt im Log. Der vorherige Catch hat alles geschluckt. v0.3.3 loggt:

FCM ios registration failed: 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.

Das ist der wahre Grund: die @aracna/fcm-Lib spricht eine andere Google-API (fcmregistrations.googleapis.com) als die Python-firebase_messaging-Lib in der HA-Integration (firebaseinstallations.googleapis.com). Der OSS-Key ist nur für
letztere freigeschaltet. Hatte ich an die Adresse weiterleiten — entweder wird der Key für die zweite API auch freigegeben, oder ich tausche die Node-Lib. Solange überbrückt der Polling-Fallback.

4. Bonus-Fix: kein "No PKCE verifier stored"-Crash mehr nach längerem Adapter-Stopp (>1 h). Der Refresh-Token wird beim Start jetzt proaktiv genutzt, falls der access_token abgelaufen ist — kein Browser-Login mehr nötig.

Update: GitHub-Tab Adapter > eigene Quellen → URL aktualisieren und neu installieren, oder npm direkt: npm i iobroker.bosch-smart-home-camera@0.3.3

Würdest du nochmal kurz testen und sagen ob (a) deine beiden Cams jetzt online=true melden und (b) eine Bewegung am Sensor cameras.<id>.last_motion_at ankommt (kann bis zu 30 s dauern)?

---

Frage zum nächsten Feature — was würde dir am meisten bringen?

a) VIS-2-Widget mit Live-Stream (aktuell zeigt das Beispiel-Dashboard nur Snapshot — RTSP-Stream via go2rtc/native einbinden)
b) Event-Historie als Sensor (letzte N Events pro Cam mit Zeitstempel/Typ — für Logik-Skripte)
c) Notification-Routing (z. B. Telegram/Pushover-Bot direkt im Adapter konfigurieren statt eigene Logik)
d) etwas anderes — sag's mir

Gruß
Thomas

[Jaschkopf]

Bin unterwegs und konnte übers Smartphone nur kurz testen. Adapter auf 0.3.3 aktualisiert. Cams sind beide online. Steuern von Light und privacy geht. Stream und snapshot muss ich morgen am PC testen. Nice wäre noch wenn man die Wallwasher über einen Datenpunkt steuern könnte um diese über einen externen Sensor bei allen Cams gleichzeitig schalten zu können. Momentan gehen sie bei Dämmerung bei mir zu unterschiedlichen Zeitpunkten an. Und das triggern eines Events per Datenpunkt wäre ebenfalls noch ein nützliches Feature. Dann könnte ich meinen Philips Hue Bewegungsmelder weiter unten in der Einfahrt nutzen um früher ein Event zu triggern.

Gibt es eine Limitierung was den rtsp stream angeht? Oder ist es möglich den stream 24/7 laufen zu lassen um ihn in mein BlueIris System zu integrieren?

Danke für deine Arbeit, wirklich klasse wie schnell das geht.

[ThomasM.]

Hi @Jaschkopf,

freut mich dass v0.3.3 sauber lief und die Toggles funktioniert haben. Auf deine drei Punkte vom Smartphone-Test bin ich direkt drangegangen — v0.4.0 ist gerade live:

https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/releases/tag/v0.4.0

1. Wallwasher separat schaltbar ✅

Zwei neue Datenpunkte pro Cam:

cameras.<id>.front_light_enabled   // Frontlampe (Gen1 frontLight / Gen2 front)
cameras.<id>.wallwasher_enabled    // Wallwasher (Gen1) / Top-Down-Strip (Gen2)
cameras.<id>.light_enabled         // legacy — bleibt als kombinierter Schalter

Damit kannst du in Blockly / JS einen Master-Datenpunkt anlegen, der bei Dämmerung alle vier Wallwasher gleichzeitig schaltet — ohne die Frontlampen mit anzufassen. Funktioniert auf Gen1 (via PUT /lighting_override mit beiden Flags einzeln steuerbar) und Gen2 (separate PUT /lighting/switch/front + /topdown). Hab gegen meine Terrassen-Gen2 getestet: front an / wallwasher aus geht sauber, combined light_enabled flippt erst wenn beide an sind.

Drei import-fertige Blockly-Vorlagen für genau diesen Use-Case (Master-Schalter, Dämmerungs-Auto via Astro, Hue-PIR-Bridge) hab ich gleich mit ins Repo gelegt:

https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/tree/main/docs/blockly-examples

Workflow: javascript-Adapter → Scripts → neues Blockly-Skript → XML-Icon → einfügen → <CAM_UUID> durch deine UUIDs ersetzen → Save + Run.

2. Event triggern per Datenpunkt ✅

cameras.<id>.motion_trigger             // button, write-only
cameras.<id>.motion_trigger_event_type  // selector: motion / person / audio_alarm

Workflow: setze erst das motion_trigger_event_type auf den gewünschten Typ (default "motion"), dann schreibe motion_trigger = true. Der Adapter setzt last_motion_at = now() + last_motion_event_type = <gewählter Typ> und resettet den Button automatisch zurück. Genau dasselbe Signal wie ein echtes Bosch-Motion-Event, deine bestehenden Skripte auf last_motion_at reagieren also identisch.

Damit kannst du jetzt deinen Hue-Bewegungsmelder weiter unten in der Einfahrt nutzen um die Cam-Eskalation früher zu starten. Vorlage hue-pir-to-bosch-motion.xml ist im Blockly-Ordner.

3. RTSP 24/7 für BlueIris ✅

Watchdog drin — die LOCAL-Session wird automatisch ~60 s vor Ablauf des Bosch maxSessionDuration erneuert, ohne dass der Stream am rtsp://127.0.0.1:PORT/rtsp_tunnel unterbrochen wird. BlueIris sieht keinen stündlichen Reconnect mehr.

Wichtige Designentscheidung dazu: der Adapter macht niemals Cloud-Relay-Fallback für Streams oder Snapshots. Wenn die Kamera auf dem LAN nicht erreichbar ist, kommt eine klare Fehlermeldung — kein stiller Fallback auf Bosch-Cloud-Proxies. War mir wichtig: lokale Kameras bleiben lokal, Datenverkehr verlässt nicht ungefragt das Heimnetz.

Sonstiges

• FCM-Push ist weiter im Polling-Modus (30 s Latenz).
• Token-Refresh beim Adapter-Start läuft jetzt sauber über den Refresh-Token; kein "No PKCE verifier"-Crash mehr nach längerem Stopp.

Roadmap v0.5.0+: Motion-Zonen + Privacy-Masken read/write, dann Mini-NVR mit Pre-Roll-Ring-Buffer.

Update via GitHub-eigene-Quelle / npm — und melde dich wenn was klemmt.

---

Was wäre dir als nächstes wichtig? Damit das Ding wirklich rund wird:

a) VIS-2-Widget mit echtem Live-Stream statt nur Snapshot — go2rtc/HLS-Bridge eingebaut, Klick im Dashboard öffnet sofort Video
b) Event-Historie als Sensor — letzte N Events pro Cam mit Zeitstempel + Typ, für Logik-Skripte und Auswertung
c) Notification-Routing direkt im Adapter — Telegram/Pushover/Signal-Bot bei Motion ohne eigene Skripte
d) Mehr Blockly-Vorlagen für andere Use-Cases — sag welche
e) was anderes — sag's

Gruß
Thomas

[Jaschkopf]

Ich hab gerade 0.4.0 getestet. Wallwasher an/aus geht. Beim Privacy Mode habe ich noch festgestellt, wenn ich über iobroker auf true setze und über die App die Cams wieder aktiviere, bleibt der DP auf true. Wenn ich einen motion trigger auslöse wird in der App keine Aufnahme angelegt. Der Zeitstempel im IOB aktualisier sich, aber sonst passiert nichts. Und wie ich den RTSP Stream in BlueIris empfangen kann müsstest du mir nochmal erklären. BlueIris und IOB laufen auf getrennten Systemen. Über die local host IP kann ich ja nur auf dem IOB Host zugreifen. Wie kriege ich den Stream ins Netzwerk bei mir?

[Jaschkopf]

Habe versucht den Stream in den Cameras Adapter einzubinden, aber bekomme folgende Fehlermeldung beim Verbindungstest: rtsp://127.0.0.1:43047/rtsp_tunnel: Server returned 401 Unauthorized (authorization failed)

Außerdem ändert sich der Port regelmäßig in der Stream URL. In der Cameras Config muss ich den Port aber fest vergeben. Wie löse ich das am besten?

[ThomasM.]

Hi Jaschkopf,

Danke fürs detaillierte Testen — alle drei Punkte habe ich in v0.5.1 (jetzt Beta) angefasst:

Privacy-Sync App → ioBroker
Adapter pollt jetzt alle 30 s /v11/video_inputs und spiegelt privacyMode zurück nach cameras.<id>.privacy_enabled. Wenn du in der App reaktivierst, springt der DP innerhalb von 30 s auf false.

Motion-Trigger ohne App-Aufnahme
Das ist by design und ich habe es jetzt klarer dokumentiert. motion_trigger setzt nur cameras.<id>.last_motion_at + last_motion_event_type — gedacht als Brücke für ioBroker-Automationen (Licht, Szene, Push) die auf Bosch-Motion lauschen. Eine Aufnahme in der Bosch-App kann der Adapter nicht auslösen — das entscheidet ausschließlich die Cloud-Motion-Engine auf der Kamera, und es gibt keine API, um das von außen zu triggern. Wenn du Aufnahmen vom Hue-PIR willst, müsstest du in ioBroker selbst aufzeichnen (z. B. FFmpeg-Snapshot oder die geplante Mini-NVR in v0.7.0).

BlueIris auf separatem Host → 401 + wechselnder Port
Drei Ursachen, alle gefixt:

• 401 Unauthorized: Der RTSP-Endpunkt verlangt Digest-Auth. Die alte URL rtsp://127.0.0.1:PORT/rtsp_tunnel hatte keine Credentials. Neu: cameras.<id>.stream_url enthält jetzt User+Password im URL-Format rtsp://<user>:<pass>@host:port/rtsp_tunnel?inst=1&enableaudio=1&fmtp=1&maxSessionDuration=3600. BlueIris akzeptiert das direkt.
• Wechselnder Port: Der Watchdog hat bei jeder Session-Erneuerung (~1 h) den TLS-Proxy gestoppt und neu gestartet → neuer Port. Neu: Port ist sticky pro Kamera, persistiert in cameras.<id>._proxy_port, überlebt Renewals und Adapter-Restarts.
• Zugriff von anderem Host: Standardmäßig bindet der Proxy nur auf 127.0.0.1 — von BlueIris auf einem anderen Rechner unerreichbar. Neuer Admin-Tab „RTSP / Stream": Checkbox „Expose RTSP proxy to LAN" anhaken + LAN-IP des ioBroker-Hosts eintragen (z. B. 192.168.1.50). Dann steht in stream_url direkt die externe URL, die du in BlueIris kopierst.

Setup für deinen Fall:

1. Auf v0.5.1 aktualisieren
2. Admin → Tab „RTSP / Stream" → „Expose RTSP proxy to LAN" anhaken
3. „External hostname / LAN IP" = LAN-IP deines ioBroker-Hosts
4. Speichern → Adapter restartet
5. In ioBroker den State cameras.<deine-cam-id>.stream_url kopieren (enthält dann user:pass und ext-IP)
6. In BlueIris als RTSP-Quelle einfügen — keine separaten Credentials-Felder nötig

Außerdem gibt's in v0.5.1 noch zwei neue Features:

• Sirene (Gen2): cameras.<id>.siren_active — true schreibt den 75-dB-Panic-Alarm scharf, false silenct ihn (gleicher Endpunkt wie die offizielle App).
• RGB-Wallwasher (Außenkamera II): cameras.<id>.wallwasher_color (HEX #RRGGBB, leer = warmweiß) + cameras.<id>.wallwasher_brightness (0..100). Steuert top+bottom LEDs gemeinsam; das Frontlicht bleibt unberührt.

Release: https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/releases/tag/v0.5.1

Falls BlueIris noch Probleme macht: gib mir bitte den genauen Verbindungsfehler aus dem BlueIris-Log, dann schauen wir weiter.

Viele Grüße

[Jaschkopf]

Bekomme in BlueIris leider weiterhin kein Bild. Einfügen der URL klappt, BlueIris schlüsselt das dann in die entsprechenden Felder automatisch auf. Ich bekomme aber NoSignal mit dem Fehler

Error 8000007a (CheckPort/User/Password) 0 

[Jaschkopf]

UPDATE: Wenn ich die Stream URL mit VLC-Player öffne bekomme ich den Stream rein. Dann muss scheinbar was mit den BlueIris settings noch nicht passen

[ThomasM.]

Hi @Jaschkopf,

genau das ist ein bekanntes BlueIris-Verhalten: VLC akzeptiert rtsp://user:pass@host/... direkt, BlueIris zieht die Credentials zwar in seine Felder, sendet sie aber dann nicht zuverlässig im RTSP-Digest-Challenge mit. Ergebnis: Error 8000007a (CheckPort/User/Password) → "NoSignal". Auf <ipcamtalk.com> gibt's mehrere Threads dazu, und der Fix ist immer derselbe.

Lösung für BlueIris:

1. In das Adressfeld nur den URL ohne user:pass@ eintragen, z. B.:

   rtsp://192.168.x.x:54321/rtsp_tunnel?inst=1&enableaudio=1&fmtp=1&maxSessionDuration=3600
   

2. Username und Passwort in die separaten BlueIris-Felder "Username" und "Password" eintragen (genau die Digest-Credentials aus der ioBroker stream_url, die hinter rtsp:// und vor dem @ stehen).
3. RTSP Authentication = Digest setzen (nicht "Auto", nicht "Basic").

Damit sollte's laufen — die Logik dahinter ist, dass BlueIris die In-URL-Credentials parst, aber im DESCRIBE/SETUP-Handshake nur die Felder seines eigenen Config-Dialogs verwendet.

---

Bonus: gerade neu in v0.5.2 (beta) released — der neue Livestream-Schalter

cameras.<id>.livestream_enabled (Default AUS). Bisher hat der Adapter pro Kamera beim Start eine 24/7 LOCAL-Session + TLS-Proxy + RTSP-Watchdog aufgemacht — auch wenn niemand zuschaut, kostet das täglich Quota. Ab v0.5.2 ist Streaming explizit Opt-in:

• true schreiben → PUT /v11/.../connection, Proxy startet, stream_url wird gesetzt, Watchdog läuft.
• false schreiben → Watchdog stoppt, Proxy beendet, DELETE /connection, stream_url leer.

Snapshots laufen unverändert (kurzlebige Session, nach dem JPEG sofort wieder zu).

Update via iobroker upgrade bosch-smart-home-camera — 0.5.2 ist auf npm. Release Notes: https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/releases/tag/v0.5.2

Viele Grüße
Thomas

[Jaschkopf]

Kann man vielleicht den Stream mit niedriger Bandbreite simultan ausgeben? Also pro Kamera zwei Stream URLs, quasi einen Mainstream mit hoher Bitrate und einen Substream mit niedriger Bitrate (und niedrigerer Auflösung???) BlueIris unterstützt diese Prinzip um die CPU Last zu reduzieren. Der schlechte Substream wird analysiert bis was passiert (motion) und schaltet dann auf den Mainstream um und zeichnet diesen auf.

[Jaschkopf]

User und Pass händisch eintragen habe ich probiert. Leider ohne erfolg. Die Option RTSP Authentication = Digest habe ich nicht gefunden. Kann ich irgendwie loggen was BlueIris sendet zur Authentication?

[Jaschkopf]

Machen die Sonderzeichen im User/Pass vielleicht probleme wenn BlueIris die URL wieder zusammensetzt?

[ThomasM.]

Hi @Jaschkopf,

danke fürs Dranbleiben — Posts 17 + 18 (Authentifizierung-Setting nicht gefunden, Sonderzeichen-Verdacht) haben mich nochmal dazu gebracht, das Problem an der Wurzel zu fixen statt eines Workarounds.

v0.5.3 (Beta) ist gerade raus und behebt deinen Fall direkt: https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/releases/tag/v0.5.3

Was ist neu

1. TLS-Proxy macht jetzt die Digest-Auth selbst. Die cameras.<id>.stream_url ist ab v0.5.3 eine saubere URL ohne Credentials:

rtsp://192.168.x.x:54321/rtsp_tunnel?inst=1&enableaudio=1&fmtp=1&maxSessionDuration=3600

Keine User/Pass mehr in der URL. Der Adapter-Proxy fängt die 401-Challenge der Kamera selbst ab, rechnet den Digest-Hash, injiziert den Authorization-Header und schluckt das 401, bevor dein Client es überhaupt sieht. BlueIris bekommt direkt 200 OK und muss gar nichts mehr authentifizieren. Sonderzeichen-Problem und das fehlende "RTSP Auth = Digest"-Setting sind damit aus der Welt.

2. Sub-Stream-URL für deinen BlueIris-CPU-Wunsch aus Post 16. Neuer Datenpunkt cameras.<id>.stream_url_sub — gleiche Bosch-Session, gleicher Proxy, gleiche Kostenstelle, nur mit inst=2 (niedrigere Bitrate). Mainstream für Aufnahme, Substream für die Anzeige:

rtsp://192.168.x.x:54321/rtsp_tunnel?inst=2&enableaudio=1&fmtp=1&maxSessionDuration=3600

Experimentell — hängt davon ab, ob die Gen2-Eyes-Firmware inst=2 wirklich serviert. Bitte testen und Feedback geben, dann weiß ich, ob ich's als stable markieren kann.

3. Bonus: Auto-Snapshot bei Bewegung. Bei jedem FCM-Motion-/Person-/Audio-Event holt der Adapter automatisch ein frisches JPEG und legt es als Base64-String in cameras.<id>.last_event_image ab. Damit kannst du in Blockly bei Motion direkt notify.telegram / signal / etc. triggern und das Bild mitsenden — ohne extra Snapshot-Trigger-Script. Default an, Opt-out im neuen Admin-Tab "Events / Notifications".

4. Snapshot-Session-Keep-Alive (60s). Falls deine Card oder Automation öfter snapshot_trigger setzt — der Adapter hält die Bosch-Session jetzt warm und reused sie statt jedes Mal neu zu öffnen. Erster Snap ~1-2s, alle weiteren in der 60s-Window ~200ms.

5. cameras.<id>.motion_active — Boolean-DP, true bei Motion, auto-false nach 90s. Sauberer Trigger für Blockly.

Update

iobroker upgrade bosch-smart-home-camera

Dann BlueIris-Kamera entfernen und neu anlegen mit der frischen stream_url (ohne User/Pass im Adressfeld, keine Credentials in irgendein BlueIris-Feld eintragen, RTSP-Auth auf "None" oder Default lassen). Sollte einfach funktionieren.

Falls's nicht klappt: bitte den Adapter-Log mit debug-Level posten (info → debug in der Instance-Config), die Zeile RTSP auth EF791764: ... zeigt, in welchem State der Proxy hängt.

Viele Grüße
Thomas

[ThomasM.]

v0.5.4 ist live — der Schwerpunkt liegt diesmal komplett auf der Login-UX nach euren Rückmeldungen aus diesem Thread. Plus
drei kleine Quality-Fixes, die mir beim Live-Test aufgefallen sind.

Login-UX-Overhaul

• Bosch-Login-Button direkt in den Instanz-Einstellungen. Die OAuth-URL wird jetzt zusätzlich als Datenpunkt
  bosch-smart-home-camera.0.info.login_url veröffentlicht und als klickbarer Link in der Admin-UI gerendert. Über den neuen
  Button „Bosch-Login im Browser öffnen" öffnet sich der OAuth-Flow direkt in einem neuen Tab. Kein Heraussuchen einer
  300-Zeichen-URL aus dem Log-Inspektor mehr.
• Kein Terminate-Loop mehr beim Warten auf Login. Wenn eine alte redirect_url oder ein abgelaufenes PKCE-Paar den
  Token-Tausch killen, bleibt der Adapter jetzt im awaiting_login-Modus am Leben statt sich jedes Mal selbst zu beenden. Das
  „sieht kaputt aus"-Verhalten ist damit weg.
• Neuer „Login zurücksetzen"-Button mit Bestätigungs-Dialog: löscht Tokens, PKCE-Paar, gepastete URL und login_url in
  einem Klick und startet den Adapter neu für einen frischen OAuth-Cycle. Praktisch, wenn man sich verheddert hat oder das
  Bosch-Konto wechseln will.

Bessere Diagnose-Datenpunkte

• info.connection_status (Text): logged_out | awaiting_login | connected | auth_error — viel klarer für Blockly-
  und VIS-Logik als der reine Boolean info.connection.
• info.last_login_at (ISO-Zeitstempel): wann der letzte erfolgreiche Token-Mint war. Hilft einzuschätzen, wie nah das
  Refresh-Token an den 30 Tagen offline_access-Lebensdauer dran ist.

Quality-Fixes

• Privacy-Modus killt online nicht mehr. Eine Indoor-Kamera in dauerhaftem Privacy-Modus driftete bisher nach drei
  Startup-Snapshot-Retries auf online=false, obwohl die Kamera ja erreichbar war — der Snapshot-Endpoint antwortet im
  Privacy-Modus halt nicht. Das wird jetzt als User-Status erkannt, nicht als Connectivity-Fehler.
• last_motion_at ist jetzt valides ISO 8601. Bosch liefert Zeitstempel im Java-ZonedDateTime-Format mit anhängendem
  [Europe/Berlin]. JavaScript-new Date() kann das nicht parsen, Blockly-Vergleiche scheiterten. Der Adapter strippt das
  Suffix jetzt. Wer mit dem alten String gearbeitet hat: numerische Vergleiche über new Date(...).getTime() funktionieren ab
  v0.5.4 zuverlässig.
• Snapshot-Keep-Alive-Doku ehrlich. v0.5.3 hatte „nach dem ersten Snap ~200 ms" versprochen — gemessen sind es 2–5 s
  typisch, gelegentlich 10–15 s, weil der Snapshot-Endpoint der Kamera selbst dominiert. Die Session-Wiederverwendung spart
  ~0,5–1 s (den PUT /connection-Roundtrip). README ist auf den realistischen Wert korrigiert.

Installation

npm: iobroker.bosch-smart-home-camera@0.5.4
GitHub: https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/releases/tag/v0.5.4

Aufnahme ins offizielle Repository

Pull-Request ist offen: https://github.com/ioBroker/ioBroker.repositories/pull/5983 — repochecker ist FINAL: OK. Sobald
der Review durch ist, taucht der Adapter regulär im Admin-„Adapter"-Tab auf und das rote Icon (mittlere Spalte) verschwindet.

Feedback bitte weiterhin hierher — gerade die Login-Pfade waren bisher nur theoretisch durchgetestet, da würde ich gerne
wissen, ob die neuen Buttons in echten Umgebungen anders zicken als in meiner Test-Sandbox.

[Jaschkopf]

Version 0.5.4 ist installiert und läuft soweit super. Verbindung von BlueIris zu den Kameras ist jetzt problemlos möglich. Main- und Substream funktionieren beide. Steuern der Beleuchtung funktioniert auch problemlos, lediglich der Status der DP's ändert sich nicht wenn ich das Licht über die App schalte. Oder ich war zu ungeduldig. Was mir noch als Bug aufgefallen ist, der DP motion_active wird nicht true wenn ich die Kamera auslöse. Der timestamp last_motion_at kommt aber. Darüber werte ich gerade im Skript eine Bewegung aus. Ansonsten würde ich jetzt ein paar Tage beobachten ob der Stream stabil in BlueIris läuft. Falls Probleme auftreten melde ich mich sofort. Vielen Dank für den super Support und den wirklich sehr guten Adapter!

[ThomasM.]

Danke für die Rückmeldung zu v0.5.4. Schön zu hören dass BlueIris mit Main- und Substream stabil läuft.

Beide Bugs sind nachvollziehbar. Kurz zur Diagnose und zum Fix in v0.5.5.

motion_active bleibt false: der gemeinsame Event-Handler _onMotionFired(), der motion_active auf true setzt und den
90-Sekunden-Auto-Clear-Timer startet, wurde bisher nur vom FCM-Pfad und vom synthetischen Motion-Trigger aufgerufen, nicht
vom /v11/events-Polling-Fallback. Bei dir steht vermutlich info.fcm_active auf polling (FCM-Registrierung ist auf
manchen Setups noch wackelig); dann holt der Adapter die Events alle 30 Sekunden per Polling, schreibt last_motion_at, aber
_onMotionFired() lief nie. Polling-Pfad ruft jetzt denselben Helfer auf, also kippt motion_active auch dort sauber auf
true und nach 90 s automatisch zurück.

Light-DPs ändern sich nicht bei App-Toggles: der 30-Sekunden-State-Poll holt für Gen2-Kameras seit v0.5.1
/lighting/switch, hat daraus aber bisher nur wallwasher_brightness und wallwasher_color übernommen. Die Booleans
front_light_enabled und wallwasher_enabled wurden nie aus der Antwort abgeleitet, also blieben sie auf dem letzten Wert
den ioBroker selbst geschrieben hatte. Ist jetzt gefixt: front_light_enabled folgt frontLightSettings.brightness > 0,
wallwasher_enabled folgt max(top, bottom) > 0. App-Toggles propagieren innerhalb von ~30 Sekunden.

v0.5.5 ist gerade auf npm und GitHub gelandet:
https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/releases/tag/v0.5.5 — Regression-Tests für beide Pfade sind in
test/unit/main.spec.ts (Suche nach "forum #1339866").

Gen1-Kameras sind in dem Fix noch nicht drin: /lighting_override wird beim Polling aktuell nicht abgefragt. Falls du da
Bedarf hast, sag Bescheid.

[ThomasM.]

Dürfte ich kurz mal nach Feedback fragen? Funktioniert alles? Gibt es Fragen oder Features, die fehlen?

[Jaschkopf]

Moin. Ich habe aktuell v0.6 am laufen und bin sehr zufrieden. Kann momentan keine Probleme feststellen. Lichtsteuerung geht, Events kommen zuverlässig rein und der RTSP Stream sowohl Main als auch Sub laufen wunderbar in BlueIris. Dort habe ich eine permanente Aufzeichnung mit motiondetection und anschließender KI Auswertung am laufen. Wenn Personen erkannt werden wird auf Mainstream umgeschaltet. Klappt einwandfrei.

Was ich momentan aktuell habe sind kurze Verbindungsabbrüche zur Kamera. Blue Iris meldet z.B. gestern um 21:29:58Uhr Verbindung verloren und um 21:30:41Uhr war die Verbindung wieder da. Scheint aber selten aufzutreten, seit dem Abbruch gestern war die Verbindung stabil.

[ThomasM.]

Servus, Danke für das ausführliche Feedback. Gerade die Liste der Funktionen, die bei dir laufen (Beleuchtung, Events, Main/Sub-Stream, Daueraufnahme mit Personenerkennung und Mainstream-Switch), ist hilfreich, weil das selten alles in einer Installation zusammenkommt.

Zu den ca. 43 Sekunden Aussetzer am 17.05. um 21:29: Ursache ist ein kurzer Reset der MTalk-Verbindung (Googles FCM-Push-Backend, über das wir die Kamera-Events bekommen). Das passiert gelegentlich bei Server-Rotation. In v0.6 / v0.6.1 fällt der Adapter danach auf das 30-Sekunden-Polling zurück, ohne den Push-Kanal automatisch wieder aufzubauen. Erst beim nächsten Adapter-Restart kommt MTalk zurück. Die 43 s passen exakt zu einer Polling-Runde plus Scheduling-Jitter.

Ist für v0.6.2 gefixt: Nach einem disconnect vom FCM-Listener baut der Adapter den Socket mit Exponential-Backoff (5 s → 30 s → 120 s → 600 s) wieder auf, setzt info.fcm_active zurück auf healthy sobald es klappt und stellt den Backoff bei Erfolg auf 0 zurück. Damit sollten transiente MTalk-Drops in Sekunden statt in einem 30-s-Poll-Fenster heilen. Lokal mit sechs neuen Unit-Tests abgedeckt, kommt mit dem nächsten Release.

Falls du im Log nochmal nachschauen magst, würde mich eine Zeile mit bosch-smart-home-camera rund um 21:29 interessieren, speziell ob da etwas Richtung disconnect, socket oder MTalk auftaucht. Hilft beim Bestätigen, dass die neue Reconnect-Logik genau diesen Drop-Typ trifft.