Test Adapter eusec 3.2.x

mcm1957

Aktuelle Test Version	3.2.0
Veröffentlichungsdatum	15.9.2026
Github Link	https://github.com/iobroker-community-adapters/ioBroker.eusec

Der Adapter eusec hat eine größere Überarbeitung durch @bluefox und @ttyphosj uns steht nun in der Version 3.x.x im BETA Repository zur Verfügung.

Details siehe CHANGELOG https://github.com/iobroker-community-adapters/ioBroker.eusec#changelog

Hinweis:
Das Diskussiontopic zur Versi0on 2.x.x findet sich hier: https://forum.iobroker.net/topic/82651/test-adapter-eusec-v2-0-x

Atifan

Hi, bei mir hat der Adapter unter picture_url auch kein Bild mehr angezeigt. Habe dann den Adapter vom Github-Link installiert. Das war dann Version 3.2.-7xxxxx irgendwas. Die Instanz ist bei mir aber garnicht gestartet. Deswegen hab ich dann wieder über IoBroker V3.2 latest installiert, also die letzte Version die einem angezeigt wird. Und seit dem Funktioniert der Picture Link auf einmal wieder. Ich hab keine Ahnung wieso aber es geht wieder.

mcm1957

@Atifan said:

Habe dann den Adapter vom Github-Link installiert. Das war dann Version 3.2.-7xxxxx irgendwas. Die Instanz ist bei mir aber garnicht gestartet.

Das ist das zu erwartende Verhalten. Der Adapter ist (wie in Zukunft immer mehr Adapter) nicht von Gihub installierbar.

CptJackSparrow

Das ist das zu erwartende Verhalten. Der Adapter ist (wie in Zukunft immer mehr Adapter) nicht von Gihub installierbar.

Ich habe den Adapter jetzt wieder aus ioBroker heraus installiert. Die Aktualisierung der letzten Bilder bei Bewegung funktioniert aber nicht. Ist das korrekt oder liegt da ein Problem bei mir vor?

Atifan

Hallo muss doch wieder korrigieren, der Adapter funktioniert doch nicht richtig. Unter picture_url bekomme ich zwar ein Bild, allerdings ist das nie aktuell.

mcm1957

@WG25 said:

Ich habe den Adapter jetzt wieder aus ioBroker heraus installiert.

Danke, so wäre es vorgesehen

Die Aktualisierung der letzten Bilder bei Bewegung funktioniert aber nicht. Ist das korrekt oder liegt da ein Problem bei mir vor?

Ein Fehlverhalten ist eigentnlich nie korrekt :-) (Oder meinst du die Installation?). Kann derzeit kein Problem / Fehler bei dir erkennen. Da du dazu eh Issue https://github.com/iobroker-community-adapters/ioBroker.eusec/issues/136 geöffnet hast können wir nur warten, dass sich @bluefox oder @typhosj das ansieht - die beiden haben zuletzt am Adapter gearbeitet.

CptJackSparrow

@mcm1957 sagte:
Ein Fehlverhalten ist eigentnlich nie korrekt :-)

Ich meinte eher, ob mit der 3.2.0 die letzten Bilder wieder funktionieren sollten.

Aber ich gehe davon aus, so wie ich es in dem v2 Thread geschrieben habe, dass es eine Umstellung von eufy-security-client auf eufy-sdk geben muss. So habe ich es zumindest auf github verstanden.

https://github.com/bropat/eufy-security-client und https://github.com/mega-yfue/eufy-sdk

Dann warten wir mal, was passiert. Ich bin auf jeden Fall froh und dankbar, dass ihr an diesem Adapter weiterarbeitet.

Atifan

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

Atifan

Hab hier ein Javascript, das versendet eine E-Mail an angegebene E-Mail Adresse sobald eine Person/Auto/Tier entdeckt wurde.
Das Script erkennt automatisch alle Eusec Kameras.
Es muss nur die IP-Adresse vom Iobroker und die E-Mail Adresse angepasst werden.
Vielleicht kann es einer brauchen :)

Eufy-Kamera-Mail.txt

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.

Community Forum

NEWS

Test Adapter eusec 3.2.x

Support us

403

33.1k

83.9k

1.4m