@ltsalvatore hallo, ich hab diese Lampe nicht. und es hat sich noch niemand gemeldet der diese Lampe hat. aber zusammen bekommen wir das hin. Bitte schau zuerst mal in deiner Govee App ob du die Lokale Api aktiviert hast. Lokale Api: https://app-h5.govee.com/user-manual/wlan-guide Ansonsten schau dir bitte mal die Wiki an: https://github.com/krobipd/ioBroker.govee-smart/wiki Bitte gerne mal hier reinschauen: https://github.com/krobipd/ioBroker.govee-smart/wiki/Geraete würde mich freuen den Support für dieses Gerät einzubauen, dazu brauch ich aber deine Hilfe. LG

ioT4db sagte: @dering aktuell kann ich über NPM keine Updates einspielen. habs die letzten Stunden immer mal wieder probiert. hat jemand anders auch das Problem? hat sich erledigt. Sorry, das Problem saß vor der Tastatur 🤦‍♂️

Hi Jaschkopf, danke fürs Posten der Logs — das Zeitfenster 07:33–08:03 deckt sich exakt mit dem, was ich heute Morgen lokal gesehen habe. Bosch hatte ein Cloud-Maintenance-Window genau in dem Slot, die Status-RSS bestätigt es nachträglich. Du bist nicht alleine: meine vier Kameras lagen im selben Fenster auf der Schnauze. Zu deiner Frage warum LOCAL-RTSP an der Cloud hängt: der eigentliche Stream läuft natürlich rein LAN (RTSPS, port 443 direkt zur Kamera). Was während des Watchdogs an die Cloud geht, ist das Renewal der Digest-Credentials — also der cbs-XXXXXXXX user/password den die Kamera per Digest erwartet. Diese Credentials rotieren bei jedem PUT /v11/video_inputs/{id}/connection und es gibt aktuell keinen Offline-Pfad sie zu refreshen. Solange die bestehende Session lebt (~60 Minuten), läuft der Stream weiter; sobald der Watchdog die Session erneuern will und Bosch 503 zurückgibt, killt er den Stream — und genau das ist der Fehler den deine Logs zeigen. Die Fehlermeldung "Camera offline or unreachable" ist dabei irreführend: die Kamera war die ganze Zeit am Netz, nur die Cloud nicht. Das ist mit v0.7.10 (heute Abend rausgegangen) sauber unterschieden. Drei konkrete Verbesserungen in v0.7.10: Ehrliche Fehlermeldungen — HTTP 503 zur Cloud-Session-API loggt jetzt als INFO Bosch cloud temporarily unavailable, current session continues until expiry, nicht mehr als ERROR Camera offline or unreachable. Nur wenn der TCP-Connect zur Kamera-LAN-IP wirklich fehlschlägt, gibt es noch einen ERROR. Graceful Renewal-Backoff — der Watchdog stoppt den Stream nicht mehr beim ersten gescheiterten Renewal. Stattdessen exponentielles Backoff (5s, 15s, 45s, 120s, dann alle 300s) und der Stream läuft weiter solange die bestehende Session noch gültig ist (~60min). Erst wenn die Session natural-expired ist UND das Renewal immer noch fehlschlägt, ODER wenn der LAN-TCP-Connect 3-mal in Folge scheitert, wird der Stream beendet. Maintenance-Detection — der Adapter pollt jetzt die Bosch-Status-RSS alle 5 Min und schreibt das Ergebnis in einen neuen DP cameras.<id>.maintenance_state mit States none / active / scheduled. Wenn ein aktives Maintenance-Fenster läuft, werden cloud-5xx-Fehler automatisch auf INFO downgegradet und mit [bosch-maintenance] geprefixt. Logs sehen während angekündigter Outages dann deutlich ruhiger aus. Konkret für dein Szenario: bei einem 30-Min-Maintenance-Fenster wie heute Morgen hätte v0.7.10 deine Streams am Leben gelassen. Der Watchdog hätte alle 5s, 15s, 45s … retried, die existierende Session wäre genutzt worden, und sobald Bosch wieder erreichbar gewesen wäre, hätte der nächste Retry das Renewal geschafft. Bei Cloud-Outages über 60 Minuten läuft die Session natürlich aus und es gibt aktuell keinen Offline-Refresh-Pfad. Dann stoppt der Stream weiterhin — das ist eine Bosch-API-Architekturgrenze, kein Adapter-Bug. Außerdem ist heute Abend v0.7.9 (und jetzt v0.7.10) über npm rausgegangen. Drei Sachen die für deinen BlueIris-Workflow direkt relevant sind: MQTT-Event-Bridge (opt-in, default aus) — neuer Admin-Tab unter den Settings. Wenn aktiviert, published der Adapter motion / audio / person / intrusion auf <prefix>/<cam_id>/<event_type> mit {camera, event_type, timestamp, extra} JSON-payload. Plug-and-play für Node-RED, openHAB oder direkt in eine BlueIris-Trigger-URL. Emergency LiveSession Fix — die Privacy- und Light-Writes über LAN funktionieren jetzt auch nach Adapter-Cold-Start ohne aktiven Stream. Vorher haben sie still mit 401 gefailt weil der Digest-Credential-Cache leer war. PTZ-Presets falls du eine 360° Indoor hast — neue DPs cameras.<id>.pan_preset mit States home | left | right | back_left | back_right. Upgrade-Pfad: iobroker upgrade bosch-smart-home-camera (oder über Admin → Adapter → Bosch Smart Home Camera → Update). Das Blockly-Beispiel mit Wetterstation+Bewegungsmelder das du in Post 29 gepostet hattest ist übrigens jetzt im Repo unter examples/driveway-light-automation.xml und in der README verlinkt. Danke nochmal dafür. Falls du nach dem Update noch unklare Logs siehst, immer her damit — ich teste die Adapter-Stack auf einer eigenen ioBroker-Sandbox-Instanz parallel und kann mit deinen Logs gezielt nachstellen. Viele Grüße Thomas

