Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[maxclaudi]

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

@maxclaudi
Zur -1, wenn der Zendure das mal selber gemacht hat steht im Set auch gerne mal eine 1 bei mir, warum auch immer.

Ist eigentlich nicht möglich. Zendure oder API ändert den dpSet nicht.

Kann aber auch daran liegen, dass ich dein script oft neu starte, wenn ich mal wieder einen der Akkus durch 'Übertaktung' beim Testen eingefroren habe....

Das wird es sein.
Der Datenpunkt kann nur über Dich bzw. Dein(e) Script(s) geändert werden.

Ich mach mal ein screeny, wenn es mal wieder passiert. Dann können wir beide darüber grübeln, warum das so ist....eigentlich weiss ich nicht präzise, wo es herkommt.

Nicht nötig. Mir ist das mögliche Fehlverhalten bewusst.

Der Datenpunkt wird, wenn nicht schon vorhanden, bei Scriptstart automatisch angelegt und mit "-1" initialisiert.
Existiert der Datenpunkt schon, dann wird er iob-typisch nicht neu erstellt und somit auch nicht bei scriptstart mit "-1" initalisiert.
Wurde nun zuvor eine 1 (oder 0) gesetzt und es kam zu einem vorzeitigem Abbruch des Scripts, dann "könnte" der letzte Wert gesetzt bleiben.
Danke für Dein Feedback.

Update 26.11.2025 12:20h– Neues Script
im Eingangspost.

Bisher:

• Bei Script-Start wird wenn dpSet nicht vorhanden ist: dpSet erstellt und mit -1 initalisiert.
  Wenn schon vorhanden: keine -1 Initialisierung.
• Jeder Wert wird nach SET und aufgerufenem POST auf -1 zurückgesetzt. Unabhängig ob POST erfolgreich war oder nicht.

Neu/zusätzlich:

• Bei Script-Start wird immer mit -1 initalisiert.
• alle dpSet-Werte werden spätestens beim nächsten GET wieder auf -1 gesetzt

Durch Queue sind Race Conditions ausgeschlossen.

Damit ist ein manuelles setzen von "-1" nicht nötig und (war auch) nicht vorgesehen.

[maxclaudi]

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

@maxclaudi

Vielen Dank für das ausführliche oben beschriebene Verhalten von smartMode.

Es gibt wirklich keine konstante wann er umschaltet. Hatte erst mal.4 Tage ohne umschalten und dann kann sein das er 3 mal am tag umschaltet

Die Umschaltung von SmartMode passiert tatsächlich von Cloud UND Firmware.
Das ist nicht ohne weiteres von Zendure zu lösen.
Dafür müsste Firmware angepasst und ausgerollt werden.
SmartMode war/ist für eine bestimmte Zeit der Steuerung für bestimmte Ereignisse gedacht und nicht als stetiger Flag.
Wenn auch von uns so gewünscht.
Macht nichts, solange es so funktioniert und tatsächlich in RAM geschrieben wird.

[JimmyGold]

@maxclaudi
Erstmal vielen Dank für deine Mühen. Habe es gerade mit einem SF2400 AC getestet - sieht gut aus. Mir ist nur aufgefallen, dass beim Datenpunkt "chargeMaxLimit" der Wert durch 10 geteilt wird und als % angegeben wird. Richtig wäre die Anzeige in "W" und ohne Teilung. Es stellt die maximale Ladeleistung in Watt dar. Bei SF2400 AC somit 2400W.

[maxclaudi]

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

@maxclaudi
..Mir ist nur aufgefallen, dass beim Datenpunkt "chargeMaxLimit" der Wert durch 10 geteilt wird und als % angegeben wird. Richtig wäre die Anzeige in "W" und ohne Teilung. Es stellt die maximale Ladeleistung in Watt dar. Bei SF2400 AC somit 2400W.

Danke fürs Feeedback.
Done. Script im Eingangspost aktualisiert. Version: 2025.12.02_09.40h

Wenn Script aktualisiert wird muss vor Start der Datenpunkt:
chargeMaxLimit gelöscht werden.
Alternativ vor Start komplettes Verzeichnis mit allen Datenpunkten löschen.
Sonst existiert der Datenpunkt weiterhin und wird zwar mit dem richtigen Wert aktualisiert, zeigt aber statt Einheit "W" dann weiterhin "%" an.

---

Frage an Alle:
Lässt sich chargeMaxLimit in der App einstellen (mit wieviel Watt maximal geladen werden darf)?

@mabbi und @schimi , ihr habt ja höhere Ausgangsleistungen frei schalten lassen. was steht bei Euch aktuell für ein Wert in der max. Eingangs- bzw. Ladeleistung: chargeMaxLimit?

[Schimi]

2400 W

[Schimi]

ich kann in der App den max wert einstellen... es ändert sich aber nur

