Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro)

maxclaudi

Bisher habe ich nur ein Log von @daniel-8 (SF800Pro) – ohne seine Hilfe und dieses Log hätte es das Script nicht gegeben.
Danke, Daniel!

Mir fehlt noch ein Log eines SF2400AC.

edit: Danke @Mabbi

Mabbi

@maxclaudi
Habe Dir das Ergebnis geschickt.

maxclaudi

@mabbi
Dankeschön
geht nur ums auswerten SF800 (PRO)<>SF2400

maxclaudi

Update 16.10.2025 19:35h
Das aktualisierte Script ist im ersten Post des Threads zu finden.

Neu:

1. Erfolgreiche HTTP-Verbindung und Wert-Setzung werden jetzt ausgewertet
→ Im Result-Datenpunkt erscheint nun eine Rückmeldung:
"ok set <wert>" oder "error set <wert>".

2. Für die Auswertung der aktuellen Zustände
bitte ausschließlich die read-only-Datenpunkte unter properties verwenden.

3. Die Control-Datenpunkte:

setSmartMode
setMqttConnect
setAcMode
setInputLimit
setOutputLimit
setSocSet
setMinSoc
setGridReverse
setGridStandard
setInverseMaxPower
werden jetzt mit -1 initialisiert
und nach jedem Setzen automatisch wieder auf -1 zurückgesetzt.

Jeder gesetzte Wert wird vor der Ausführung auf Gültigkeit überprüft.
Ist der Wert nicht erlaubt, wird die Anfrage verworfen und es erscheint im Log:

Value xxx for id is not allowed

4. Vorübergehende Verbindungsprobleme (WiFi, Netzwerk etc.)
werden nur noch als "info" im Log protokolliert – keine Warnungen mehr.

5. Alle aktuell von Zendure angebotenen Batteriemodelle, einschließlich sämtlicher X-Varianten, werden jetzt automatisch erkannt.

6. Betrieb mehrerer Zendure-Geräte (ein Script pro Gerät)
Dieses Script steuert ein einzelnes Zendure-Gerät.
Bei mehreren Geräten kann für jedes Gerät ein eigenes Script mit individueller Konfiguration verwendet werden:

IP-Adresse
Seriennummer (SN)
MQTT-Daten (Broker, Port, Benutzer, Passwort)
Gerätespezifische Werte: maxInputLimit / maxOutputLimit (abhängig vom Gerätetyp)

Die Standard-Intervalle können beibehalten werden:

intervalGet = 60 s
intervalMqtt = 300 s

Für jedes Script wird das Standard-Verzeichnis automatisch angelegt:
0_userdata.0.zendure.<Seriennummer>
→ Dort befinden sich alle zugehörigen Datenpunkte des jeweiligen Geräts.
→ Es ist keine manuelle Einrichtung erforderlich.

Empfehlung:

Bis zu 3 Geräte: völlig unkritisch
4 Geräte: problemlos möglich
Mehr als 4 Geräte: nicht empfohlen!

Hinweis: Warum -1 bei den Control-Datenpunkten?

Nach jedem Schaltvorgang wird der Wert automatisch wieder auf -1 gesetzt.
Das stellt sicher, dass auch über Blockly oder andere Skripte
derselbe Befehl mehrfach zuverlässig gesendet werden kann –
selbst wenn der vorherige Wert identisch war.

Hintergrund:
In ioBroker kann über Blockly kein ack: false gesetzt werden.
Ohne diesen automatischen Rücksprung auf -1
würde ein identischer Wert nicht erneut übertragen werden.

Der Mechanismus sorgt also für sauberes, wiederholbares Schalten – auch mit Blockly!

Beispiel:
Wenn über HTTP ein Wert auf 1 gesetzt und später über MQTT auf 0 geändert wurde,
würde der Datenpunkt (vom HTTP-zendSDK) noch 1 enthalten –
ein erneutes Senden von 1 wäre dann nicht möglich.
Mit dem -1 -Reset funktioniert das jetzt jederzeit korrekt.

Hinweis für VIS-Benutzer

Ich selbst verwende kein VIS.
VIS-Nutzer können aber einfach den aktuellen Status aus den
properties-(read-only)-Datenpunkten visualisieren.

Zum Steuern und Setzen von Funktionen wie

smartMode (1 = ein / 0 = aus) oder
MQTT aktivieren (1) bzw. deaktivieren (0)

können Buttons angelegt werden.
Dabei wird jeweils ein Button für „Ein“ und einer für „Aus“ benötigt.

