NEWS Räume und Funktionen in einem Durchlauf: der Assistent in Admin 8 (mit Video)

[CptJackSparrow]

@Atifan sagte:

Hi es gab ein Update vom Adapter und ich glaube es funktioniert jetzt wieder alles richtig.

Es funktioniert zur Zeit nur sehr bedingt, da im Falle, dass ein neues Bild nicht dekodiert werden konnte, das vorherige weiter im Verzeichnis stehen bleibt. Dieses wird im Log auch angezeigt. Das liegt daran, dass v8 nicht dekodiert werden kann.

Event picture of device T8113Txxxxxxxxxx could not be decoded, keeping the previous picture (18153 bytes, format "v8_eufysecurity")

Aber wie kommt es, dass bei einigen eufy Cams v1 oder v2 jpegs kommen und bei mir v8? Hat man da einen Einfluss drauf?

[mcm1957]

@CptJackSparrow said:

Aber wie kommt es, dass bei einigen eufy Cams v1 oder v2 jpegs kommen und bei mir v8? Hat man da einen Einfluss drauf?

Ich würde sagen dass kann nur eufy sagen :-). Heißer Tipp sind Kameramodell undFirmwarestand :-)

Und bisher hat auch eine Suche mit AI keine V8 decodierung geliefert. Zwar wurde das (vermutliche) Datenformat ausgewertet aber wie bzw. wo die notwendigen Schlüssel zur Entschlüsselung ermittelt werden können ist nach meinem Wissensstand nicht bekannt.

[CptJackSparrow]

@mcm1957 sagte:
Ich würde sagen dass kann nur eufy sagen :-). Heißer Tipp sind Kameramodell undFirmwarestand :-)

Die sind schon auf github im entsprechenden Issue hinterlegt...

[CptJackSparrow]

Was mir gerade nochmal aufgefallen ist, dass die letzten Bild auf einmal vorhanden sind, wenn der Adapter neu gestartet wird. Das hieße doch, dass sich die Bilder doch decodieren lassen?!?

[typhos]

@CptJackSparrow Die Beobachtung war der entscheidende Hinweis, danke!

Das Bild kommt auf zwei verschiedenen Wegen zum Adapter:

• Bei einem Ereignis steht in der Push-Nachricht ein Link in die eufy-Cloud. Der Adapter lädt das Bild dort herunter, und genau das ist die v8-Datei, die sich nicht entschlüsseln lässt.
• Beim Start des Adapters kennt er nur den Pfad des Bildes auf der HomeBase und holt es deshalb direkt von der HomeBase über die lokale P2P-Verbindung. Auf diesem Weg kommt das Bild in einem Format, das sich entschlüsseln lässt. Deshalb waren nach einem Neustart plötzlich die richtigen Bilder da.

Die Bibliothek hat zwar einen Ausweichweg über P2P, der greift aber nur, wenn der Download aus der Cloud leer ist, und ein v8-Bild ist ein erfolgreicher Download.

Mit Version 3.3.0, die gerade erschienen ist, holt der Adapter das Bild selbst von der HomeBase, wenn das Bild aus der Cloud nicht zu entschlüsseln ist. Das Bild erscheint dann etwa eine Minute nach dem Ereignis, weil die HomeBase es erst nach dem Ende der Aufnahme speichert. Wer in der Kamera eine eigene Cliplänge eingestellt hat, wartet so lange. Im Log steht dazu statt der Warnung eine Info-Zeile:

Event picture of device T8113... could not be decoded (... format "v8_eufysecurity"), loading it from the station

Im GitHub-Issue #136 hat das mit einem Testpaket an vier Kameras funktioniert.

Zur Frage, warum manche Kameras v8 senden und andere nicht: Das entscheidet eufy, vermutlich je nach Modell und Firmware. Beeinflussen lässt sich das nach allem, was ich weiß, nicht. Mit 3.3.0 sollte das für die letzten Bilder aber keine Rolle mehr spielen.

Die Version sollte in Kürze im Beta-Repository auftauchen. Rückmeldungen, ob es bei euch auch klappt, gerne hier.

[Atifan]

Vielen Dank für den geilen Support! 👍

[mick70]

