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.