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

[Kiter1988]

@maxclaudi
Danke für eine Antwort. Das hat mich weitergebracht.

Ja lokal ohne App

ich hab den Wert per mqtt explorer abgeschickt. Dieser wurde auch angenommen.
Der Datenpunkt steht in iob nun auf 1200.

Ob die Leistung auch so aus dem Hub kommt, muss ich noch testen, dazu gabs noch keine Gelegenheit.

[T-147]

@maxclaudi
Seit gestern Abend bin ich mit meinem SF800Pro2 auch endlich am Start.
Verbindung steht und dein Script ruft sauber alle Daten ab. Jetzt verschaffe ich mir erstmal Stück für Stück einen Überblick über die ganzen Datenpunkte und deren Funktion.

Was mir persönlich fehlt, wäre eine Übersicht über die Menge an Energie, die per PV produziert, eingespeist oder über AC geladen wird.
Spricht etwas dagegen, dafür (und nur dafür) parallel den Adapter von Nograx zu verwenden und sich dort diegewünschten Daten für Influx/Grafana aus der Cloud zu holen?
Oder laufe ich Gefahr, dass sich Adapter und Script gegenseitig in die Quere kommen?

Edit: sorry, ich hab mich im Thread vertan...

[lesiflo]

@T-147 sagte:

Was mir persönlich fehlt, wäre eine Übersicht über die Menge an Energie, die per PV produziert, eingespeist oder über AC geladen wird.

Die Datenpunkte gibt es im Adapter unter "calculations"

[T-147]

@lesiflo
Ah, sorry, ich hab mich im Thread vertan, das sollte eigentlich in den Thread von maxclaudi zu seinem Script...

[T-147]

@lesiflo sagte:

Die Datenpunkte gibt es im Adapter unter "calculations"

Da gibt es in der Tat aber nur Werte für den Tag, keine Gesamtwerte, oder? Würde jetzt erwarten das Gerät speichert auch irgendwo, wieviel Strom es gesamt per PV produziert oder ins Hausnetz eingespeist hat. Einfach um langfristig mal ne Übersicht zu erhalten, was das Gerät nach zB einem Jahr an Geld eingespart hat.
Oder kann/muss ich das über nen Zwischenstecker (Shelly?) abgreifen?

[maxclaudi]

@nograx sagte:

@maxclaudi Bei mir läuft es auf dem „mqtt“ Adapter mit einem selbst signierten Zertifikat. Der Hyper scheint das Stand jetzt zu akzeptieren. Den Adapter habe ich in einer pre-release Version umgestellt. Lasse das auf dem Hyper diese Nacht mal durchlaufen und schaue ob ich mich morgen traue meine anderen 3 Hyper zu aktualisieren.

Welches Zertifikat verwendest Du auf dem Broker?

Ist es genau das Zertifikat, das mit folgendem Befehl erzeugt wurde?

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout mqtt_rsa.key \
  -out mqtt_rsa.crt \
  -days 3650 \
  -subj "/CN=homeassistant"

Oder verwendest Du das Standard-EMQX-Zertifikat oder ein anderes Zertifikat?
Falls ein anderes: Wie hast Du es erzeugt?

Ich habe den Befehl nachgestellt und Mosquitto mit dem erzeugten Zertifikat konfiguriert. Der TLS-Handshake startet zwar, aber mein SolarFlow 1600 AC+ bricht ihn sofort ab mit:

tlsv1 alert unknown ca

Deshalb würde mich interessieren, ob Du wirklich genau dieses Zertifikat verwendest oder ob noch etwas an der Zertifikatserstellung bzw. TLS-Konfiguration anders ist.

[nograx]

@maxclaudi Ich habe das Standard-Zertifikat vom EMQX drin gelassen. Das wird bei mir anstandslos akzeptiert. Bis heute auch keinerlei Ausfall bei Verbindung und der Bypass lief bis jetzt auch super. Bin aktuell sehr zufrieden mit der Konstellation.

[maxclaudi]

@nograx
Du hast doch anfangs, bevor Du EMQX als Broker verwendet hast, den ioBroker-MQTT-Adapter mit einem selbstsignierten Zertifikat betrieben. Weißt Du noch, wie Du dieses Zertifikat erzeugt hast oder nach welcher Anleitung Du dabei vorgegangen bist?

Ich habe die in diesem GitHub-Kommentar beschriebene Vorgehensweise ausprobiert:
[Bug] HYPER 2000 firmware update and Zendure Home Assistant problems

Leider akzeptiert mein SolarFlow 1600 AC+ das so erzeugte Zertifikat nicht und bricht den TLS-Handshake ab mit:
tlsv1 alert unknown ca

Deshalb würde mich interessieren, ob Dein damaliges Zertifikat wirklich genauso erzeugt wurde oder ob es dabei noch Unterschiede gab.

[Bernd1967]

Ich glaube es gibt aktuell mal wieder cloud Probleme.
Die Zendure App ist fast nicht mehr bedienbar.
Zendure Forum
Der solarflow Adapter streikt bei mir mit folgenden Fehler:

TypeError: Converting circular structure to JSON --> starting at object with constructor 'Agent' | property 'sockets' -> object with constructor 'Object' | property 'app.zendure.tech:443

[Murphy 0]

Jetzt scheint sogar das Forum down zu sein?
Es ist nicht zu glauben 😂😂😂

[lesiflo]

Geht jetzt wieder.

[nograx]

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.

[Rico Sander]

@bernd1967 , @nograx

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...

[maxclaudi]

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

@maxclaudi Habe ich dir per PN geschickt

[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.