Kurze Frage: Ist Node.js 24 tatsächlich zwingend, wie in der Versionsinfo beschrieben?

[mcm1957]

@mick70 said:

Kurze Frage: Ist Node.js 24 tatsächlich zwingend, wie in der Versionsinfo beschrieben?

ja

[Thomas Braun]

@mick70 sagte:

Ist Node.js 24 tatsächlich zwingend, wie in der Versionsinfo beschrieben?

Ist aber gar kein Problem, das kommt seit heute Nachmittag ohnehin über

iob nodejs-update

angespült. Wird wohl in den nächsten Tagen dann auch offiziell zur aktuellen Empfehlung gekürt werden.

[mick70]

OK, ich konnte mich nun endlich durchringen, meinen Raspi mit Trixie/64bit neu aufzusetzen, nodejs 24.21 war gleich dabei. iob installiert, Updates gemacht, Backup eingespielt. Alles funktioniert nach einigen manuellen Eingriffen bis auf Kleinigkeiten wieder und zwar richtig gut...

...aber leider bekomme ich jetzt ausgerechnet weder Eusec 2.3 (noch von Bropat) noch 3.3 (Community) zum Laufen.

Zunächst musste ich den Adapter komplett deinstallieren und neu installieren, da die "Startdatei" nicht gefunden werden konnte. Nun ist die Eingabe der Credentials kein Problem, dann kommt per Mail das OTP, das ich in das Objekt "verify-code" eintrage. Jetzt werden zwar alle Objekte richtig ausgelesen und angelegt, dann aber kommen folgende Fehlermeldungen (Tokens, Zertifikate & IDs habe ich mit "x" unkenntlich gemacht):

eusec.1
2026-09-25 19:05:51.767	error	[push] [PushNotificationService._open] Push notifications are disabled, because the registration failed! [{"renew":false}]

eusec.1
2026-09-25 19:05:51.766	info	[main] Push notification connection closed

eusec.1
2026-09-25 19:05:51.765	error	[push] Create push credentials Error [{"error":{"cause":{"name":"RequestError","code":"SELF_SIGNED_CERT_IN_CHAIN","timings":{"start":1790355951687,"socket":1790355951701,"lookup":1790355951708,"connect":1790355951714,"error":1790355951757,"phases":{"wait":14,"dns":7,"tcp":6,"total":70}},"options":{"agent":{},"decompress":true,"timeout":{},"prefixUrl":"","body":"{\"fid\":\"xxx\",\"appId\":\"1:xxx:android:xxx\",\"authVersion\":\"FIS_v2\",\"sdkVersion\":\"a:16.3.1\"}","ignoreInvalidCookies":false,"context":{},"hooks":{"init":[],"beforeRequest":[],"beforeError":[null],"beforeRedirect":[],"beforeRetry":[],"beforeCache":[],"afterResponse":[]},"followRedirect":true,"maxRedirects":10,"throwHttpErrors":false,"username":"","password":"","http2":false,"allowGetBody":false,"copyPipedHeaders":true,"headers":{"user-agent":"got (https://github.com/sindresorhus/got)","x-android-package":"com.oceanwing.battery.cam","x-android-cert":"xxx","x-goog-api-key":"xxx","content-type":"application/json","content-length":"129","accept":"application/json","accept-encoding":"gzip, deflate, br, zstd"},"methodRewriting":false,"retry":{"limit":3,"methods":["POST"],"statusCodes":[408,413,429,500,502,503,504,521,522,524],"errorCodes":["ETIMEDOUT","ECONNRESET","EADDRINUSE","ECONNREFUSED","EPIPE","ENOTFOUND","ENETUNREACH","EAI_AGAIN"],"backoffLimit":null,"noise":100,"enforceRetryRules":false},"method":"POST","cacheOptions":{},"https":{},"resolveBodyOnly":false,"isStream":false,"responseType":"json","url":"https://firebaseinstallations.googleapis.com/v1/projects/batterycam-3250a/installations","pagination":{"countLimit":null,"backoff":0,"requestLimit":10000,"stackAllItems":false},"setHost":true,"enableUnixSockets":false,"strictContentLength":false},"message":"self-signed certificate in certificate chain","cause":{"code":"SELF_SIGNED_CERT_IN_CHAIN","name":"Error","message":"self-signed certificate in certificate chain"}},"message":"FidRegistrationFailedError: FID registration failed","context":{"fid":"dyc_xxxx"},"stacktrace":"FidRegistrationFailedError: FID registration failed\n at PushNotificationService.registerFid (/opt/iobroker/node_modules/eufy-security-client/build/push/service.js:152:19)\n at process.processTicksAndRejections (node:internal/process/task_queues:104:5)\n at async PushNotificationService.createPushCredentials (/opt/iobroker/node_modules/eufy-security-client/build/push/service.js:225:16)\n at async PushNotificationService._open (/opt/iobroker/node_modules/eufy-security-client/build/push/service.js:834:32)\n at async PushNotificationService.open (/opt/iobroker/node_modules/eufy-security-client/build/push/service.js:916:13)"},"renew":false}]

