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

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

[Mabbi]

Hi,
ich wollte mal alle, die mqtt mit dem Zendure AC 2400 nutzen, informieren:

Ich habe vor 4 Tagen ein Firmware update bei den Zendure AC2400 gemacht.
Seitdem ist mqtt langsam geworden, Aktualisierungraten von bis zu 1 Minute.
Zusätzlich wirft das script von maxclaudi alle paar Minuten ein Econreset plus Warnmeldung raus.
Ich habe testweise im script das setting
const intervalMqtt = 600; // sek MQTT-Status (default: 300 sek, > SmartMode)
auf 600 gesetzt, was die Anzahl der Meldungen deutlich senkt.(Vorher 300)

Kann jemand ähnliches Verhalten bestätgien ?

Als Fix habe ich nun meine scripte erstmal auf die Objekte der api-Version umgebaut(die aktualisieren noch regelmässig).
Hier würde ich aber gerne an dem script etwas ändern.

[Schimi]

habe die 15ner Version und bri mir funktioniert es weiter wie bisher...

oder ich merke nichts.....

sonst resete ihn mal und stell alles neu ein...

[maxclaudi]

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

Ich habe vor 4 Tagen ein Firmware update bei den Zendure AC2400 gemacht.
Seitdem ist mqtt langsam geworden, Aktualisierungraten von bis zu 1 Minute.
Zusätzlich wirft das script von maxclaudi alle paar Minuten ein Econreset plus Warnmeldung raus.
Ich habe testweise im script das setting
const intervalMqtt = 600; // sek MQTT-Status (default: 300 sek, > SmartMode)
auf 600 gesetzt, was die Anzahl der Meldungen deutlich senkt.(Vorher 300)

....

Als Fix habe ich nun meine scripte erstmal auf die Objekte der api-Version umgebaut(die aktualisieren noch regelmässig).
Hier würde ich aber gerne an dem script etwas ändern.

Hi, habe das script erweitert.
Bei Version 2026.01.13_16.05h kann in der Konfiguration gewählt werden:

// MQTT Status zyklisch abfragen? ja: true / nein: false
const mqttStateAsking = true;   // true = zyklische MQTT-Abfrage aktiv, false = deaktiviert

Wenn man das script stoppt und den Wert auf false ändert:

// MQTT Status zyklisch abfragen? ja: true / nein: false
const mqttStateAsking = false;   // true = zyklische MQTT-Abfrage aktiv, false = deaktiviert

dann wird per script keine mqtt-Abfrage mehr durchgeführt. Alles andere funktioniert unabhängig weiter.
Möchte man mqtt-Abfrage wieder nutzen, dann einfach script stoppen, in konfig wieder auf 'true" setzen und script wieder starten.

Die Einstellung / Wert von

const intervalMqtt = 300;               // sek MQTT-Status (default: 300 sek, > SmartMode)

muss beim deaktivieren nicht verändert werden.

Script im Eingangspost aktualisiert.

[maxclaudi]

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

Ich habe vor 4 Tagen ein Firmware update bei den Zendure AC2400 gemacht.
Seitdem ist mqtt langsam geworden, Aktualisierungraten von bis zu 1 Minute.
Zusätzlich wirft das script von maxclaudi alle paar Minuten ein Econreset plus Warnmeldung raus.

ist kein MQTT-Protokollfehler und kein reiner HTTP-Fehler.
Transportproblem (TCP/IP)
Wenn Du per HTTP GET MQTT-Status des 2400AC abfragst
und viele Econresets kommen, dann bricht irgendwo der Socket weg.
MQTT ist extrem empfindlich bei WiFi-Problemen.
http steckt das besser weg.
Würde wie @schimi schrieb die zendure resetten bzw. einmal komplett trennen, stromlos machen und wieder einschalten.
Alle zendure Geräte auf dem gleichen Firmware-Level betreiben .

Denke Du hast ein (zusätzliches, größeres) WiFi-Problem.

---

OT
Habe bei mir auch immer mehr Probleme, dank Nachbarschaft und überfüllten Bändern.
So viel wie möglich auf LAN umgestellt.
Selbst Garagentor macht Probleme. Manchmal hatte ich 0 Empfang und musste aussteigen um das Tor manuell elektrisch zu öffnen/schließen.
Hin und wieder 300-400m kein Problem. Gleichgültig ob 433MHz oder 868MHz. Nun auf FSK umgestellt. Funktioniert jetzt gut. Wahnsinn.
WiFi mit 3 Mesh Points via LAN verbunden. Dennoch immer mal wieder WiFi-Störungen... Aber funktioniert gut.
Repeater möchte ich nicht. Also kabelgebundenes Mesh und damit Stockwerke abgedeckt.

[maxclaudi]

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

Hi,
ich wollte mal alle, die mqtt mit dem Zendure AC 2400 nutzen, informieren:

Ich habe vor 4 Tagen ein Firmware update bei den Zendure AC2400 gemacht.
Seitdem ist mqtt langsam geworden, Aktualisierungraten von bis zu 1 Minute.

nun ist auch klar warum http schneller ist als „offizielles“ lokales MQTT.
Siehe zenSDK Issue #36 mit offizieller Stellungnahme von Zendure:

dav1dBoy Zendure:
....Yes, the ~90-second MQTT reporting interval is intentionally controlled on the device side. The main reason is to avoid overwhelming the system when the device is already busy with core energy-management tasks. Without throttling, excessive reporting could lead to resource contention or unstable behavior.

At the moment, the device is handling quite a few parallel responsibilities, including Zendure HEMS logic and Home Assistant–style local control. These two use cases are similar but not identical, and they compete for limited memory and CPU resources. We are actively planning how to better separate and optimize these business paths in the future, but today memory pressure is still a real constraint.

That’s also why configuration changes (e.g. charging settings) are reflected almost immediately via the local REST API, but not pushed instantly via MQTT. MQTT is treated as a controlled, periodic reporting channel rather than a real-time event stream.

If you decide to poll the local REST API, the device can handle it, but we would recommend keeping the polling interval at 3 seconds or above. Polling faster (e.g. every 1–2 seconds) usually doesn’t provide additional benefit, because internally the device state may not have fully settled or updated yet — so you may just be reading the same data repeatedly while increasing load.
.....