Test Adapter Zendure Solarflow
-
Nach den gestrigen Meldungen weiterhin froh alles lokal laufen zu haben. Keinerlei Probleme gehabt ;-)
@maxclaudi Ich habe das Zertifikat per ioBroker Javascript Adapter erzeugt, da ich zu dem Zeitpunkt unterwegs war und keinen Zugriff per SSH hatte und nur einen Browser ;-) Das Script habe ich mir da auch schnell per Claude erstellen lassen. "Erstelle ein ioBroker Javascript das mir ein MQTT kompatibles Zertifikat erzeugt. Meine IP lautet XX.XX.XX.XX und mein interner DNS Name lautet XX.XX. default_bits = 2048". Oder so ähnlich.
Nach den gestrigen Meldungen weiterhin froh alles lokal laufen zu haben. Keinerlei Probleme gehabt ;-)
Kann ich bestätigen. Tagsüber war die SF angeblich offline, obwohl sie im WLAN fest verankert war und die lokale Steuerung ohne Probleme lief.
Am abend war die App wieder zum Leben erwacht, auch heute morgen alles ok.
Ich hatte am Abend noch den Support angeschrieben.Schönen Tag Euch da draußen...
-
Nach den gestrigen Meldungen weiterhin froh alles lokal laufen zu haben. Keinerlei Probleme gehabt ;-)
@maxclaudi Ich habe das Zertifikat per ioBroker Javascript Adapter erzeugt, da ich zu dem Zeitpunkt unterwegs war und keinen Zugriff per SSH hatte und nur einen Browser ;-) Das Script habe ich mir da auch schnell per Claude erstellen lassen. "Erstelle ein ioBroker Javascript das mir ein MQTT kompatibles Zertifikat erzeugt. Meine IP lautet XX.XX.XX.XX und mein interner DNS Name lautet XX.XX. default_bits = 2048". Oder so ähnlich.
@nograx
Hast Du das JavaScript bzw. den erzeugten OpenSSL-Configtext noch? Mich würde interessieren, welche Extensions (CN/SAN) darin verwendet wurden.Zu den gestrigen Meldungen: Mein Script zur Steuerung lief bis jetzt auch ohne Probleme.
-
@nograx
Hast Du das JavaScript bzw. den erzeugten OpenSSL-Configtext noch? Mich würde interessieren, welche Extensions (CN/SAN) darin verwendet wurden.Zu den gestrigen Meldungen: Mein Script zur Steuerung lief bis jetzt auch ohne Probleme.
-
@maxclaudi Habe ich dir per PN geschickt
@nograx
Dankeschönedit 12.07.2026 11.00h:
Ich habe das ebenfalls getestet. Leider wurde dieses – noch einfachere – Zertifikat von meinem 1600AC+ ebenfalls nicht akzeptiert.Info:
Mit openssl s_client gegenmq.zen-iot.com:8883erhält man folgende Informationen:CONNECTED(00000004) depth=1 C=CN, ST=hangzhou, O=EMQ, CN=RootCA verify error:num=19:self-signed certificate in certificate chain verify return:1 depth=1 C=CN, ST=hangzhou, O=EMQ, CN=RootCA verify return:1 depth=0 C=CN, ST=hangzhou, O=EMQ, CN=Server verify return:1 ..... --- Certificate chain 0 s:C=CN, ST=hangzhou, O=EMQ, CN=Server i:C=CN, ST=hangzhou, O=EMQ, CN=RootCA a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: May 8 08:07:05 2020 GMT; NotAfter: May 6 08:07:05 2030 GMT ...... 1 s:C=CN, ST=hangzhou, O=EMQ, CN=RootCA i:C=CN, ST=hangzhou, O=EMQ, CN=RootCA a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: May 8 08:06:52 2020 GMT; NotAfter: May 6 08:06:52 2030 GMT Server certificate subject=C=CN, ST=hangzhou, O=EMQ, CN=Server issuer=C=CN, ST=hangzhou, O=EMQ, CN=RootCA --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 2205 bytes and written 402 bytes Verification error: self-signed certificate in certificate chain --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit This TLS version forbids renegotiation. No ALPN negotiated Early data was not sent Verify return code: 19 (self-signed certificate in certificate chain)Nach meiner Interpretation bedeutet das:
- Zendure verwendet kein einzelnes selbstsigniertes Serverzertifikat, sondern eine Zertifikatskette aus einer selbstsignierten Root-CA (RootCA) und einem von dieser Root-CA signierten Serverzertifikat (Server).
- Die Root-CA ist selbstsigniert und wird vom OpenSSL-Client deshalb erwartungsgemäß nicht als vertrauenswürdig eingestuft (Verify return code: 19).
- Das Serverzertifikat verwendet RSA-2048 und ist bis 2030 gültig. Interessant ist das Ausstellungsdatum von bereits 2020.
Bei meinem SolarFlow 1600 AC+ wird ein einfaches selbstsigniertes Serverzertifikat bisher mit
unknown caabgelehnt, obwohl RSA-2048, TLS 1.2, passende Cipher und SAN verwendet werden.Nach den bisherigen Erkenntnissen scheint sich die TLS-Implementierung der Hyper-Geräte von der der neueren AC-Serie zu unterscheiden. Ob dies tatsächlich an einer strengeren Zertifikatsprüfung liegt oder eine andere Ursache hat, ist mir derzeit noch unklar.
Als nächsten Schritt werde ich versuchen, statt eines einzelnen selbstsignierten Serverzertifikats ebenfalls eine Zertifikatskette (Root-CA - > Serverzertifikat) nachzubilden.
Ob das vom 1600 AC+ akzeptiert wird, halte ich allerdings für eher fraglich. -
@nograx
Dankeschönedit 12.07.2026 11.00h:
Ich habe das ebenfalls getestet. Leider wurde dieses – noch einfachere – Zertifikat von meinem 1600AC+ ebenfalls nicht akzeptiert.Info:
Mit openssl s_client gegenmq.zen-iot.com:8883erhält man folgende Informationen:CONNECTED(00000004) depth=1 C=CN, ST=hangzhou, O=EMQ, CN=RootCA verify error:num=19:self-signed certificate in certificate chain verify return:1 depth=1 C=CN, ST=hangzhou, O=EMQ, CN=RootCA verify return:1 depth=0 C=CN, ST=hangzhou, O=EMQ, CN=Server verify return:1 ..... --- Certificate chain 0 s:C=CN, ST=hangzhou, O=EMQ, CN=Server i:C=CN, ST=hangzhou, O=EMQ, CN=RootCA a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: May 8 08:07:05 2020 GMT; NotAfter: May 6 08:07:05 2030 GMT ...... 1 s:C=CN, ST=hangzhou, O=EMQ, CN=RootCA i:C=CN, ST=hangzhou, O=EMQ, CN=RootCA a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: May 8 08:06:52 2020 GMT; NotAfter: May 6 08:06:52 2030 GMT Server certificate subject=C=CN, ST=hangzhou, O=EMQ, CN=Server issuer=C=CN, ST=hangzhou, O=EMQ, CN=RootCA --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 2205 bytes and written 402 bytes Verification error: self-signed certificate in certificate chain --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit This TLS version forbids renegotiation. No ALPN negotiated Early data was not sent Verify return code: 19 (self-signed certificate in certificate chain)Nach meiner Interpretation bedeutet das:
- Zendure verwendet kein einzelnes selbstsigniertes Serverzertifikat, sondern eine Zertifikatskette aus einer selbstsignierten Root-CA (RootCA) und einem von dieser Root-CA signierten Serverzertifikat (Server).
- Die Root-CA ist selbstsigniert und wird vom OpenSSL-Client deshalb erwartungsgemäß nicht als vertrauenswürdig eingestuft (Verify return code: 19).
- Das Serverzertifikat verwendet RSA-2048 und ist bis 2030 gültig. Interessant ist das Ausstellungsdatum von bereits 2020.
Bei meinem SolarFlow 1600 AC+ wird ein einfaches selbstsigniertes Serverzertifikat bisher mit
unknown caabgelehnt, obwohl RSA-2048, TLS 1.2, passende Cipher und SAN verwendet werden.Nach den bisherigen Erkenntnissen scheint sich die TLS-Implementierung der Hyper-Geräte von der der neueren AC-Serie zu unterscheiden. Ob dies tatsächlich an einer strengeren Zertifikatsprüfung liegt oder eine andere Ursache hat, ist mir derzeit noch unklar.
Als nächsten Schritt werde ich versuchen, statt eines einzelnen selbstsignierten Serverzertifikats ebenfalls eine Zertifikatskette (Root-CA - > Serverzertifikat) nachzubilden.
Ob das vom 1600 AC+ akzeptiert wird, halte ich allerdings für eher fraglich. -
@nograx ich habe seit der Umstellung auf EMQX immer mal wieder das Problem, dass für 10-15 Minuten keine Daten am Zendure aktualisiert werden. Das scheint dann bei dir nicht der Fall zu sein, oder?
@The_Stig sagte:
@nograx ich habe seit der Umstellung auf EMQX immer mal wieder das Problem, dass für 10-15 Minuten keine Daten am Zendure aktualisiert werden. Das scheint dann bei dir nicht der Fall zu sein, oder?Keine Antwort?
habe heute ein Zendure Hyper2000-Testgerät bekommen, von der Cloud getrennt und mit einem lokalen Mosquitto-Broker über TLS verbunden.
Danach kamen anfangs ebenfalls - wenn überhaupt - nur sehr spärlich Daten.
Der Hyper zickte deutlich mehr herum als die neueren Geräte.
Im Gegensatz zu diesen musste ich bei dem Hyper drei zusätzliche Dinge anpassen, damit es läuft:
1. Kein TLSv1.3 nutzen: Sonst gab es ständig Verbindungsabbrüche
OpenSSL Error[0]: error:0A000102:SSL routines::unsupported protokolEs half nur eine ältere TLS-Version im Broker.
2. Cipher-Kompatibilität anpassen: Wichtig in der Config war:
ciphers DEFAULT@SECLEVEL=1Erst mit den älteren Ciphers läuft die Verbindung stabil. Danach musste der Broker natürlich neu gestartet werden.
3. den Hyper einmal komplett von PV und 230V AC trennen.
Das Gerät hat keine Batterie, schaltet aber brav mit einem 200W-Modul in den Bypass und läuft seitdem einwandfrei über TLS mit permanenten Updates.
:-)
Nutze selbst zwar kein EMQX, aber vielleicht helfen Dir die TLS/Cipher-Anpassungen trotzdem weiter.
EMQX blockiert standardmäßig auch gerne ältere Verschlüsselungen, was Aussetzer erklären könnte.Vielleicht hilft bei dir aber auch schon Schritt 3 – also einmal komplett stromlos machen.
Viel Erfolg!
-
Hallo zusammen,
hoffe ich bin hier richtig mit meinem Problem.
Betreibe meinen SF800Pro seit Monaten mit dem Zendure Adapter und iobroker Script. Vor 2 Tagen ging das Gerät dann plötzlich auf Standby und ich kriege den da nicht mehr raus. Nur wenn ich HEMS einschalte kommt er wieder aus dem Standby. Wenn ich HEMS wieder aus schalte geht er so nach ca. 5s wieder in Standby. Habe jetzt Stunden lang alles mögliche versucht und bin echt am Verzweifeln. Hat von euch vielleicht noch jemand eine Idee? Habe übrigens nicht auf V2.01 upgedated, bin auf V1.0.23 -
Hallo zusammen,
hoffe ich bin hier richtig mit meinem Problem.
Betreibe meinen SF800Pro seit Monaten mit dem Zendure Adapter und iobroker Script. Vor 2 Tagen ging das Gerät dann plötzlich auf Standby und ich kriege den da nicht mehr raus. Nur wenn ich HEMS einschalte kommt er wieder aus dem Standby. Wenn ich HEMS wieder aus schalte geht er so nach ca. 5s wieder in Standby. Habe jetzt Stunden lang alles mögliche versucht und bin echt am Verzweifeln. Hat von euch vielleicht noch jemand eine Idee? Habe übrigens nicht auf V2.01 upgedated, bin auf V1.0.23 -
Frage:
Wie kann ich einen zweiten SF aus dem Adapter entfernen? Wenn da einmal einer ausgewählt wurde kann ich den nur ändern aber nicht löschen.
Peter
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
263
Online33.0k
Benutzer83.6k
Themen1.3m
Beiträge