inverseMaxPower

edit ah mist.... kommt davon wenn man nicht vernünftig liest.. ;)

Ne, nur die outMaxPower... nicht mit welcher "power" er laden darf....

kurz: chargeMaxLimit, lässt sich nicht in der app ändern

[JimmyGold]

Das ging fix.
Mit dem Befehl:

schaltet der DP um

Ob das eine Auswirkung hat, habe ich noch nicht testen können.

Edit: OK, wenn bei chargeMaxLimit z.B. 1000 eingestellt sind und der Wert für setInputLimit >1000 ist, wird die Ladeleistung auf 1000W beschränkt. Funktioniert also.

[maxclaudi]

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

Das ging fix.
Mit dem Befehl:

schaltet der DP um

Ob das eine Auswirkung hat, habe ich noch nicht testen können.

Edit: OK, wenn bei chargeMaxLimit z.B. 1000 eingestellt sind und der Wert für setInputLimit >1000 ist, wird die Ladeleistung auf 1000W beschränkt. Funktioniert also.

Sehr interessant.

PS:
Mit kleiner log Auswertung , korrekter Syntax und größerem Timeout ist es ok, falls Du (auch andere keys?) testen möchtest.
Timeout von 250 ist extrem kurz im lokalen Netzwerk, das manchmal kleine Latenzen hat.
Dazu WiFi, ESP Zendure (der nicht sofort antwortet) und JavaScript/Node ioB (was auch mal durch andere Skripte verzögert wird).

httpPost(
    "http://xxx.xxx.xxx.xxx/properties/write",
    '{"sn":"H0xxxxxxxxx","properties":{"chargeMaxLimit":1000}}',
    { timeout: 2000, responseType: "text" },
    async (err, response) => {
        if (err) {
            log("HTTP-Error: " + err, "info");
            return;
        }
        log("Response: " + response, "info");
    }
);

[maxclaudi]

Hallo,

könnte bitte jemand Screenshots aller offiziellen MQTT-Verzeichnisse mit Keys/Values bereitstellen?

• Seriennummern bitte entfernen oder unkenntlich machen.
• Bitte die Verzeichnisse select, switch und homeassistant abbilden.

Danke.

[Schimi]

Ich hoffe das hilft dir :-)

[maxclaudi]

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

Ich hoffe das hilft dir :-)

ja, Danke.
bei homeassistant sind nicht 'mehr' oder unterschiedliche topics als bei den anderen?

[Schimi]

@maxclaudi habe zwar nie exakt verglichen, aber für mich sieht es nach den gleichen Daten aus nur anders verarbeitet...

[maxclaudi]

Update 2025.12.13_22.00h (Eingangspost aktualisiert)

• chargeMaxLimit
  Wurde in den control-Bereich aufgenommen.

Damit kann die effektive Ladeleistung (Watt) gezielt begrenzt werden, auch wenn ein höheres inputLimit gesetzt ist.
Evtl. sinnvoll, wenn ein Script aktiv ist, das die Ladeleistung dynamisch über inputLimit regelt, man jedoch kurzfristig oder temporär eine zusätzliche Begrenzung der maximalen Ladeleistung vornehmen möchte.

Denkbar auch zur manuellen Umschaltung, wenn mehr PV-Leistung für priorisierte bzw. kritische Verbraucher benötigt wird.

Auch relevant, falls chargeMaxLimit durch die Cloud oder ein anderes Flag beeinflusst wird und man diesen Wert überwachen, auswerten und bei Bedarf aktiv eingreifen möchte.

Hinweis:
chargeMaxLimit funktioniert, ist aber nicht offiziell dokumentiert.
Nutzung auf eigene Verantwortung. Testen und Überwachen empfohlen.

[Rand]

Sorry für die doofe Frage aber wie benutze ich denn nun das Skript?

Setup ist klar, Zendures eingetragen und so weiter und das Skrippt fragt die Werte auch ab und erzeugt/füllt die DPs

Aber wie setze ich denn nun regelmäßig den SmartMode auf 1? Wenn ich versuche den setSmartModeD Pauf 1 zu setzen (als command) dann bekomme ich "error set 1" in set Result.
Ansonsten könnte ich natpürlich selbst nen http request machen aber das erscheint mir widersprüchlich wenn es ja mit dem Skript gehen soll, das ist ja nicht nur ein Value poller nehme ich an.

Hab gesucht aber in der Anleitung steht nichts, muss also entweder völlig selbsterklärend sein eigentlich oder ich habe es falsch verstanden;)

[maxclaudi]

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

Setuip ist klarm Zendures eingretragen und so weiter und das Skrippt fragt die Werte auch ab und erzeugt/füllt die DPs

Aber wie setze ich denn nun regelmäßig den SmartMode auf 1? Wenn ich versuche den setSmartModeD Pauf 1 zu setzen (als command) dann bekomme ich "error set 1" in set Result.