eusec.1
2026-09-25 19:05:51.762	error	[push] [PushNotificationService.registerFid] Register FID - Generic Error [{"error":{"cause":{"code":"SELF_SIGNED_CERT_IN_CHAIN","name":"Error","message":"self-signed certificate in certificate chain"},"message":"RequestError: self-signed certificate in certificate chain","stacktrace":"RequestError: self-signed certificate in certificate chain\n at ClientRequest.<anonymous> (file:///opt/iobroker/node_modules/got/dist/source/core/index.js:868:107)\n at ClientRequest.wrapper (node:events:639:12)\n at ClientRequest.emit (node:events:526:24)\n at ClientRequest.emit (node:domain:489:12)\n at emitErrorEvent (node:_http_client:114:11)\n at TLSSocket.socketErrorListener (node:_http_client:766:5)\n at TLSSocket.emit (node:events:514:28)\n at TLSSocket.emit (node:domain:489:12)\n at emitErrorNT (node:internal/streams/destroy:170:8)\n at emitErrorCloseNT (node:internal/streams/destroy:129:3)\n at TLSSocket.onConnectSecure (node:internal/tls/wrap:1775:34)\n at TLSSocket.emit (node:events:514:28)\n at TLSSocket.emit (node:domain:489:12)\n at TLSSocket._finishInit (node:internal/tls/wrap:1203:8)\n at ssl.onhandshakedone (node:internal/tls/wrap:984:12)"}}]

eusec.1
2026-09-25 19:05:51.680	info	[push] [generateFid] generateFid ["dyc_xxxx"]

eusec.1
2026-09-25 19:05:45.238	info	starting. Version 3.3.0 in /opt/iobroker/node_modules/iobroker.eusec, node: v24.21.0, js-controller: 7.2.2

Wenn ich die für mich kryptischen Meldungen richtig deute, könnte es ein altes Cookie geben, das die Registrierung verhindert - wie bekomme ich das weg? Oder was könnte ich sonst probieren?

[Atifan]

Hi habs mal in ChatGPT geknallt, vielleicht hilft dir das :)

a. Der Log ist ziemlich eindeutig: Der eusec-Adapter selbst startet korrekt, aber die Eufy-Push-Benachrichtigungen können nicht registriert werden. Der entscheidende Fehler ist das TLS-Zertifikat.

Was genau passiert

Der Ablauf ist:

eusec 3.3.0 startet

starting. Version 3.3.0
node: v24.21.0
js-controller: 7.2.2

→ Adapterstart ist grundsätzlich OK.

eusec erzeugt eine neue Firebase-ID:

[generateFid] generateFid

Danach versucht der Adapter, diese bei Google Firebase zu registrieren:

https://firebaseinstallations.googleapis.com/v1/projects/batterycam-3250/installations

Dabei scheitert die HTTPS-Verbindung:

SELF_SIGNED_CERT_IN_CHAIN
self-signed certificate in certificate chain

Dadurch kann keine Firebase/FCM Push-Credential erzeugt werden:

Create push credentials Error

Und deshalb deaktiviert eusec anschließend die Push-Funktion:

Push notifications are disabled, because the registration failed!
Wichtig: Das ist vermutlich kein Eufy-Login-Problem