Derzeit nichts mehr bekannt - was bei einem Review zu sehen ist muss ich dann schaun. Maldung bezog sich primär auf Repo, Tests etc. Dinge die eh angegangen wurden.

Bin gerade dabei eine 0.0.8-beta.1 zu erstellen - was wird sich ändern : die letzten 10 gespeicherten Video aus der Cloud oder auch lokale (von der sd-Karte) werden angezeigt und können angesehen werden (für jede Kamera) Indikator, ob die Videos aus der Cloud oder Lokal abgerufen wurden Darstellung: einzelne Kamera, oder alle über ein Grid sowie die gesamte Historie dazu Kameras werden automatisch gefunden und müssen nicht mehr manuell eingebunden werden (d.h. die widget scripte vom Startpost werden überflüssig) Umsetzung über einen Server, der per javascript gestartet wird : // ============================================================ // Blink Multi-Camera Server + Widget // http://<host>:8085/ → Single + 10-Slot History darunter // http://<host>:8085/?camera=548730 → Single für eine fixe Kamera // http://<host>:8085/grid → Alle Kameras im Grid (mit History-Blättern) // http://<host>:8085/history?camera=ID → Reine History-Ansicht, 10 Slots in Reihe // http://<host>:8085/blink/<file> → Video-Datei // http://<host>:8085/cameras → JSON mit allen Kameras (inkl. History-Datenpunkten) // ============================================================ Beispiel: [image: 1779133072076-a53d7015-bbee-4594-8b6b-b6a2bfa9dcf9-image-resized.jpeg]

Habe den Adapter installiert und läuft einwandfrei mit unserem BYD. Das mit dem Akku entladen stimmt so, aber ich habe es ganz einfach gelöst und frage das Auto nur 1x pro Stunde ab. Das Intervall verkürze ich auf 5 Minuten wenn das Auto zu Hause steht und an der Wallbox angeschlossen ist.

Octopus hat uns nun in den korrekten Tarif umgestellt. Nun sehe ich "Rates" für den Go und den Standardtarif. Mit den anderen Datenpunkten muss ich mich dann mal beschäftigen. Danke dir.

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.

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