Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[Bernd1967]

@maxclaudi
Hab dein Script (Version 2026.04.19_01.15h) jetzt mal mit dem Solarflow 800 Pro 2 getestet (Firmware 1.02) .
Kann ich dieses Script für Windows nehmen ?

Ich erhalte beim Start folgenden Fehler:

GET parse error: SyntaxError: Unexpected token 'N', "Not Found" is not valid JSON

[maxclaudi]

@Bernd1967
sorry im meeting.
Firmware aktuell?
Danach oder wenn ja:
To enable the local API, add HEMS and then exit to apply.

Also HEMS aktivieren. etwas warten und danach wieder deaktivieren.

[Bernd1967]

Ja, das hatte ich auch schon gelesen.
Habe HEMS in der App aktiviert und wieder deaktiviert, funktioniert nicht.

[Bernd1967]

Okay, Fehler gefunden, das Mistding hat sich ne neue IP im LAN gegönnt und war deswegen nicht erreichbar.Die Daten trudeln jetzt rein.
Super

[maxclaudi]

@Bernd1967
Freut mich.
Dann bitte nicht vergessen: mindestens über den Router eine dauerhafte, feste IP zuzuweisen

[maxclaudi]

@Daniel-8 sagte:

Habe jetzt mal eine Verweilzeit von 5 sekunden gemacht. Da scheint es zu funktionieren.

Damit meinst Du:

const minTimeBreakForSetDpSec = 5;

oder intervall?

minTimeBreakForSetDpSec ist eigentlich nicht nötig und nur eine Schutzfunktion, falls – wie Du richtig erkannt hast:

Kann es sein wenn der Status noch nicht aktualisert wurde das es dann zum Problem kommt?

oder

• wenn ein script zu schnell commands schreibt
• oder mehrere commands (fast) gleichzeitig feuern
  edit: dann bitte script(e) der Regelung kontrollieren.
• oder das intervall zu groß ist.

Gibt es eigentlich eine Möglichkeit, zu sehen ob in der Warteschlange befehle sind?

Nein, nicht nötig und geht zu schnell.

Bin gerade an einer kompletten Überarbeitung und einem neuen Skript, damit States nicht dauernd so oft geschrieben werden etc. Das geht leider nur schleppend voran, da mir momentan die Zeit fehlt und auch noch die Zeitverschiebung zu meinem Kontakt mit reinspielt.

Edit PPS:
Oder hast Du auf Änderung getriggert und sendest das command erst 5 sek. später?
Falls ja, ist das ein guter Ansatz für einen stabilen Ablauf.
Eventuell könntest du zusätzlich das Intervall noch etwas verkürzen. Das ist jedoch individuell vom Setup abhängig (WLAN-Qualität, Zendure-Geräte etc.).

[Daniel 8]

Ich habe Smartmode auf Änderung getrickert und wenn er auf 0 springt hat er gleich wieder 1 gesetzt. Und da habe ich jetzt ein Timeout mit 5 Sekunden rein gemacht. Seit dem funktioniert es.

[Daniel 8]

Ich habe heute mal angefangen mein ganzes Steuerungsscript umzuschreiben mit deinem Script zur Abfrage. Da ist mir aufgefallen, das im pass Modus der wert nicht 1 sondern 2 ist.

[maxclaudi]

@Daniel-8 sagte:

Ich habe heute mal angefangen mein ganzes Steuerungsscript umzuschreiben mit deinem Script zur Abfrage. Da ist mir aufgefallen, das im pass Modus der wert nicht 1 sondern 2 ist.

Ok, laut Dokumentation sollte es eigentlich nur 0 und 1 geben.

Das Skript schreibt exakt den Wert in den Datenpunkt, der im JSON-Stream unter dem Key pass geliefert wird.

Warum dort eine 2 ankommt, obwohl das SDK nur 0 und 1 vorsieht, ist mir rätselhaft.
Es gibt auch über die Cloud für pass nur 0 (Bypass aus) oder 1 (Bypass aktiv).

