wichtiges UPDATE für controller 7.2.2 im stable

[Murphy 0]

@darkblu
Hast du Solarmodule am Hyper direkt angeschlossen.
Wenn nicht kann ich dir für den Hyper ein Blockly für die Grundfunktion schicken.

[nograx]

@Mr.G68 es gab hier ein Problem auf Zendure Seite, das ist laut meinem Kontakt seit heute Morgen behoben. Kannst du es wohl noch mal probieren?

[darkblu]

@murphy-0 , ja, die PV Module hängen direkt am Hyper

[Bernd1967]

@nograx
Zur Info:
Mein Solarflow 800 Pro 2 taucht jetzt über API Abfrage "devicelist" seit Heute auf mit productId: nVyeqM
In deinem Adapter kommt Fehler:

[onReady] Error creating device with productKey 'nVyeqM' / deviceKey '********' / productModel 'SolarFlow 800 Pro2'

[nograx]

Ich habe es befürchtet, aber das ist ja schon mal ein Fortschritt. Ich bin bis Sonntag noch im Urlaub. Dann binde ich die ID mit ein. Danke für das testen!

[Murphy 0]

@darkblu

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:

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

1. kann ich erst morgen testen
2. 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",
),

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

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

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