Mir sind möglicherweise noch weitere beschreibbare Keys bekannt.
Diese habe ich bewusst nicht ins Script aufgenommen,
da sie ohne Testgerät nicht sicher geprüft werden können.

Warum pro Gerät jeweils ein eigenes Script?

Das ist der einzig saubere und stabile Weg im ioBroker-Kontext.

Vorteile
Isolierte Instanzen

Jedes Script läuft unabhängig.
Keine Race-Conditions oder Variablenkonflikte zwischen Geräten.
Eigene Queue (curlQueue) und eigene Timer für jedes Gerät.

Einfache Wartung

Für jedes Gerät können IP, Seriennummer, Limits usw. separat gesetzt werden – ohne Code-Chaos.
Änderungen oder Tests betreffen nur das jeweilige Gerät.

Sauberes Scheduling

ioBroker regelt das Timing selbst.
Auch wenn mehrere Scripte mit gleichem Intervall laufen (z. B. alle 10 s), entstehen keine Konflikte.

Performance / Ressourcen

Der ioBroker-JS-Adapter (Sandbox-Engine) ist leichtgewichtig.
Solange Queue-Verarbeitung und Timeout-Handling sauber implementiert sind (wie hier), sind selbst 4 Geräte völlig unproblematisch.

Alternative (nur theoretisch)
Ein einziges großes Script mit einer Geräte-Liste (devices = [{SN, IP}, …]) wäre zwar grundsätzlich machbar, aber:

riskant, wenn ein Gerät hängt oder verzögert antwortet
aufwendiger zu debuggen
fehleranfälliger bei Queue-Handling und POST-Timing
insgesamt schwer wartbar und weniger robust

Fazit:
Ein separates Script pro Gerät ist die technisch saubere, stabile und wartungsfreundliche Lösung im ioBroker-Umfeld.

...viel Spaß

maxclaudi

Werde immer wieder privat gefragt, was „besser“ ist:
HTTP oder MQTT?
Deshalb antworte ich hier einmal öffentlich darauf – vielleicht hilft’s ja auch anderen weiter.

Vorweg:
Ich habe das Script für Euch geschrieben.
Ich selbst kann es gar nicht verwenden, weil mein Zendure-Gerät keinen Web-Server hat.
Aber ich helfe gern weiter damit Befehle im RAM landen – und nicht ständig ins Flash geschrieben werden.
Wollte auch einfach mal sehen, was technisch machbar ist,

Nachdem ich mich intensiver mit der zenSDK, den Keys & Values und etlichen Logs (danke an alle, die mir was geschickt haben!) beschäftigt habe,
wurde schnell klar: Da geht richtig was
Selbst den MQTT-Client aktivieren, deaktivieren und konfigurieren.

Der HTTP-Server scheint bei allen Geräten immer aktiv zu sein.
Zu viel MQTT verursacht schlicht mehr Traffic,
während HTTP-Anfragen quasi 0 Belastung bringen.

Wenn ich ein Zendure-Gerät mit HTTP-Webserver hätte,
würde ich mein Script simultan mit MQTT laufen lassen.
Ich würde dabei genau die im Script vorgesehenen Intervalle nutzen:

60 Sekunden für get report / smartMode
300 Sekunden für die MQTT-Überwachung.

Wichtig ist mir auch der Hinweis auf smartMode = 1:
Bitte überwacht das – und nutzt es bei eigener Automatik oder Blockly-Steuerung unbedingt mit!

Viele hatten anfangs Zweifel, ob das wirklich funktioniert oder überhaupt etwas bringt.
Aber ich verweise da ganz offiziell auf die zenSDK von Zendure und Entwickler David:
zenSDK smartMode – Dokumentation

Dort steht eindeutig:
1: The setting parameter is not written to flash.
0: The setting parameter is written to flash.

Selbst bei meinem HUB2000 (09/2024) lässt sich smartMode:1 setzen – und es funktioniert einwandfrei.

Ob Ihr das Script komplett nutzt oder nur teilweise, bleibt natürlich jedem selbst überlassen.
Beim Get Report werden ohnehin alle Werte abgefragt – ob ihr nur smartMode daraus verwendet oder mehr,
macht keinen Unterschied und verursacht auch keinen zusätzlichen Traffic.

Zur eigenen Entscheidungsfindung:

Grundsätzlich: HTTP vs MQTT bei Zendure

