Test Adapter Zendure Solarflow

nograx

@MP_Trixi Das ist komisch.

2 Lösungansätze die ich da hätte:

zenSDK in den Adaptereinstellungen deaktivieren und dann autoModel noch mal setzen (das läuft dann über den Cloud MQTT Server), danach kann zenSDK wieder aktiviert werden.
Das ganze direkt in der App Einstellungen vornehmen (alle Energiepläne abwählen -> resultiert dann in autoModel: 0).

Hinweis: autoModel = Energieplan in den App Einstellungen. Energiepläne werden bei Zendure von der Cloud gesteuert. Wenn du zenSDK nutzt, schreibst du Einstellungen direkt auf dem Gerät. Eine direkte Logik gibt es nicht auf dem System selbst (also Energiepläne oder ein was soll ich tun wenn sich hier ein Wert ändert).

Eine Steuerung per zenSDK ersetzt quasi immer die Cloud Steuerung.

nograx

@Bernd1967 Bzgl. Batcur scheint es dann bei den Geräten unterschiedlich gehandhabt zu werden. Bei meinen Hypern wird das zum Beispiel sauber umgerechnet.

MP_Trixi

@nograx Danke für die Antwort

kann ich erst morgen testen
Ich hatte das Gerät nicht in HEMS (Ich habe keine extra CTs nach dem Zähler für den Zendure, sondern will die Steuerung über iobroker mit dem per Modbus angebunden Wechselrichter der großen Anlage steuern). Deshalb hatte ich sonst in der App nur die Einstellungen für den Netzanschluss (steht aktuell auf "Netzausgangsmodus" mit Ausgang (für Haus) 250W und "Strategie der Leistungsverteilung" (Priorität lässt sich nicht einstellen, Überschüssige Energie exportieren steht auf "Zulassen") machen. Dazu noch für die Off-Grid-Steckdosensteuerung (ist aber nichts angeschlossen) und Akkueinstellungen (10-100%). Ich habe nun HEMS aktiviert und den Energieplan auf "Automatischer Modus" stehen. Mal sehen ob es damit dann geht. Oder sollte da dann Grundlastmodus rein, was für meine Anwendung vermutlich das ist was ich bräuchte - ich will selbst sagen, was er gerade einspeisen soll, solange die Batterie noch nicht voll ist, bzw. wie er diese dann leert. Ganz abwählen geht nicht, eins muss gewählt werden (entweder Zenki, Auto, Stromzähler, smarte Steckdosen, Grundlast oder Stromtarif).

Bernd1967

@nograx sagte:

@Bernd1967 Bzgl. Batcur scheint es dann bei den Geräten unterschiedlich gehandhabt zu werden. Bei meinen Hypern wird das zum Beispiel sauber umgerechnet.

Ja, beim Solarflow 800 Pro 2 ist das wohl geändert worden auf Basis 16Bit. Welche Geräte da noch betroffen sind weiß ich nicht. Über KI kann man das herausfinden aber eine Quelle kann ich dir nicht nennen.

Beispiel Formel :

if (batcur > 32767) {
batcur -= 65536;
}
batcur = batcur / 10;

maxclaudi

@Bernd1967 sagte:

@nograx sagte:

@Bernd1967 Bzgl. Batcur scheint es dann bei den Geräten unterschiedlich gehandhabt zu werden. Bei meinen Hypern wird das zum Beispiel sauber umgerechnet.

Ja, beim Solarflow 800 Pro 2 ist das wohl geändert worden auf Basis 16Bit. Welche Geräte da noch betroffen sind weiß ich nicht. Über KI kann man das herausfinden aber eine Quelle kann ich dir nicht nennen.

Beispiel Formel :

if (batcur > 32767) {
batcur -= 65536;
}
batcur = batcur / 10;

Zendure hat m. M. n. den Wert für batcur schon immer als vorzeichenbehafteten 16-Bit-Int im 2er-Komplement übertragen?

Beim Laden (positiv) mit kleinem Wert wie z. B. 28 funktioniert das mit einer Berechnung ohne jede Anpassung (28 / 10 = 2,8 A) zufällig.

Warum? Weil das oberste Bit für das Vorzeichen Null ist.
Sobald beim Entladen der Wert negativ wird, wird der 16-Bit-Int (Zweierkomplement) > 32767.

Faszinierend, dass eine KI ohne Quelle exakt den manuellen mathematischen Workaround meines Skripts als Antwort ausgibt.

nograx

@maxclaudi Bei meinen Geräten passt das auch bei Minus-Werten (Hyper 2000 und SF2400Pro) immer:

maxclaudi

@nograx sagte:

@maxclaudi Bei meinen Geräten passt das auch bei Minus-Werten (Hyper 2000 und SF2400Pro) immer:

Zendure hat m. M. n. den Wert für batcur schon immer geräteübergreifend als vorzeichenbehafteten 16-Bit-Int im 2er-Komplement übertragen.

Sobald beim Entladen der Wert negativ wird, wird der 16-Bit-Int (Zweierkomplement) > 32767.

Ein Entladestrom von -3,3 A wird als Rohwert 65503 übertragen.
Teilt man diesen Wert einfach durch 10, kommen rechnerisch 6550,3 A heraus.

Dass im gezeigten Screenshot ein Alias-Datenpunkt (alias.0...) einen korrekten Minuswert anzeigt, liegt vermutlich an einer im ioBroker-Alias hinterlegten Konvertierungsfunktion.

Wie dem auch sei, das zenSDK liefert definitiv ein 16-Bit-Int (Zweierkomplement), auch für den SF2400pro.

Bernd1967

Im Zendure-HA Adapter von Fireson ist auch die Umrechnung von "Batcur" so drin in der Datei "entity.py". Er hat das auch bei "BatVolt" gleich so gemacht, vielleicht vorsoglich, falls ein neues Gerät das bei der Spannung auch so überträgt.

Bernd1967

@maxclaudi sagte:
........
Faszinierend, dass eine KI ohne Quelle exakt den manuellen mathematischen Workaround meines Skripts als Antwort ausgibt.

Das war die G***le KI.
Suchwörter: "zendure solarflow 800 Pro2 akku Strom batcur über 65000" .Dann Fragen nach Quelle und Beispielcode.
Den Code habe ich dann gekürzt.

maxclaudi

entity.py

3 interessante Fakten, wenn man den Code anschaut:

Die dortige Zuweisung für den Batteriestrom ist:

"batcur": (
    "template",
    "{{ value / 10 if (value | int) < 32768 else (value | bitwise_xor(0x8000 | int) - 0x8000 | int) / 10 }}",
    "A",
    "current",
),

Keine neue Änderung.
Der Code wurde dort bereits vor 10 Monaten implementiert.
Das Format (16-Bit-Zweierkomplement) ist bei der Zendure-API folglich keine neue Änderung des aktuellen SolarFlow 800 Pro 2, sondern wird schon immer so codiert.
Anderer Syntax:
Das HA-Template nutzt eine verschachtelte Jinja2-Logik mit bitweisen Operationen (bitwise_xor).
Mein minimalistischer KISS Workaround ist mathematisch identisch, umgeht dabei aber bitweise Operationen, um das einfach in JavaScript umzusetzen
die Datei zeigt auch, wie schnell Copy-Paste fehlerhaft sein kann.
Bei der Batteriespannung (BatVolt) wurde exakt derselbe Template-Block hinterlegt.

Das ist Unfug:

"BatVolt": (
    "template",
    "{{ value / 100 if (value | int) < 32768 else (value | bitwise_xor(0x8000 | int) - 0x8000 | int) / 100 }}",
    "V",
    "voltage",
),

Eine Batterie-Nennspannung im SolarFlow-Bereich kann physikalisch niemals negativ werden und laut zenSDK bei einer Auflösung von 0.01V niemals Werte über 327 V erreichen.
Darum ist dieser else-Zweig für die Spannung technisch unlogisch.

nograx

An dieser Stelle mal eine Warnung für alle die einen Hyper lokal nutzen und über das neuste Firmware Update nachdenken...

Die Geräte funken anschließend nur noch per SSL auf Port 8883!

Murphy 0

@nograx
Danke für die wichtige Info.
Bestätigt mein Vorgehen bei Zendure, so lange es läuft „never change a running system“ 😉

nograx

@Murphy-0 Jo hätte ich mich auch mal dran gehalten… aber so ist der Druck größer eine Lösung im Adapter zu finden.

Man kommt aber nicht mehr drum rum einen MQTT mit SSL und Zertifikat zu betreiben. Oder alte Firmware.

Bin neugierig ob der Freeze Bug und 99% Bug endlich behoben ist.

maxclaudi

@nograx sagte:

An dieser Stelle mal eine Warnung für alle die einen Hyper lokal nutzen und über das neuste Firmware Update nachdenken...

Die Geräte funken anschließend nur noch per SSL auf Port 8883!

Weil das neue EU-Recht (EN 18031) eine Verschlüsselung für IoT-Hardware vorschreibt, ist es vermutlich nur eine Frage der Zeit, bis Zendure auch bei allen älteren Geräten per Update nachzieht.
Früher oder später wird der Cloud-Zugang über Port 1883 gesetzeskonform deaktiviert werden müssen.

EN 18031 schreibt vor:

Verschlüsselungspflicht (TLS): Jede Kommunikation von IoT-Geräten über das Internet (also zur Zendure-Cloud) darf nicht mehr unverschlüsselt (Klartext) erfolgen.
Port 1883 überträgt alles (auch Passwörter und Tokens) unverschlüsselt.
Das ist nach neuem EU-Recht für Neu- und Bestandsgeräte mit Internetzugang verboten.
Deshalb stellt Zendure jetzt radikal auf MQTTS (Port 8883 mit SSL/TLS) um.
Verbot von Standard-Passwörtern:
Die Zeiten, in denen Geräte ein universelles Standard-Passwort nutzen oder Passwörter leicht erratbar im Klartext übertragen werden, sind gesetzlich vorbei.
Jedes Gerät muss eine sichere, verschlüsselte Authentifizierung nutzen.

Zwei neue Hub 2000 der älteren Generation habe ich erst vor wenigen Tagen auf die Firmware V3.0.24 aktualisiert – dort läuft derzeit noch alles unverschlüsselt über Port 1883.

Von den ersten Geräten der neueren Generationen – speziell SF800 und 2400AC – sind allerdings noch einige Geräte mit alter Firmware im Umlauf.
Im Auslieferungszustand lohnt es sich zu prüfen, ob sie noch nicht auf SSL-Verschlüsselung (Port 8883) umgestellt sind.

Solange das der Fall ist, ist das offizielle lokale MQTT noch nicht reglementiert bzw. gedrosselt.
Noch besser: Man kann DNS umbiegen oder umschreiben und den eigenen lokalen Broker als Cloud-Broker verwenden.

nograx

Ja verstehe den Grund dafür und macht auch total Sinn. Für mich kam es trotzdem überraschend und war im ersten Moment total ärgerlich weil ich nicht verstanden habe warum das Gerät quasi tot war.

Aktuell läuft bei mir als Test per DNS rewrite auf lokalen MQTT mit Port 8883.

maxclaudi

@nograx
darf gar nicht schreiben, wie ich mich fühle...
Alles lief perfekt und schnell mit dem Cloud-Ersatz-Broker, und dann macht einem die EU einen Strich durch die Rechnung.

Wenn man wenigstens unkompliziert ein eigenes Zertifikat ausstellen und im Gerät hinterlegen könnte.
Ich bin an dem Thema Zertifikate aktuell dran – bisher ohne Erfolg.

Das ist auch der Grund, warum ich meinen 1600AC+ komplett auf das zenSDK umgestellt habe.
Den habe ich damit inzwischen soweit, dass er lokal fast alles macht, was ich will.

Ein echter, lokaler Cloud-Ersatz-Broker trotz SSL wäre bzw. ist hier natürlich das absolute Non plus Ultra.

Aber leider...

nograx

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

maxclaudi

@nograx
ja, funktioniert noch. Nur sollte man gleich im Hinterkopf behalten, dass das vermutlich nur so lange funktioniert, wie die Firmware auf Port 8883 die Signierung des Zertifikats durch eine offizielle Behörde noch nicht streng validiert.

Sobald Zendure hier die Daumenschrauben anzieht – was durch die Vorgaben der EN 18031 für internetfähige Geräte leider über kurz oder lang zwingend vorgeschrieben ist (Stichwort Certificate Pinning oder strikte CA-Prüfung) –, könnte dieser charmante DNS-Weg mit selbstsignierten Zertifikaten leider auch ganz schnell wieder Geschichte sein.

nograx

Ich habe jetzt meine 4 Hyper auf dem lokalen MQTT mit TLS am laufen. Bin aber ehrlich gesagt sehr unzufrieden. Der Freeze bzw. der Connection Probleme tauchen hier jetzt viel häufiger auf. Bin jetzt absolut kein MQTT oder TLS Experte, aber folgende Meldung erscheint im Log:

connection closed: Error: XXXXXXXXXXXXXXXX:error:0A000119:SSL routines:tls_get_more_records:decryption failed or bad record mac:../deps/openssl/openssl/ssl/record/methods/tls_common.c:802:

Generell funktioniert die Kommunikation, aber ca. alle halbe Stunde meldet sich ein Hyper mit dieser Meldung und dann kommen keine neuen Daten bzw. ist eine Steuerung nicht mehr möglich. Manchmal reconnected das Gerät nach 3-4 Minuten, aber nicht immer.

maxclaudi

@nograx
Wenn die Verbindung grundsätzlich aufgebaut wird und MQTT-Daten zunächst funktionieren, dann sind DNS-Umleitung und Zertifikat wahrscheinlich ok.

connection closed: Error: XXXXXXXXXXXXXXXX:error:0A000119:SSL routines:tls_get_more_records:decryption failed or bad record mac:../deps/openssl/openssl/ssl/record/methods/tls_common.c:802:

bedeutet in etwa: Integritätsprüfung (MAC) fehlgeschlagen und die Nachricht deshalb nicht mehr entschlüsselt werden konnte.

ich vermute eher, dass der Fehler aus OpenSSL stammt.
Es wurden auf einer bestehenden TLS-Verbindung Daten empfangen, die nicht mehr zur TLS-Session bzw. zur aktuellen Verschlüsselung passen.
Es ist kein typischer Zertifikatsfehler.

Ob die Ursache dann Hyper, Broker, Node.js/OpenSSL oder irgendwo im Netzwerk (Verbindung bitte überprüfen) liegt?

Falls der Broker der mqtt-Adapter ist, würde ich testweise einen anderen MQTT-Broker einsetzen. So könnte der MQTT-Adapter als Fehlerquelle ausgeschlossen oder bestätigt werden.

Als wahrscheinlichste Ursachen bleiben im Wesentlichen:
Hyper-Firmware
ioBroker MQTT-Adapter (Node.js/OpenSSL)
Netzwerk/WLAN zwischen beiden

Community Forum

NEWS

Test Adapter Zendure Solarflow

Support us

594

33.0k

83.2k

1.3m