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

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

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

---

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

---

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

---

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

---

5. 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")!

[maxclaudi]

@daniel-8

Update 16.10.2025 14:47h

Beschreibung / Anleitung

[Daniel 8]

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

@daniel-8

Update 16.10.2025 14:47h

Beschreibung / Anleitung

Also was ich jetzt testen konnte hat funktioniert.

[Mabbi]

@maxclaudi
Ich konnte aktuell noch nicht das letzte Release testen, bin erst gerade mit der Arbeit fertig geworden.

Habe die letzten Tage Abends noch ein bisschen an meinen scripten rumoptimiert, Steuerpausen verlängert und mit steuerbaren Prioritäten versehen.
Grundsätzlich ist die Reihenfolge Heizen(Klimas), Haus-Akku und dann EV-laden, nun kann ich aber bei Bedarf jedes der Systeme priorisieren,
wobei der Haus-Akku dann trotzdem solange lädt wie die Startbedingungen für Heizen oder EV-Laden noch nicht erreicht sind bzw sich Überschuss auch greift.

Anbei mal heute in Diagrammen:

Morgens lud der PV-Überschuss in den Akku, gegen 10 Uhr sprang die EG-Hauptklima an, gegen 11:30 Uhr die OG-Hauptklima.
Dann hat meine älteste Tochter gegen 13:30 Uhr mit einer Heißluftfriteuse+Spülmaschine+Herd Aktion alle laufenden Klimas abgewürgt (laufen ja nur bei PV-Überschuss-Einspeisung).
Danach kam heute zum ersten mal die Sonne raus, Klimas waren noch im Cool-Down-Cycle und das EV hat beschlossen zu laden(lila) bis die Sonne wieder hinter Wolken verschwand.

Später dann kamen nach einander beide Klimaanlagen im EG dazu und mit Verzögerung beide im OG, wobei es zu dem Zeitpunkt im EG schon so mollig warm war, dass die Klimas nur noch sporadisch geheizt haben. EV hat in den kurzen Sonnenphasen noch weitere 2 mal geladen.
Grundsätzlich trotz gefühltem Schlechtwetter: Haus warm, ca. 6 KWh zus. im EV und der Haus-Akku von 10% auf 83% (aktuell 4x AB3000X)) geladen im Laufe des Tages.

Insgesamt heute bis jetzt knappe 24,5 KWh aus der PV-Anlage bekommen, davon 20,85 KWh selber genutzt und seit heute morgen die Sonne aufging 1,2 KWh Netzbezug gehabt.

Fazit: Die nun längeren Steuerzeiten am Zendure machen im Stromverbrauch kaum einen statistischen bzw. finanziellen Unterschied, ich hoffe, dass dadurch der Zendure Wechselrichter evtl. etwas länger hält.

[Mabbi]

Völlig vergessen, ich habe noch eine Frage an @maxclaudi :

Mein 2. Zendure AC2400 kommt die nächsten Tage an.
Taugt Dein Script um anhand vorhandener Datenpunkte und einer abweichenden IP 2+ Geräte zu verwalten (ich werde wahrscheinlich noch einen 3. irgendwann im Frühjahr kommendes Jahr kaufen, damit ich 7.2 KW In/Out realisieren kann, und JA, ich habe 3 einzeln abgesicherte Anschlüsse direkt an jeder Phase in meinem Schaltschrank dafür)

Hier müsste der Objektbaum evtl. um eine Ebene erweitert werden ?
Und dann mit einem 2. mqtt Client sollte das doch gehen oder ?

Falls nein wäre dies ein feature-request