Der Fehler tritt bei der Verbindung zu

firebaseinstallations.googleapis.com

auf, also bei Google/Firebase und nicht beim eigentlichen Eufy-Server.

Der relevante Fehler ist:

SELF_SIGNED_CERT_IN_CHAIN

Das bedeutet normalerweise, dass Node.js beim HTTPS-Zertifikat eine selbstsignierte bzw. nicht vertrauenswürdige Zertifikatskette sieht.

Bei deinem Setup würde ich deshalb als Erstes an Pi-hole / Technitium / DNS / HTTPS-Inspection / Proxy / eigenes CA-Zertifikat denken.

Gerade weil du Pi-hole und Technitium im Netzwerk betreibst, ist das interessant.

Ein weiterer wichtiger Punkt

Du verwendest:

eusec 3.3.0
Node.js 24.21.0
js-controller 7.2.2

Die aktuelle eusec-Entwicklung verwendet inzwischen eine deutlich neuere eufy-security-client-Basis. Im aktuellen Repository steht beispielsweise eufy-security-client 4.1.1-1; die neueren Versionen enthalten auch Änderungen rund um FCM/Push.

Das heißt: Ein Update könnte sinnvoll sein, aber dein konkreter Fehler

SELF_SIGNED_CERT_IN_CHAIN

würde ich nicht einfach durch ein Update erklären. Das ist zunächst ein TLS-/Zertifikatsproblem.

Ich würde jetzt genau das testen

In deinem ioBroker-LXC, also dort, wo eusec läuft:

curl -Iv https://firebaseinstallations.googleapis.com/

und:

openssl s_client -connect firebaseinstallations.googleapis.com:443 -servername firebaseinstallations.googleapis.com

Besonders interessant ist, welches Zertifikat dort zurückkommt.

Wenn dort beispielsweise etwas wie

issuer=...

mit deinem lokalen Netzwerk, Pi-hole, Technitium, einer Firewall oder einem eigenen Zertifikat auftaucht, haben wir den Verursacher ziemlich sicher gefunden.

Zusätzlich:

node -e "require('https').get('https://firebaseinstallations.googleapis.com',r=>console.log(r.statusCode)).on('error',e=>console.error(e))"

Wenn dort ebenfalls

SELF_SIGNED_CERT_IN_CHAIN

kommt, ist eindeutig Node.js/TLS im LXC betroffen und nicht speziell eusec.

Noch eine interessante Möglichkeit

Bei Node.js 17+ gibt es außerdem ein bekanntes Thema mit IPv6 bei firebaseinstallations.googleapis.com. Die Eufy-Security-Websocket-Dokumentation weist ausdrücklich darauf hin, dass Node bei neueren Versionen IPv6 bevorzugen kann und nennt dafür eine ipv4first-Option.

Aber: Dein Fehler ist momentan nicht ENETUNREACH, ETIMEDOUT oder eine nicht erreichbare IPv6-Adresse, sondern explizit:

SELF_SIGNED_CERT_IN_CHAIN

Deshalb würde ich zuerst das Zertifikat prüfen, nicht IPv6.

Meine Einschätzung
Bereich Status
eusec startet ✅
Node.js 24 ✅
Eufy-Bibliothek wird geladen ✅
FID wird erzeugt ✅
Verbindung zu Firebase ❌
TLS-Zertifikat ❌
FCM Push ❌
Eufy-Kameras grundsätzlich erreichbar wahrscheinlich weiterhin möglich
Ursache sehr wahrscheinlich Zertifikatskette/TLS im Netzwerk oder LXC

Schick mir am besten die Ausgabe von den beiden Befehlen curl -Iv ... und openssl s_client .... Dann können wir ziemlich genau feststellen, wer das falsche Zertifikat liefert und ob wir an Pi-hole/Technitium, Debian-CA-Zertifikaten oder Node.js ansetzen müssen.

[mcm1957]

@mick70 said:

Zunächst musste ich den Adapter komplett deinstallieren und neu installieren, da die "Startdatei" nicht gefunden werden konnte.