wenn die Datenpunkte aktualisiert werden und das setzen bei Result immer "error set..." meldet, dann liegt das meist daran, dass die Seriennummer (SN) im Script nicht mit der des zendure Geräts übereinstimmt.
Bitte prüfen

const SN = "EXXXXXXXXXXXXX0";   // Seriennummer

• GET liefert Daten ohne Seriennummer, deshalb siehst du alle Daten.

• POST zum Setzen von Werten benötigt die richtige SN.

Fehler liegt nicht am Script.
Bei funktionierendem GET sind WiFi oder zendure Gerät sehr unwahrscheinlich die Ursache.

[Rand]

Hi,
danke für die schnelle Antwort, das ist es leider nicht. Die Serial steht ja im DP also schwer das falsch zu machen.

Ich werde mal paar Debug logs einfügen und versuchen zu verstehen was Du da tust:)

Und allgemein, nehmen wir mal an das funktioniert irgendwann - das ist ja dann ein Einmal Set (weil der Wert dann ja auf -1 zurückgesetzzt wird).
Brauche ich dann ein zweites Script mit nem Scheduler der alle paar h den DP auf 1 setzt? Oder wie ist das gedacht?

Edit:
Hm ist das vlt doch nicht die Seriennummer?
Res "{"timestamp":1766335344,"messageId":2,"error":"SN does not match","code":401}"

Edit2:
Fehler Layer 8, hab die IPs der beiden Zendures verwechselt. Da ja beide mit zendure.domain rein kommen (weil man den namen nicht per dhcp oder direkt anpassen kann) sieht man das auch nicht gleich :/

Es wäre aber ggf praktisch zu mindestens den Fehler als Error/Warn im Log mit auszugeben :)

[maxclaudi]

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

Hi,
danke für die schnelle Antwort, das ist es leider nicht. Die Serial steht ja im DP also schwer das falsch zu machen.

Wenn die Seriennummer nicht stimmen sollte, würden die Datenpunkte unter der "falschen" Seriennummer angelegt werden.
GET funktioniert dennoch, POST mit nicht korrekter SN nicht.

Und allgemein, nehmen wir mal an das funktioniert irgendwann - das ist ja dann ein Einmal Set (weil der Wert dann ja auf -1 zurückgesetzzt wird).

Die -1 sagt nichts über den aktuellen Wert aus. Sie wird nur gesetzt, damit der DP stets änderbar bleibt. Beschreibung etc. findet man in der Anleitung HIER

Zum Auswerten sind die anderen Datenpunkte zuständig, nicht die set.. DP.

Brauche ich dann ein zweites Script mit nem Scheduler der alle paar h den DP auf 1 setzt? Oder wie ist das gedacht?

Wert überwachen, bei Änderung automatisch steuern.
Beispiel: mit Blockly Beispiel-Bild

[Mabbi]

Moinsen,

heute mal einen Monsterschreck bekommen...
Ich gucke eher zufällig und verträumt nachmittags in meine Überwachung und dachte erstmal, mein script-Steuerung für die Akkus ist kaputt.
Ein Akku lädt mit Maximum obwohl kein PV-Überschuss da war, einer entlädt mit ca 75% maximaler Leistung.
Leichte Panik machte sich breit, das script warf Infos raus, das sich der ladende Akku nicht ansteuern lässt.

Also script gestoppt, rein in den Router, IPs unblocked, Zendure App angeschmissen um HEMS zu aktivieren.
In der App steht so eine komische Nachricht, der Zendure AC2400 (der ladende) würde sich selber kalibrieren.

Was auch das Verhalten des 2. Zendure erklärt. Der erste saugt sich voll auf 100%, egal was man ihm sagt.
Der 2. sieht einen echt hohen Stromverbrauch und ballert raus was gebraucht wird.

Unterm Strich:
Das muss ich in meinem script noch realisieren, dass die einzelnen Zendure sich 1x im Monat an einem guten Tag voll saugen und dann solange entladen bis die auf Min-SOC sind.

Sah auf jedenfall witzig aus....

Fazit: Auch mit MQTT wird man die Grundlogik der Zendure Firmware nicht los.

Bin nur in diesen Modus gelaufen, weil ich seit 3 Wochen die Wallbox auf Prio liegen habe um das EV zu tanken, die Zendure-Akkus wurden einfach nicht mehr voll.

Sollte nun aber wieder besser werden... es gibt seit Donnerstag einen weiteren laufenden String auf dem Dach.

Habe nun 24,8 kwp, mehr gibts auch nicht, weil ich nicht will, dass mein Energieversorger Fernsteuer-Zugriff auf meine PV-Anlage bekommt.

[maxclaudi]

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

Moinsen,