Merkmal	HTTP (zenSDK / REST)	MQTT (lokal)
Verbindungstyp	Direkt (Client → Gerät, kein Broker nötig)	Broker-basiert, Gerät <-> ioBroker
Last / Traffic	Nur bei Abruf oder Befehl → minimal	Dauerverbindung, Keepalive, Topics → leicht mehr Traffic
Latenz	Antwort dauert typischerweise 500–3000 ms	Quasi sofort (50–200 ms)
Stabilität	Sehr robust, solange Gerät erreichbar ist	Instabil, wenn Broker oder WLAN wackeln → Gerät schaltet MQTT selbständig aus
Befehlsumfang	Groß (Properties, Steuerbefehle etc.)	(noch?) Eingeschränkt (z. T. nur subset, meist Status und einfache Kommandos)
Einrichtung / Wartung	Kein Setup nötig, immer aktiv	Muss im Gerät aktiviert bleiben – sonst inaktiv oder bei Brokerverlust nach Timeout deaktiviert
Rückmeldung (ACK/State)	Nur auf Anfrage (Polling nötig)	Automatisch per Publish bei jeder Änderung

ioBroker-Betrieb

HTTP (zenSDK)

Vorteile
Immer verfügbar (lokaler Webserver läuft immer).
Alle Befehle nutzbar (auch seltene/komplexe).
Kein Risiko durch MQTT-Abbruch.
Kein zusätzlicher MQTT-Traffic im lokalen Netz.

Nachteile
Kein Echtzeit-Push, man muss pollen (z. B. alle 30–60 s).
Etwas höhere Latenz bei jeder Anfrage (2–3 s).

Fazit: Sehr stabil, vollständige Kontrolle, braucht aber periodisches Polling.

MQTT (lokal)

Vorteile
Schnelle Push-Updates (kein Polling nötig).
Gut, um Zustände automatisch im ioBroker zu aktualisieren.
Einfach lesbar über MQTT-Adapter.

Nachteile
Gerät schaltet MQTT von selbst ab, wenn Broker nicht erreichbar ist → man verliert Verbindung ohne Warnung.
Muss über HTTP oder App reaktiviert werden.
(Noch) weniger Steuerbefehle verfügbar.

Fazit: Ideal als Zustands-Kanal, evtl. nicht als primäre Steuerung.

Kombination
bewährter und stabiler Hybrid-Ansatz:

Aufgabe	Empfohlenes Protokoll
smartMode überwachen / schalten	→ HTTP GET (60s) /POST
Zustände lesen (Status, SOC, Power etc.)	→ MQTT (solange verbunden)
Fallback, wenn MQTT ausfällt	→ HTTP-GET (Polling 300 s)
Befehle senden (z. B. Mode, Limits, AC/DC On/Off)	→ HTTP-POST
MQTT-Status überwachen (aktiv/inaktiv)	→ HTTP-Poll alle 2–5 Min. (prüfen `mqttConnect` DP)

Das ergibt:

minimale Netzlast,
volle Befehlsabdeckung,
automatischen Fallback, falls MQTT aussteigt.

Praxis-Tipp für ioBroker-Skript

Polling-Intervall HTTP: 60s ist perfekt, 30s nur wenn man schnelle Reaktion braucht.
MQTT aktivieren: per HTTP einmalig beim Start oder nach Timeout prüfen (dpSetMqttConnect setzen).
Bei MQTT-Ausfall: automatisch HTTP-only weiterarbeiten.

Fazit

Auswertung	Beschreibung
+ HTTP als Primärsteuerung	Vollständig, robust, kein Verbindungsstress
+ MQTT als Statuskanal	Automatische Statusupdates, schnell
+ Simultan	Ideal: HTTP für Befehle + MQTT für Zustände
- Nur MQTT allein	kann sich abschalten, leicht mehr Traffic
- Nur HTTP (ohne Polling)	Kein Live-Update – Status hinkt hinterher

Daniel 8

@maxclaudi

Habe das neue Script getestet und erhalte folgende error Meldungen

javascript.0	20:17:09.451	error	
ReferenceError: Cannot access 'dpMap' before initialization
javascript.0	20:17:09.452	error	
    at script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set:432:13
javascript.0	20:17:09.452	error	
    at script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set:1627:3```

maxclaudi

@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@maxclaudi

Habe das neue Script getestet und erhalte folgende error Meldungen

javascript.0	20:17:09.451	error	
ReferenceError: Cannot access 'dpMap' before initialization
javascript.0	20:17:09.452	error	
    at script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set:432:13
javascript.0	20:17:09.452	error	
    at script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set:1627:3```