Das "Fehlerbild" deutet stark darauf hin, dass du den Adapter von Github installiert hattest. Das ist nicht (mehr) unterstützt und immer mehr Adapetr unterstützen diese Installationsart nicht mehr. Wenn es nicht explizit vom Maintainer angefordert wird, solltest du direkte Github Installationen nicht vornehmen.

Ich nehme an, du hast nun vom offiziellen repo installiert.

Zu deinem eigentlichen Problem wollte ich eigentlich an @typhos und @bluefox weiter verweisen die den Adapter zur Zeit betreuen. Aber da ja Quatsch-GPT eh alles kennt, wart ich mal was der noch so ausspuckt :-).

mcm1957

[mick70]

@mcm1957 Nein, war eigentlich von vornherein eine NPM-Installation. Die Github-Kontroverse hatte ich schon mitbekommen und ist ja grds. nicht nötig, wenns auch mit NPM geht (ging hier nicht z.B. mit RPI2 oder ganz alten Widgets für VIS). Da ich zwei Adapter über Github installieren musste und evtl. die Einstellung doch nicht mehr auf NPM zurückgestellt habe, habe ich das aber vorsichtshalber nochmal neu hochgezogen.

@atifan Außerdem habe ich dieses Mal Pihole abgestellt und wieder einen gebräuchlichen DNS eingestellt, um die von der KI nahegelegten Probleme auszuschließen.

Ihr beiden, welche Lösung auch immer es war, geholfen hat es - vielen Dank :) !!

[mcm1957]

Danke fürs Feedback.

Das mit Github Installs wird immer häufiger auftreten, Da Github Installationen im Normalfall wenig Vorteile bringen werden diese bei modernisierten adapter auf Typescriptbasis oftmals nicht mehr unterstützt. Generell daher die Empfehlen vorzugsweise aus den Repositories zu installieren - und sollte das mal nicht möglich sein dann von npm. Nicht auf npm gepublishte Releases sind eigentlich nur im Zuge einer intensiveren Fehlersuche sinnvoll - und asagt der Maintainer hoffwentlich was sein(e) Tester tun sollen.

Ist hier zwar OT - möchte nur klarstellen, dass das keine Schikane sein soll sondern schlicht und einfach eingesparte Sonderlocken die aus Sicht der Entwicklung kaum etwas bringen.

[Foggy]

Guten Abend,
vielen Dank zunächst einmal für diesen klasse Adapter. Ich binde aktuell eine Flutlichtkamera E30 damit ein und habe versucht die Presets anzusteuern. Bislang erfolglos. Ist bekannt, ob die Kamera die Preset Positionen grundsätzlich meldet und diese angesteuert werden können?
Gruß

[typhos]

@Foggy Danke für die Meldung. Die Preset-Datenpunkte werden für die Floodlight Cam E30 (T8426) angelegt, weil die Bibliothek eufy-security-client sie für dieses Modell als unterstützt meldet. Beim Senden fehlt die E30 aber in der Liste der Modelle, für die der Befehl tatsächlich an die Kamera geht. Das Schreiben der Datenpunkte bleibt deshalb ohne Wirkung, ohne Fehlermeldung. An deiner Bedienung liegt es also nicht.

Die Bibliothek wird nicht mehr weiterentwickelt, daher möchte ich das im Adapter lösen. Beim Livestream versteht die E30 nachweislich dieselben Befehle wie die Floodlight Cam E340, bei der die Presets funktionieren. Ob das auch für die Presets gilt, kann ich ohne die Kamera nicht prüfen. Hättest du Lust, ein Testpaket auszuprobieren?

Vorab drei kurze Fragen:

Steht bei der Kamera als Modell T8426?
Bewegen pan_left, pan_right, tilt_up und tilt_down unter eusec.0.<Station>.cameras.<Kamera> die Kamera?
Kommt beim Livestream (start_stream) ein Bild? Für die E30 ist in der Bibliothek ein weiterer Fehler bekannt: Der Stream startet, aber es kommen keine Bilder.

Zu deiner Frage, ob die Kamera ihre Presets meldet: Nein, das liefert die Bibliothek nicht. Der Adapter kann die Positionen 1 bis 4 anfahren, speichern und löschen, aber nicht anzeigen, welche davon belegt sind.