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.

Habe den Adapter gestern für mein kleines System (1 Syncmodul, 2 Outdoor-Kameras) installliert. Nutze ihn vorerst lediglich zum skriptgesteuerten de/aktivieren des Systems. Funktioniert super. Tolle Arbeit, vielen Dank für deine Mühe!

@Skippy07 Gibt es noch nicht. Erstelle gerne ein issue in github, am besten mit Screenshots

DANKE für die Kooperation.

Schade, wenn ich irgendwie unterstützen kann sag bescheid

@chucky666 bitte, wie meinst du? alles was du in deine VIS reingibst kannst du anzeigen und steuern. ich verstehe gerade nicht ganz was ein Schloss mit dem Adapter zu tun hat. aber wenn du das Schloss Steuerbar in den Iobroker bekommst, was mein Adapter hier nicht macht, dann könntest dus in deine VIS einbauen und mit meinem Adapter zB auf einem Shelly Display Anzeigen lassen und steuern.

Ich werde also Octopus nochmal kontaktieren müssen.

„Seit Kurzem ist der Adapter auch als npm-Paket iobroker.autodoc installierbar

Ich hab mal ne Befehlsfolge mir von der AI geben lassen mit der man einen Backupordner für den icloud-sync erzeugen kann bzw. der die rechte richtig setzt. Legt unterhalb von HOME eine subdir an und macht den pfad nach oben betretbar für iobroker SERVICE_USER="iobroker" SUBDIR="backup" TARGET="$HOME/$SUBDIR" STOP_AT="/" # nicht über diese Grenze hinaus ACLs setzen # 1. Zielordner anlegen (falls nicht da) mkdir -p "$TARGET" # 2. Pfadkette nach oben durchlaufen und x setzen, wo nötig dir="$(dirname "$TARGET")" while [ "$dir" != "$STOP_AT" ] && [ "$dir" != "/" ]; do # Nur wenn "other" noch kein x hat → ACL setzen (sonst überflüssig) other_digit=$(stat -c '%a' "$dir") other_digit=${other_digit: -1} if (( (other_digit & 1) == 0 )); then sudo setfacl -m "u:${SERVICE_USER}:x" "$dir" echo "ACL gesetzt: x auf $dir" else echo "übersprungen (hat schon o+x): $dir" fi dir="$(dirname "$dir")" done # 3. Zielordner: rX rekursiv auf Bestehendes sudo setfacl -R -m "u:${SERVICE_USER}:rX" "$TARGET" # 4. Default-ACL für künftige Inhalte sudo setfacl -d -m "u:${SERVICE_USER}:rX" "$TARGET" # 5. Kontrolle echo echo "--- Pfad-Check ---" namei -l "$TARGET" echo echo "--- ACLs auf Ziel ---" getfacl "$TARGET" echo sudo -u "$SERVICE_USER" test -r "$TARGET" && sudo -u "$SERVICE_USER" test -x "$TARGET" \ && echo "OK: $SERVICE_USER kann auf $TARGET zugreifen" \ || echo "FEHLER: Zugriff klappt nicht" $HOME auf was anders setzten, wenn erwünscht.

Nein, das funktioniert bisher nur über die App. Es hat aber noch einige Datenpunkte, die bei besserem Verständnis der Werte sicherlich zu besserer Visualisierung und Steuerung beitragen können. Dazu reichen meine Kenntnisse aber nicht. Hab das Blockly zum laufen gebracht, aber der Adapter aktualisiert manchmal einfach nicht mehr die Position. Ich denke es liegt wahrscheinlich am WLAN Emfang, der manchmal weg ist.

Der "Adapter" ioBroker.euhome ist in keinen offiziellen Repository veröffentlicht. Sein Versionsstand sollte daher als ALPHA betrachtet werden. Er sollte nur zu Testzwecken von erfahrenen Testern installiert werden. Warum der Dev den Adapter nicht in die Repositories aufnehmen lässt kann nur er beantworten. Generell gilt auch hier: Von direkten Installation von GitHub - insbesondere auf produktiven Systemen - wird explizit abgeraten. GitHub Versionen können sich jederzeit (auch kurzfristig) ändern und durchaus auch in sich inkonsistent und fehlerhaft sein. Versionsangaben von GitHub Installationen sind Schall und Rauch da die Versionsnummer zumindest bei Verwendung der standardmäßigen Umgebung erst im Zuge der Releaseerstellung geändert wird. Auf explizite Aufforderung durch den Entwickler kann eine GitHub Installation zur Fehlereingrenzung oder zum Test neuer Funktionalität - unter Inkaufnahme des erhöhten Risikos - natürlich erfolgen. Adapter die nur via GitHub oder npm (also NICHT aus einem der beiden Repositories) installierbar sind sind mit erhöhter Vorsicht zu betrachten. Hier sollte der Entwickler drum ersucht werden eine Aufnahme in die Repositories zu veranlassen indem z.B. ein Issue im Adapterrepository erstellt wird. @homoran Da der Adapter nicht im Repository geliostet ist bitte das Topic in ...nicht in offiziellem Repoverschieben.

Der Adapter ist NICHT in den offiziellen ioBroker Repositories gelistet. Er ist daher zumindest DERZEIT als im ALPHA Stadium zu betrachten. @homoran Bitte in den Bereich "...nicht in offiziellem Repo" verschieben. DANKE

INFO: Ich habe jetzt den Antrag für die Aufnahme ins Latest-Repo gestellt.

@RISSN die daten sind ja richtig, nur das widget halt nicht. da ich weder vis, noch das widget benutze, glaub ich halt an die daten... also, nicht gleich aufregen... :)