Eingangspost aktualisiert, bitte Rückmeldung.
Jetzt werden alle erhältlichen Batterie-Modelle erkannt die es von Zendure gibt, inkl. alle X Modelle

Daniel 8

@maxclaudi

Bekomme jetzt noch folgende Meldung wenn ich ein Set setzten möchte. Dabei ist es egal welches. Habe outputlimit, SOC min/Max, Smartmode getestet

error	script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: setForeignState: Error: The state property "ack" has the wrong type "object" (should be "boolean")!

maxclaudi

@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@maxclaudi

Bekomme jetzt noch folgende Meldung wenn ich ein Set setzten möchte. Dabei ist es egal welches. Habe outputlimit, SOC min/Max, Smartmode getestet
error	script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: setForeignState: Error: The state property "ack" has the wrong type "object" (should be "boolean")!

typisch iobroker sandbox... bin dran

maxclaudi

@daniel-8
Eingangspost aktualisiert, müsste nun ok sein, bitte Rückmeldung.

Daniel 8

@maxclaudi

Immer noch

script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: setForeignState: Error: The state property "ack" has the wrong type "object" (should be "boolean")!

maxclaudi

@daniel-8
aktualisiert

Danke für das testen und die Rückmeldungen
Kann nur simulieren ohne Gerät

Daniel 8

@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@daniel-8
aktualisiert

Danke für das testen und die Rückmeldungen
Kann nur simulieren ohne Gerät

Selber Fehler. Hat jetzt auch keine Eile. Schaue einfach mal in Ruhe wenn du Zeit hast

maxclaudi

@daniel-8
der Fehler?

script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: setForeignState: Error: The state property "ack" has the wrong type "object" (should be "boolean")!

mit dem letzten script von 2025.10.16 09:25h?

Daniel 8

@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@daniel-8
der Fehler?

script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: setForeignState: Error: The state property "ack" has the wrong type "object" (should be "boolean")!

mit dem letzten script von 2025.10.16 09:25h?

Ja genau. Hab sogar den ganzen Objektbaum gelöscht

maxclaudi

@daniel-8
prüfe ich jetzt noch mal ausführlich und simuliere. ca 20min

maxclaudi

@daniel-8
aktualisiert, bitte testen.

Daniel 8

@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):

@daniel-8
aktualisiert, bitte testen.

Also entweder bin ich zu doof oder es ist noch nicht richtig im Script.
Folgende Meldung

error	
setForeignState: Error: The state property "ack" has the wrong type "object" (should be "boolean")!

maxclaudi

@daniel-8
nein, bist Du nicht. Ruhig Blut. Bitte noch einmal testen: Version 16.10.2025 11:10h.
Sind nur noch Kleinigkeiten.

Daniel 8

@maxclaudi

immer noch das selbe

error	
setForeignState: Error: The state property "ack" has the wrong type "object" (should be "boolean")!

Fehlermeldung	Bedeutung	Typische Ursache
`EHOSTUNREACH`	Host (IP) nicht erreichbar	Gerät offline, WLAN-Repeater gewechselt, Mesh-Roaming, kurzzeitig kein Netz
`ECONNREFUSED`	Verbindung aktiv abgelehnt	Gerät ist erreichbar, Dienst (Port 80) reagiert gerade nicht, z. B. Neustart
`ETIMEDOUT`	Timeout (keine Antwort innerhalb der Zeit)	Gerät zu beschäftigt, schwaches WLAN, Ping funktioniert, HTTP antwortet zu spät
`socket hang up`	Verbindung unerwartet beendet	Gerät hat Verbindung abgebrochen (z. B. keine Antwort innerhalb der Zeit)
`ECONNRESET`	Verbindung vom Zielgerät zurückgesetzt	Meist firmwareseitig, Request nicht vollständig verarbeitet
`ENETUNREACH`	Netzwerkroute nicht erreichbar	Router kurzzeitig ohne Route zur IP (häufig bei WLAN-Mesh während Kanalwechsel)
`EAI_AGAIN`	Temporäres DNS-Problem	DNS-Server antwortet nicht schnell genug
`ENOTFOUND`	Hostname konnte nicht aufgelöst werden	IP ok, aber Name nicht gefunden (z. B. bei Geräten mit mDNS wie `zendure.local`)

NEWS

Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro)

Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro)

Support us

303

32.4k

81.3k

1.3m