heute mal einen Monsterschreck bekommen...
Ich gucke eher zufällig und verträumt nachmittags in meine Überwachung und dachte erstmal, mein script-Steuerung für die Akkus ist kaputt.
Ein Akku lädt mit Maximum obwohl kein PV-Überschuss da war, einer entlädt mit ca 75% maximaler Leistung.
Leichte Panik machte sich breit, das script warf Infos raus, das sich der ladende Akku nicht ansteuern lässt.

Also script gestoppt, rein in den Router, IPs unblocked, Zendure App angeschmissen um HEMS zu aktivieren.
In der App steht so eine komische Nachricht, der Zendure AC2400 (der ladende) würde sich selber kalibrieren.

Was auch das Verhalten des 2. Zendure erklärt. Der erste saugt sich voll auf 100%, egal was man ihm sagt.
Der 2. sieht einen echt hohen Stromverbrauch und ballert raus was gebraucht wird.

Unterm Strich:
Das muss ich in meinem script noch realisieren, dass die einzelnen Zendure sich 1x im Monat an einem guten Tag voll saugen und dann solange entladen bis die auf Min-SOC sind.....

Fazit: Auch mit MQTT wird man die Grundlogik der Zendure Firmware nicht los.

Guten Morgen @Mabbi
ja, Kalibrierung, SmartMode etc. sind fest als Self-Healing-Logic in der Firmware implementiert.

Eigene Regelung / Kalibrierung

Meine Batterieregelung basiert ausschließlich auf minVol und maxVol.

• Entladeschutz:
  Bei minVol <= 3.0 V einer einzelnen Batterie wird weiteres Entladen verhindert.
  Freigabe erst wieder, wenn alle Batterien minVol >= 3.25 V haben.

• Kalibrierung:
  Ein separates Script lädt 1× monatlich (am 15.) die Batterien vollständig auf.
  Ausgelöst wird dies über einen selbst erstellten DP 100prozentAufladung = 1.

Geladen wird mit 800 W, solange:

• mindestens eine Batterie noch minVol < 3.5 V hat und
• electricLevel < socSet ist.

Abbruch erfolgt automatisch, sobald:

• electricLevel >= socSet oder
• alle Batterien minVol >= 3.5 V haben.

Wichtig:
Damit die eigene Kalibrierung funktioniert, darf der Ladevorgang nicht unterbrochen werden, bis die Batterie(n) vollständig geladen sind (zumindest bei meiner HUB2000-Firmware).

Zusammenspiel der Scripts:

• Hauptsteuerungs-Script arbeitet nur, wenn 100prozentAufladung == 0
• Bei 100prozentAufladung == 1 übernimmt die Kalibrierungslogik.
• Nach Abschluss wird der DP wieder auf 0 gesetzt und die normale Steuerung fortgesetzt.

Der DP 100prozentAufladung kann beliebig durch andere Scripts getriggert werden
(z. B. PV-Überschuss, günstiger Stromtarif etc.).

Bei mir gibt es nur ein Ladegerät (ACE1500) für alle Batterien.
Beim SF2400AC ist das komfortabler und getrennt lösbar.

Im Winter ist die Kalibrierung wichtiger und wird öfters ausgelöst,
im Sommer werden die Batterien ohnehin regelmäßig voll.

Entladen wird bei uns meist vollständig bis minVol <= 3.0 V.

Sollte nun aber wieder besser werden... es gibt seit Donnerstag einen weiteren laufenden String auf dem Dach.

super, ging ja schnell :-)

[maxclaudi]

Guten Morgen :-)

Tipp:
damit man von einer Kalibrierung nicht überrascht wird, kann man diesen Zustand überwachen.
Bei SF2400AC / SF800(pro) lässt sich dafür der Datenpunkt socStatus auswerten.

Unter properties gibt es den DP socStatus:

• Normalbetrieb: socStatus = 0
• Kalibrierung aktiv: socStatus = 1

Wenn Du auf socStatus triggerst, kannst Du dir z. B. eine Benachrichtigung (email etc.) senden lassen und evtl. im eigenen Script währenddessen keine Regelbefehle mehr senden.
Ggf. auch andere Geräte (zweiter SF, Netzbezug, Verbraucher) entsprechend anpassen.

So vermeidet man:

• scheinbar „ignorierte“ Steuerbefehle
• Fehlersuche an der falschen Stelle
• unnötige Panik

Firmware-Kalibrierungen laufen in der Regel hart priorisiert.
Externe Limits (chargeMaxLimit, inputLimit etc.) werden dabei entweder komplett übergangen oder erst nach Abschluss der Kalibrierung wieder berücksichtigt.

Ein Abbruch der Kalibrierung ist daher vermutlich nicht möglich.

Ich selbst kann das nicht weiter testen, da ich kein entsprechendes Gerät habe.
Bei meinem HUB2000 existieren socStatus und chargeMaxLimit leider nicht.