Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[maxclaudi]

@nograx
Dankeschön

edit 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 gegen mq.zen-iot.com:8883 erhä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 ca abgelehnt, 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]

@maxclaudi Ich habe tatsächlich nur 4x Hyper über den lokalen Weg angebunden. Wie das mit der neuen Serie aussieht kann ich leider nicht sagen.

[The_Stig]

@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?

[maxclaudi]

@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 protokol

Es half nur eine ältere TLS-Version im Broker.

2. Cipher-Kompatibilität anpassen: Wichtig in der Config war:

ciphers DEFAULT@SECLEVEL=1

Erst 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!

[The_Stig]

Danke dir - bin grad im Urlaub. Die Probleme traten ja nur mit EMQX auf - vorher lange Zeit ziemlich stabil. Ich schaue mir deine Tipps nochmal an, wenn ich wieder vor Ort bin.

[Berny-K]

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

[Murphy 0]

@Berny-K

Lies mal hier im Zendure Forum :
https://flarum-eu.zendure.tech/d/30405/8

Dort schreiben einige dass wegen Serverproblemen ihre SF800pro nur noch im Hems laufen.

[Berny-K]

Vielen Dank für den Tipp, habe den Zendure Support jetzt mal angeschrieben.

[petman]

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

[Murphy 0]

sorry falsch hier

[NOUSEFORANAME]

Der Adapter lief bei mir nun viele Wochen einwandfrei - jedoch mit der Zendure Cloud. Da die jetzt aber so viele Ausfälle hatte, habe ich die Steuerung nun komplett lokal via Script.
Die Metriken würde ich natürlich trotzdem gerne weiter auslösen uns als Objekte im iOBroker haben.
Also habe ich den Adapter auf lokalen MQTT Adapter umgestellt.
Den krieg ich so aber nicht ans laufen:

Beim Adapterstart kommt immer die Meldung, dass der Adapter keine IP für die Geräte ID finden konnte.

Ich verstehe aber nicht wo ich die überhaupt hinterlegen soll. Die MQTT Verbindung zum Mosquitto hab ich ja oben drüber eingegeben und diese Verbindung läuft auch.

[nograx]

@NOUSEFORANAME Kannst du mal bitte einmal den Adapter oben kurz auf Cloud stellen und den Haken bei zenSDK nutzen entfernen - danach wieder so wie du es brauchst. Es sieht so aus als versucht er deinen SF2400AC noch per zenSDK zu erreichen.

[NOUSEFORANAME]

hab ich genauso gemacht. Die Meldung ist nun weg. Leider hab ich nun das nächste Problem. Die Objekte sind nun da, werden aber alle mit NULL angezeigt. Ich hab mir das mal genauer mit KI angesehen und den Datenverkehr mitgeschnitten..
Die KI sagt:

[nograx]

Ja du hast in der App das lokale MQTT aktiviert. Das funktioniert mehr oder weniger schlecht und ist meines Wissens nach auch nicht geeignet um eine Steuerung des Gerätes zu realisieren.

Dafür ist das zenSDK besser geeignet. Meine Empfehlung ist aktuell den Adapter auf Cloud zu stellen und dann zenSDK zu nutzen. Der Adapter holt sich dann deine Geräteliste aus der Cloud und cached diese und kommuniziert dann lokale mit deinem Gerät. Sollte die Cloud ausfallen nutzt er weiterhin die Infos aus deinem Cache und läuft weiter.

Bei den neuen Geräten kannst du sonst nur per DNS rewrite aufm Router den "originalen" MQTT-Datenverkehr auf deinen lokalen MQTT umleiten um das zu realisieren was du da tun willst.

EDIT: Wenn du den lokalen MQTT vom Gerät selbst aktivierst solltest du ja auch alle Infos vom Gerät in deiner MQTT Instanz haben, da brauchst du dann keinen Adapter mehr... Wenn ich mich recht erinnere ist die Datenaktualisierung aber sehr zögerlich und ob da eine komplett Steuerung möglich ist weiß ich aktuell nicht...

[NOUSEFORANAME]

Erstmal Danke für die Antwort. Ich steuere direkt via Shelly mit nem Script. Ich möchte den Adapter ausschließlich für die Metriken nutzen. Zenki möchte ich am Gerät eigentlich nicht einschalten. Denn ich möchte ja nicht das der China Server meine Script Steuerung durcheinander bringt und Befehle vom Script und gleichzeitig von der Zenki an den Akku gehen.

[nograx]

@nouseforaname zenKI != zenSDK !!! zenSDK ist eine lokale Webschnittstelle auf dem Gerät was zum Auslesen der Daten und zur Steuerung genutzt wird.

[NOUSEFORANAME]

ich glaub ich habs jetzt begriffen. Ich dachte sobald ich HEMS von Zendure abschalte auch keine Daten mehr über den Adapter kommen. Das war ein Irrlgaube. Die kommen weiterhin. Hab somit den Datenabruf über den Adapter wieder via Cloud laufen. Danke nochmal.

[nograx]

@NOUSEFORANAME als Nachtrag und vll als Erklärung dient die Cloud in dem Fall nur noch dazu die Geräteliste zu laden. Den Rest übernimmt dann der Adapter.

[Karacho]

Hallo,
ich habe 3x Zendure SolarFlow 2400AC im System. Einer davon ist defekt und ausgetauscht worden.
Habe ihn in der Zendure App den alten rausgeschmissen und den neuen eingebunden. Funktioniert auch ganz normal.
Nach Neustart Zendure Adapter habe ich den alten aus den Objekten rausgeschmissen und der neue wird erkannt mit SN usw.
Steht aber bei Wifi auf disconnectes.
Einbindung über Cloud API
Aber er liefert keine Daten....

[getZenSdkProperties] IP address is not defined for device pCQKRq19!

Was mache ich falsch?
Danke.
Gruss
Karacho

[Murphy 0]

@karacho
Hattest du für den Neuen in der Zendure App 1x kurz das Hems aktiviert.
Irgendwas habe ich mal gelesen dass man das machen muss.
Da ich nen Hyper habe da nicht so drauf acht gegeben.