Test Adapter Zendure Solarflow

Murphy 0

Dann schau dir mal hier das Skript von lesiflo an.
https://forum.iobroker.net/post/1326172

nograx

@Bernd1967 Adapter ist mit der 4.0.6 angepasst. Magst du mal testen?

memme

welchen modus muss man in der app wählen ?
gibt es irgendwo eine anleitung, die aktuell ist, wie man den adapter und die app einstellt?

Bernd1967

@nograx sagte:

@Bernd1967 Adapter ist mit der 4.0.6 angepasst. Magst du mal testen?

Sieht gut aus, Gerät wird erkannt und Datenpunkte werden angelegt.
Hab aber im Moment nicht viel Zeit zum testen.

Bei "batcur" in "packData" wird ein zu hoher Wert angezeigt z.B. : 6552A
Ich denke da fehlt die Umrechnung val - 65536 bevor durch 10 geteilt wird.

MP_Trixi

@nograx
Hi, ich bin jetzt auch stolzer Besitzer eines Solarflow 800 Pro 2 (auch wenn es bis dahin eine kleine Odysse war :)). Vorab habe ich mich natürlich informiert, welches Gerät mit ioBroker zusammen arbeiten kann und bin auf den Adapter gestossen (hier mal ein Danke dafür, tolle Arbeit die ihr alle leistet). Installiert ist die Version 4.0.6
Nun möchte ich mein Gerät natürlich auch steuern (die lesenden Werte werden aktualisiert, ein paar bleiben auf (null) stehen, denke mal die gibt es für das Modell nicht). Bevor ich ein Skript bastle wollte ich die Werte mal von Hand anpassen. Plan wäre das über "control->setOutputLimit" zu machen. Wenn ich das aber versuche bekomme ich den Fehler:

zendure-solarflow.0 2026-06-10 15:16:02.253 warn Operation mode (autoModel) is not set to '0', we can't set the output limit!

nach Adapterstart war nur zendure-solarflow.0.xyz.abc.control.acMode auf "AC output mode (2)" gesetzt. ...autoModel stand auf (null). Wenn ich das auf Nothing (0) setzen will kommt:

zendure-solarflow.0 2026-06-10 15:18:07.137 warn [setAutoModel] Can't set autoModel to a value other than 0 when using zenSDK!

Es steht dann "Nothing (0)" als unbestätigter Wert drin.

Setze ich umgekehrt in der Zendure App die Ausgangsleistung auf einen anderen Wert, kommt dieser im Adapter an (sowohl bei outpuLimit als auch bei control.setOutputLimit).

Was mache ich falsch? Danke für die Hilfe.

Da der 800 Pro 2 wohl recht neu drin ist kann ich auch gerne Testen. batcur in packData haben bei mir ebenfalls die hohen Werte.

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.

Community Forum

NEWS

Test Adapter Zendure Solarflow

Support us

563

33.0k

83.2k

1.3m