Zur Steuerung wird eigentlich ein separater, interner Key verwendet (passMode). Dieser hat die Werte 0 (Automatik), 1 (immer ausgeschaltet) und 2 (immer eingeschaltet).
pass selbst informiert normalerweise nur darüber, ob der Bypass aktiv ist oder nicht.

Bleibt abzuwarten, ob Zendure hier etwas an der API-Struktur ändert oder ob es ein temporärer Fehler im zenSDK-Output ist/war.

[Daniel 8]

Das könnten sie ja dann nur per Firmwareupdate beheben oder? Da warte ich immer bisschen ab welche Probleme da auftauchen.

[Daniel 8]

Ich logge gerade die Variable pass mit. Irgendwie schaltet die so ziemlich oft am Tag. In der früh ist das ja noch ok. Aber ab ca. 10 Uhr hat der Akku eigentlich genug SOC das der Speicher nicht in den Bypass schalten muss. Ich bin mir auch nicht sicher ob der Wirklich schaltet oder das nur ein Anzeigefehler ist. Hat jemand ein ähnliches Verhalten. Ich habe einen 800Pro

0 = Bypass aus
2 = Bypass ein
Die Zahl dazwischen ist nur eine addierte Zahl, das ich sehe wie oft er geschalten hat

[maxclaudi]

@Daniel-8 sagte:

Ich logge gerade die Variable pass mit. Irgendwie schaltet die so ziemlich oft am Tag. In der früh ist das ja noch ok. Aber ab ca. 10 Uhr hat der Akku eigentlich genug SOC das der Speicher nicht in den Bypass schalten muss. Ich bin mir auch nicht sicher ob der Wirklich schaltet oder das nur ein Anzeigefehler ist. Hat jemand ein ähnliches Verhalten. Ich habe einen 800Pro

0 = Bypass aus
2 = Bypass ein
Die Zahl dazwischen ist nur eine addierte Zahl, das ich sehe wie oft er geschalten hat

@Daniel-8, habe dich nicht vergessen, habe nur gerade viel Arbeit.
Nebenher ist ein neues, verbessertes Skript in Arbeit und zu 80 % fertig.

Ich wundere mich sehr, dass dir bei so vielen Aufrufen des Threads bisher niemand geantwortet hat.

Kurz zum Thema:
pass (Info) zeigt bei dir viele Schaltvorgänge des Bypass.
Auffällig ist zudem, dass hier anscheinend der passMode gespiegelt wird. Statt der reinen Info 0/1 siehst du 0/2
(was normalerweise der echte Set Key für den Bypass-Modus passMode wäre).

Das kann aber durchaus so sein und zusätzlich an bestimmten Tagen auftreten.

Der Bypass schaltet am Anfang öfter ein und aus, weil die Batterien bei 100 % SoC nicht sofort dauerhaft stabil auf diesem Wert bleiben.
Das BMS gönnt den Batterien gegen Ende "Ruhephasen",
wodurch sie abkühlen.
Nach der Ladung bzw. in der Ruhephase sinkt die Spannung leicht wieder ab (das nennt man auch Sackspannung).
Dann wird gewartet und der Bypass wieder aufgehoben, damit die Batterien noch einmal „langsam“ nachgeladen werden.
Dies wiederholt sich ein paar Mal, bis die Batterien letzten Endes als wirklich voll gelten.
Das wird von der Firmware und dem BMS anhand diverser Parameter festgestellt – wie z. B. minVol, maxVol oder der Differenz dazwischen (Zelldrift), Temperatur usw.
So bestimmt das BMS den Gesundheitszustand (State of Health) und den echten „Full“-Status.
Dass die Firmware hier bei wechselhafter Bewölkung (fluktuierende PV-Leistung) oder wechselnden Lasten etwas „nervös“ reagiert, ist ein bekanntes Verhalten bei Solar-Firmware-Logiken.

