Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro)
-
edit Warnung(en) weg. Müsste alles funktionieren. Script ist im ersten Eingangs-Post.
-
@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):
edit Warnung(en) weg. Müsste alles funktionieren. Script ist im ersten Eingangs-Post.
at IncomingMessage.<anonymous> (script.js.common.Testphase.@maxclaudi_mit_set:394:29) at IncomingMessage.<anonymous> (script.js.common.Testphase.@maxclaudi_mit_set:444:25) at IncomingMessage.<anonymous> (script.js.common.Testphase.@maxclaudi_mit_set:445:25)die Eine kam 2 mal
-
@daniel-8
Eingangspost code. -
@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):
@daniel-8
Eingangspost code.
keine Fehlerausgabe -
@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):
keine FehlerausgabeDer Code war nie kaputt – nur die Datenpunkte waren beim ersten Start zu langsam.
Jetzt wird erst angelegt und dann abgefragt. Keine Fehlermeldungen mehr, keine Panik – läuft -
@daniel-8
Dankeschön für den Hinweis.Update 07.10.2025 03:25h
Unix-Timestamp jetzt in lesbarer Form verfügbar:- .zendureSmartMode.timestamp
- .zendureMqttState.mqttTimestamp
-
@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):
@daniel-8
Dankeschön für den Hinweis.Update 07.10.2025 03:25h
Unix-Timestamp jetzt in lesbarer Form verfügbar:- .zendureSmartMode.timestamp
- .zendureMqttState.mqttTimestamp
Das hat funtkioniert.
Hatte heute morgen noch einen Fehler vom Script was aber wahrscheinlich in dem Moment war wo irgendwie das System anfangen zu arbeiten hat und schätzungsweise kurz nicht erreichbarscript.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: HTTP GET Fehler: connect EHOSTUNREACH 192.168.177.103:80 -
@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):
@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):
@daniel-8
Dankeschön für den Hinweis.Update 07.10.2025 03:25h
Unix-Timestamp jetzt in lesbarer Form verfügbar:- .zendureSmartMode.timestamp
- .zendureMqttState.mqttTimestamp
Das hat funtkioniert.
Hatte heute morgen noch einen Fehler vom Script was aber wahrscheinlich in dem Moment war wo irgendwie das System anfangen zu arbeiten hat und schätzungsweise kurz nicht erreichbarscript.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: HTTP GET Fehler: connect EHOSTUNREACH 192.168.177.103:80Erklärung zur Logmeldung:
HTTP GET Fehler connect EHOSTUNREACH 192.168.177.103:80Wenn kein weiterer Fehler im Log folgt, war das Zendure-Gerät in diesem Moment einfach nicht erreichbar. Das ist kein Skriptproblem, sondern deutet auf eine kurzzeitige Netzwerkunterbrechung oder interne Blockade des Geräts hin.
Typische Ursachen:
-
WLAN kurz weg oder zu schwach:
Das Gerät hat evtl. den Access Point gewechselt (z. B. in einem Mesh-System), war im Energiesparmodus oder die Verbindung war instabil.
Auch vorübergehende Störungen durch andere Geräte in der Nähe oder überlappende WLAN-Kanäle können kurzzeitig den Zugriff verhindern. -
Gerät war intern beschäftigt:
Während interner Vorgänge wie MQTT/HTTP-Umschaltung, Leistungsänderungen oder interner Tasks reagiert das Gerät evtl. für wenige Sekunden nicht. -
Netzwerkverzögerung oder ARP-Problem:
Der Router hat die IP kurz aus der ARP-Tabelle entfernt, oder DHCP hat intern eine Neuzuweisung vorbereitet. -
Sleep / Neustart:
Gerät war kurz im Standby oder hat einen automatischen Neustart ausgeführt (z. B. nach Konfigurationsänderung).
Wenn nach dieser Meldung keine weiteren Fehler folgen und die nächsten Abfragen wieder funktionieren, ist kein Eingreifen nötig.
Das Gerät war nur kurzzeitig nicht erreichbar und hat sich selbst erholt.
-
Ja das war meine Vermutung. Wird ca. Zu dem Zeitpunkt gewesen sein wo irgendwie pv angefangen hat zu produzieren. Habe ich ja nie behauptet das es ein script Fehler ist. Kamen auch keine weiteren Meldungen
-
@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):
Ja das war meine Vermutung. Wird ca. Zu dem Zeitpunkt gewesen sein wo irgendwie pv angefangen hat zu produzieren.
Bei Dir wurde wenigstens produziert
Bei uns .... naja, ein paar Watt bei dem Wetter
Kamen auch keine weiteren Meldungen
-
@maxclaudi sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):
@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):
Ja das war meine Vermutung. Wird ca. Zu dem Zeitpunkt gewesen sein wo irgendwie pv angefangen hat zu produzieren.
Bei Dir wurde wenigstens produziert
Bei uns .... naja, ein paar Watt bei dem WetterKamen auch keine weiteren Meldungen
Naja die Welt war es nicht. 1,5 kWh. Aber es geht noch schlechter
-
Heute morgen ziemlich um die gleiche Zeit (20 Minuten früher) eine andere Meldung. Ich schätzte da ist wieder der Speicher irgendwie hochgefahren.
error: javascript.0 (32915) script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: HTTP GET Fehler: socket hang up -
@daniel-8 sagte in Zendure SmartMode:1 SolarFlow2400 AC SolarFlow800 ( u. Pro):
Heute morgen ziemlich um die gleiche Zeit (20 Minuten früher) eine andere Meldung. Ich schätzte da ist wieder der Speicher irgendwie hochgefahren.
error: javascript.0 (32915) script.js.common.Garten.Balkonkraftwerke.Zendure_http_Abfrage_Set: HTTP GET Fehler: socket hang upDanke Daniel.
Kurzinfo zum „socket hang up“:
Die Verbindung zum Zendure-Gerät wurde vom Gerät oder vom Netzwerk vorzeitig beendet – völlig normal und unkritisch.Passiert z. B. wenn
- das Gerät kurz nicht erreichbar ist (WLAN-Störung, Interferenzen, Mesh-Wechsel, Sleep-Modus, Reichweite usw.),
- oder die Antwort zu lange dauert und http.request den Socket schließt (z. B. Gerät zu beschäftigt).
Der socket hang up ist kein Scriptfehler, sondern nur ein temporärer Netzwerkzustand.
Das Script läuft ganz normal weiter.
(ja, ich weiß – sagst du auch nicht
, nur als Hinweis für alle.)Im Log steht das als „Fehler“, weil in diesem Moment keine Verbindung zustande kam.
Man könnte das Script so anpassen, dass statt „Fehler“ eine „Warnung“ geloggt wird – das ändert aber nichts daran, dass diese eine Abfrage im Intervall einfach übersprungen wird.Vermutlich liegt die Ursache in einer kleinen WLAN-Reichweiten- oder Interferenzsituation (z. B. andere Geräte auf demselben Kanal).
Solche Situationen kommen auch bei MQTT oder anderen Verbindungen gelegentlich vor – unabhängig davon, ob sie im Log auftauchen oder nicht.
Also alles gut
-
Update 10.10.2025 15:47h
Hier eine Liste typischer Fehlermeldungen, die in der ioBroker-JavaScript-Sandbox bei httpGet oder http.request auftreten können – selbst wenn alles korrekt programmiert ist, aber die Verbindung oder das Gerät Probleme macht.Fehlermeldung Bedeutung Typische Ursache EHOSTUNREACHHost (IP) nicht erreichbar Gerät offline, WLAN-Repeater gewechselt, Mesh-Roaming, kurzzeitig kein Netz ECONNREFUSEDVerbindung aktiv abgelehnt Gerät ist erreichbar, Dienst (Port 80) reagiert gerade nicht, z. B. Neustart ETIMEDOUTTimeout (keine Antwort innerhalb der Zeit) Gerät zu beschäftigt, schwaches WLAN, Ping funktioniert, HTTP antwortet zu spät socket hang upVerbindung unerwartet beendet Gerät hat Verbindung abgebrochen (z. B. keine Antwort innerhalb der Zeit) ECONNRESETVerbindung vom Zielgerät zurückgesetzt Meist firmwareseitig, Request nicht vollständig verarbeitet ENETUNREACHNetzwerkroute nicht erreichbar Router kurzzeitig ohne Route zur IP (häufig bei WLAN-Mesh während Kanalwechsel) EAI_AGAINTemporäres DNS-Problem DNS-Server antwortet nicht schnell genug ENOTFOUNDHostname konnte nicht aufgelöst werden IP ok, aber Name nicht gefunden (z. B. bei Geräten mit mDNS wie zendure.local)Hinweis:
Dies sind harmlose, verbindungsbedingte Fehler. Solche Kommunikationsfehler können auch bei anderen Protokollen (z. B. MQTT) auftreten.Bisher wurden diese Fälle als „Fehler“ im LOG angezeigt, damit man sieht, dass ein Abruf oder Befehl nicht ausgeführt werden konnte. Das Script arbeitet jedoch zuverlässig weiter.
Script-Update:
-
Die üblichen Verdächtigen werden jetzt nicht mehr als „Fehler“, sondern als „Warnung“ ins LOG geschrieben – das hält das LOG sauberer und reduziert Panik.
-
Ein zusätzlicher Datenpunkt SetInverseMaxPower wurde hinzugefügt.
Viel Spaß!
-
-
-
@maxclaudi
Habe Dir das Ergebnis geschickt. -
@mabbi
Dankeschön
geht nur ums auswerten SF800 (PRO)<>SF2400 -
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 allowed4. 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ß
-
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 – DokumentationDort 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 mqttConnectDP)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 -
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```
