Hallo zusammen,
@Daniel-8
Sorry, dass ich mich erst jetzt wieder melde.
Ich bin gerade intensiv mit dem Reverse Engineering beschäftigt und habe auch viel Zeit im source-code der Zendure-App verbracht – alles sehr zeitaufwendig.
Wenn du aktuell auf der Firmware 2.0.1 bist, könntest du in der App mal verschiedene Einstellungen bei der Kalibrierung vornehmen und die Daten mitloggen oder beobachten?
Mich würde interessieren, wann genau sich socCompSwitch und batCalTime ändern und welche Werte in diesem Moment gesetzt werden.
Anscheinend:
version:3 vs version:2
LCNstate wurde entfernt
socCompSwitch wurde hinzugefügt.
Kann nicht selbst testen, weil ich bewusst noch kein Update durchführe(n kann).
Zu meinem Beitrag bezüglich des unknown ca-Fehlers beim SolarFlow 1600 AC+:
maxclaudi sagte:
@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.
Meine Vermutung hat sich inzwischen bestätigt und ich habe eine erfolgversprechende Lösung für die Zertifikatskette gefunden.
Da ich momentan nicht vor Ort bin, steht der finale Praxistest direkt mit dem 1600 AC+ noch aus.
Sobald ich wieder Zugriff habe, wird sich zeigen, ob der Cloud-Server damit komplett durch einen lokalen Broker ersetzt werden kann.
Ziel ist ein vollständig lokales Setup mit eigenem MQTT-Broker, zusätzlichen Keys und schnellem, direktem MQTT.
Läuft der Test erfolgreich, hätte man bis zum Ablauf des Original-Zertifikats am 6. Mai 2030 um 10:07:05 Uhr (MESZ) erst einmal Ruhe – also für gut 3,5 Jahre ein schnelles, stabiles, lokales MQTT-System.
Ich bin parallel auch gerade dabei, eine Windows-Konsolen-Anwendung zu schreiben.
Bitte habt etwas Verständnis und Geduld, wenn ich nicht immer sofort antworte.
Danke und viele Grüße!
edit 27.07.2026
Heureka :-)
[image: 1785168487516-hub-erkannt-mqtxx.png]
