Adapter - Bosch Smart Home Kameras
-
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
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:
- 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 - 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). - 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:trueschreiben →PUT /v11/.../connection, Proxy startet,stream_urlwird gesetzt, Watchdog läuft.falseschreiben → Watchdog stoppt, Proxy beendet,DELETE /connection,stream_urlleer.
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.2Viele Grüße
Thomas - In das Adressfeld nur den URL ohne
-
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.
-
Machen die Sonderzeichen im User/Pass vielleicht probleme wenn BlueIris die URL wieder zusammensetzt?
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_urlist ab v0.5.3 eine saubere URL ohne Credentials:rtsp://192.168.x.x:54321/rtsp_tunnel?inst=1&enableaudio=1&fmtp=1&maxSessionDuration=3600Keine User/Pass mehr in der URL. Der Adapter-Proxy fängt die
401-Challenge der Kamera selbst ab, rechnet den Digest-Hash, injiziert denAuthorization-Header und schluckt das401, bevor dein Client es überhaupt sieht. BlueIris bekommt direkt200 OKund 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 mitinst=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=3600Experimentell — hängt davon ab, ob die Gen2-Eyes-Firmware
inst=2wirklich 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_imageab. Damit kannst du in Blockly bei Motion direktnotify.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-cameraDann 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→debugin der Instance-Config), die ZeileRTSP auth EF791764: ...zeigt, in welchem State der Proxy hängt.Viele Grüße
Thomas -
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_urlverö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_urloder ein abgelaufenes PKCE-Paar den
Token-Tausch killen, bleibt der Adapter jetzt imawaiting_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 Booleaninfo.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 Tagenoffline_access-Lebensdauer dran ist.
Quality-Fixes
- Privacy-Modus killt
onlinenicht mehr. Eine Indoor-Kamera in dauerhaftem Privacy-Modus driftete bisher nach drei
Startup-Snapshot-Retries aufonline=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_atist 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 übernew 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 (denPUT /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.4Aufnahme ins offizielle Repository
Pull-Request ist offen: https://github.com/ioBroker/ioBroker.repositories/pull/5983 —
repocheckeristFINAL: 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. - Bosch-Login-Button direkt in den Instanz-Einstellungen. Die OAuth-URL wird jetzt zusätzlich als Datenpunkt
-
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!
-
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(), dermotion_activeauf 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 vermutlichinfo.fcm_activeaufpolling(FCM-Registrierung ist auf
manchen Setups noch wackelig); dann holt der Adapter die Events alle 30 Sekunden per Polling, schreibtlast_motion_at, aber
_onMotionFired()lief nie. Polling-Pfad ruft jetzt denselben Helfer auf, also kipptmotion_activeauch 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 nurwallwasher_brightnessundwallwasher_colorübernommen. Die Booleans
front_light_enabledundwallwasher_enabledwurden nie aus der Antwort abgeleitet, also blieben sie auf dem letzten Wert
den ioBroker selbst geschrieben hatte. Ist jetzt gefixt:front_light_enabledfolgtfrontLightSettings.brightness > 0,
wallwasher_enabledfolgtmax(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_overridewird beim Polling aktuell nicht abgefragt. Falls du da
Bedarf hast, sag Bescheid. -
Dürfte ich kurz mal nach Feedback fragen? Funktioniert alles? Gibt es Fragen oder Features, die fehlen?
-
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.
-
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
disconnectvom FCM-Listener baut der Adapter den Socket mit Exponential-Backoff (5 s → 30 s → 120 s → 600 s) wieder auf, setztinfo.fcm_activezurück aufhealthysobald 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-camerarund um 21:29 interessieren, speziell ob da etwas Richtungdisconnect,socketoderMTalkauftaucht. Hilft beim Bestätigen, dass die neue Reconnect-Logik genau diesen Drop-Typ trifft. -
:) Na dann. Dennoch ist der Fix nicht schlecht. Das freut mich, dass alles so gut funktioniert. Ich kenne mich leider nicht mehr so gut mit ioBroker aus (Migration zu Home Assistant vor 2 Jahren). Kannst du kurz erklären, wie du das alles machst? Dann packe ich es in die Readme. Nur so eine Idee.
-
Heute auch eine größere Runde am ioBroker-Adapter, parallel zur Home-Assistant-Integration. Wer in den letzten Stunden Snapshots verloren hat: die folgenden Features fangen das ab.
Cloud-Wartungs-Erkennung. Adapter zieht stündlich den Bosch-Community-RSS-Feed. State
info.maintenance.statemitactive/scheduled/past/recent/unknown/idleplus alle Felder (title,link,scheduled_start,scheduled_end,summary). Reaktives Re-Fetch bei 5xx mit 5 Minuten Cooldown. HTML-Fallback falls die RSS-URL kippt.Lifecycle-Benachrichtigungen. Wenn Bosch eine Wartung ankündigt, schreibt der Adapter pro State-Transition ein JSON-Payload nach
info.maintenance.last_notification. Damit lässt sich per Blockly oder Script direkt eine Telegram-, Pushover- oder Signal-Nachricht triggern. Dedupliziert per(RSS-Link, State).Pro-Kamera Online/Offline-Benachrichtigungen. Bei jedem Wechsel von
cameras.<id>.onlineschreibt der Adapter ein JSON-Payload nachcameras.<id>.last_status_notification. Erste Beobachtung nach Adapter-Start bleibt stumm,unknown-Flaps werden ignoriert.LAN-Fallback für Privacy und Frontlicht. Solange die Kamera im LAN erreichbar ist, gehen Privacy und Front-Licht weiter, auch wenn die Bosch-Cloud nicht antwortet. State
cameras.<id>.lan_reachablezeigt den TCP-Ping-Status. Outage-Ping läuft alle 30 Sekunden während eines Cloud-5xx-Bursts. LAN-IP-Map wird persistent in der ioBroker-State-DB gehalten — beim nächsten Adapter-Start sofort verfügbar.Cloud-Degraded-Startup. Wenn die Bosch-Cloud beim Adapter-Start bereits 5xx liefert, hängt der Adapter sich nicht mehr in den Retry-Loop. Stattdessen werden die bekannten Kameras aus der Object-DB rehydriert, LAN-Ping läuft sofort an und die Schalter funktionieren — bis die Cloud wieder antwortet, dann übernimmt sie nahtlos.
Full notes:
- v0.7.4: https://github.com/mosandlt/ioBroker.bosch-smart-home-camera/releases/tag/v0.7.4
- npm:
iobroker.bosch-smart-home-camera - Blog: https://www.mosandl.eu/iobroker-bosch-smart-home-camera/
Bugs / Fragen: GitHub-Issue im Repo, oder hier antworten.
-
Moin. Version 0.7.4 ist installiert und läuft anstandslos. Wirklich Wahnsinn wieviel Arbeit du da rein steckst den Adapter kontinuierlich weiter zu optimieren. Im Anhang mein Blockly was ich mir gebaut habe für die Lichtsteuerung zusammen mit meinem Hue Flutlicht und zwei Hue Bewegungsmeldern. Relativ simpel, über die Helligkeit von meiner Wetterstation werden die Wallwasher und das Flutlicht gedimmt ein- bzw. ausgeschaltet. Bei Bewegung einer der Hue PIR oder einer Kamera wird das Frontlight und das Flutlicht auf hell aktiviert.
Die Integration in BlueIris sollte jeder hinbekommen. Einfach den RTSP Stream Link als neue Kamera anlegen und Einstellungen nach eigenen wünschen anpassen. Ich habe z.B. eine 24/7 Aufzeichnung (Sub-Stream) aller Kameras aktiviert die für 7 Tage aufbewahrt werden. Wenn in BlueIris eine motiondetection anspricht werden mehrere Bilder über eine Schnittstelle an CodeProject gesendet. YOLO analysiert dann die Bilder ob dort z.B. Personen, Hunde, Katzen etc. zu sehen sind. Erst wenn (in meinem Fall nur Personen) gefunden wurden, wird ein Event ausgelöst und es wird (schon mit einigen Sekunden Vorlauf) der Mainstream aufgezeichnet. Zu BlueIris gibt es aber haufenweise Anleitungen im Netz. CodeProject kann auch Gesichtserkennung oder Kennzeichenerkennung von Fahrzeugen ;)
Hier mein Blockly: Sicherheit.Kameras_Einfahrt.xml
-
Moin. Version 0.7.4 ist installiert und läuft anstandslos. Wirklich Wahnsinn wieviel Arbeit du da rein steckst den Adapter kontinuierlich weiter zu optimieren. Im Anhang mein Blockly was ich mir gebaut habe für die Lichtsteuerung zusammen mit meinem Hue Flutlicht und zwei Hue Bewegungsmeldern. Relativ simpel, über die Helligkeit von meiner Wetterstation werden die Wallwasher und das Flutlicht gedimmt ein- bzw. ausgeschaltet. Bei Bewegung einer der Hue PIR oder einer Kamera wird das Frontlight und das Flutlicht auf hell aktiviert.
Die Integration in BlueIris sollte jeder hinbekommen. Einfach den RTSP Stream Link als neue Kamera anlegen und Einstellungen nach eigenen wünschen anpassen. Ich habe z.B. eine 24/7 Aufzeichnung (Sub-Stream) aller Kameras aktiviert die für 7 Tage aufbewahrt werden. Wenn in BlueIris eine motiondetection anspricht werden mehrere Bilder über eine Schnittstelle an CodeProject gesendet. YOLO analysiert dann die Bilder ob dort z.B. Personen, Hunde, Katzen etc. zu sehen sind. Erst wenn (in meinem Fall nur Personen) gefunden wurden, wird ein Event ausgelöst und es wird (schon mit einigen Sekunden Vorlauf) der Mainstream aufgezeichnet. Zu BlueIris gibt es aber haufenweise Anleitungen im Netz. CodeProject kann auch Gesichtserkennung oder Kennzeichenerkennung von Fahrzeugen ;)
Hier mein Blockly: Sicherheit.Kameras_Einfahrt.xml
@Jaschkopf, danke für das Update und das Blockly! Dein Skript ist seit gerade eben Teil des Repos:
examples/driveway-light-automation.xml. UUIDs, HomeMatic-Serial und die Hue-Pfade habe ich durch Placeholder ersetzt (<CAM_UUID_1>,<ILLUMINATION_SENSOR>,<HUE_FLOODLIGHT>usw.), die Logik selbst ist wortwörtlich übernommen. Im Header steht ein Link zurück zu Post #29, damit andere die Diskussion finden können.Den BlueIris + CodeProject-AI/YOLO-Workflow habe ich im Haupt-README unter "External recorders" mit aufgenommen. Der genaue Tuning-Spielraum (24/7 Sub-Stream + Mainstream nur bei Person/Tier-Klassifikation) bleibt beim Nutzer, aber das Pattern ist genau das, was viele suchen, wenn sie "RTSP + KI-Person-Detection statt False-Positives" hören.
Anlass war für mich, dass der
examples/-Ordner überhaupt mal richtig wachsen sollte. Sind jetzt 20 Skripte: 8 Blockly + 12 JavaScript. Themen sind Master-Switches, Motion-Aggregation, Telegram-Bot mit/snap-Command, Nachtmodus per Schedule, Vacation-Deterrent, ein Live-Slideshow-Datenpunkt für VIS, FCM-Fallback-Monitor und ein paar weitere. Index liegt unterexamples/README.md.Kurze Einordnung zum Adapter selbst, weil bei "neuer ioBroker-Adapter" oft die Frage kommt: meine Hauptplattform ist Home Assistant. Die HA-Integration läuft hier produktiv mit allen vier Bosch-Kameras (Gen1 + Gen2). Den ioBroker-Adapter habe ich überwiegend über Claude Code portieren lassen (Sonnet/Opus), getestet wird in einer Sandbox neben der eigentlichen Instanz, parallel läuft er auch in meinem eigenen Setup. Im README steht dazu ein AI-Assisted-Badge — ich verstecke das nicht. Mein Standpunkt: wenn der Code funktioniert, die Tests grün sind und alles öffentlich reviewbar ist, warum sollte man die Technik nicht nutzen. Anders bekomme ich vier parallele Implementations (HA-Integration, Python-CLI, ioBroker-Adapter und der MCP-Server für Claude Desktop / Claude Code) zeitlich nicht gestemmt.
Falls dir beim Weiternutzen etwas auffällt oder ein Pattern fehlt, freue ich mich über weitere Beispiele — hier im Thread oder per PR.
-
Hallo Thomas, habe gerade wieder einen Ausfall beider Kamerastreams. Aufgefallen ist es, weil ich über BlueIris die Streams als iFrame auf dem Startbildschirm meiner VIS habe. und da nurnoch ein Standbild war. Cam1 ist um 7:33:54 und Cam 2 kurz danach 7:36:42 ausgefallen. Bild wurde in BlueIris einfach schwarz. Jetzt kam gerade der Stream wieder, Cam1 um 8:03:14 und Cam2 um 8:03:28.
Hier das Log vom Adapter aus den beiden Zeiträumen. Habe leider nicht auf Debug, hoffe du kannst damit trotzdem was anfangen:
Log:
Hat die Cloud-Wartung den Ausfall verursacht? Dachte eigentlich der Stream läuft lokal und nicht über die Cloud?
-
Guten Morgen. Ja, heute gab es ja eine Wartung. Eigentlich solltest du auch einen Connector oder Endpoint haben, in dem die Informationen drin stehen, wann Wartung ist, sollte in dem letzten Update eigentlich auch in io Broker mit reingekommen sein. Aber danke für die Logs. Ich werde sie mal analysieren und schauen was man noch eventuell verbessern könnte.
Ich arbeite gerade daran, dass wenn die Cloud offline ist, dass man wenigstens über den lokalen Weg den privacy Mode ein und ausschalten kann und auch die Lichter ein und ausschalten kann. Das ist das einzigste, was aktuell lokal funktioniert.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
510
Online32.9k
Benutzer83.0k
Themen1.3m
Beiträge