Bei mir funktionierte das mit allen Zendure-Geräten bisher immer zufriedenstellend.

Große Ausnahme war und ist das automatische Abschalten des Bypass.

Deshalb lasse ich den Bypass zwar automatisch einschalten, aber das Ausschalten erledige ich manuell bzw. per Skript.

Dazu nutze ich:

• Astronomischer Sonnenuntergang + Versatz von -x Min.
• Ab dann wird geprüft, ob die PV-Leistung für x Min. unter x Watt liegt.

Wenn ja, setze ich Bypass auf „immer aus“ (passMode: 1). In der Nacht schalte ich dann wieder auf passMode: 0 (Bypass auf Automatik).

Leider ist (zumindest Stand heute, 28.04.2026) das Umschalten des Bypass-Modus im offiziellen zenSDK (noch?) nicht vorgesehen.

Bei der Verwendung eines 1600AC+ stört mich das weniger, da ich selbst entscheide, wann geladen/entladen wird und keine PV-DC-Anschlüsse vorhanden sind.
Aber bei Systemen mit direkten PV-Modul-Anschlüssen ist das natürlich.... nicht ideal.

Jetzt war's mal wieder doch nicht so "kurz zum Thema", sorry.

[Daniel 8]

Vielen Dank für die Infos.
Ja das in der Früh der Bypass öfter hin und her schaltet sehe ich ja noch ein. Aber das er am Mittag hin und her schaltet ist komisch. Weil da der Akku definitiv nicht voll war. Er war gestern auf maximal 66%. Ich bin mir auch nicht sicher ob er wirklich umschaltet. Denn PassMode kann ich ja leider nicht umschalten beim Solarflow 800Pro. Zumindest habe ich noch keine Möglichkeit gefunden

[Daniel 8]

@maxclaudi
"Nebenher ist ein neues, verbessertes Skript in Arbeit und zu 80 % fertig."

Was wird denn verbessert? hat es was mit meinem Smartmode zu tun? Ich hoffe ich muss nicht nochmal alles neu machen für mein Steuerungsscript.

[peschu]

Hallo,

ich habe ein für mich unerklärliches Problem mit dem Script. Alles läuft problemlos und dann kommt eine Fehlermeldung:

javascript.0
2026-04-30 21:35:55.654 info script.js.Scripte.Zendure_Pro_2: Stopping script

javascript.0
2026-04-30 21:35:55.654 error script.js.Scripte.Zendure_Pro_2: Script is calling setState more than 1000 times per minute! Stopping Script now! Please check your script!
Ich habe nur ein kleines Script laufen, was alle 10 Sekunden Setoutputlimit anhand eines Bedarfswertes ändert.

[peschu]

Scheinbar tritt der Fehler alle drei Minuten auf:

[peschu]

Hat sich erledigt. Ich habe diese Erklärung zu den Einstellungen erst im Nachgang gefunden:
-> Instanzen -> javascript-Adapter -> Allgemeine Einstellungen -> "Maximale setState-Anfragen pro Minute pro Skript" auf 5000 erhöhen.

[maxclaudi]

@peschu und @Alle

Bitte auch sicherstellen, dass Zendure-Gerät(e) immer die gleiche IP im Heimnetz zugewiesen bekommen.

Beispiel FRITZ!Box 7590:
Übersicht -> Heimnetz -> Netzwerk -> Netzwerkverbindungen.
Hier Zendure-Gerät(e) ausfindig machen.
Dann auf Stiftsymbol (rechts davon) klicken (bearbeiten).
Oben klicken auf TAB (Reiter) "Heimnetz".

"IPv4-Adresse dauerhaft zuweisen" aktivieren.

Danach "übernehmen" (speichern).

[Bernd1967]

@maxclaudi
Kommt man über zenSDK auch über den selbst vergebenen Namen in der App für das Gerät heran ?

[peschu]

@maxclaudi
Danke für die Erinnerung. Hatte ich glatt vergessen.