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

[maxclaudi]

@Daniel-8 sagte:

Also habe ich das richtig interpretiert, das eine 8 Sekundenabfrage kein Problem darstellt

Richtig.
Es kann auch mit 6 Sek. gefahrlos getestet werden.
Das Skript arbeitet mit einer Warteschlange (Queue). Das heißt, alle Anfragen (Watt lesen oder Werte schreiben) werden nacheinander abgearbeitet. Damit das stabil bleibt, müssen die Intervalle auf die Timeout-Zeit (2 Sek.) abgestimmt sein.
Voraussetzung ist eine gute, stabile und nicht überlastete WLAN-Verbindung.
Evtl. ein extra WLAN mit Access Point (AP) nur für Zendure-Gerät(e).

---

Abfrage-Intervall (GET)

const intervalGet = 8;

Standard (Empfohlen): 8 Sekunden
Technisches Minimum: 5 Sekunden

@Daniel-8 sagte:
und zwischen dem senden immer 5 Sekunden Pause sind?

Richtig.
Man kann zwar theoretisch schneller Befehle im ioBroker auslösen, aber das Skript lässt diese erst nach der eingestellten Pause, der Reihe nach, in die Warteschlange.

Sende-Pause (POST)

const minTimeBreakForSetDpSec = 5;

Standard (Empfohlen): 5 Sekunden
Technisches Minimum: 4 Sekunden

EDIT:
Siehe vorheriges POST.
Pause kann mit Wert: 0 komplett deaktiviert werden.

const minTimeBreakForSetDpSec = 0;

---

Warum diese Mindestwerte?
Stabilität.

1. Die 2x-Timeout-Regel:
   Sobald Du einen Wert sendest (POST), schickt das Skript sofort eine Abfrage (GET) hinterher, um den Status zu aktualisieren.
   Im Fehlerfall (WLAN-Lag) dauert dieser Vorgang bis zu 4 Sekunden (2x 2 Sek. bei 2000ms Timeout). Die Sende-Pause muss also immer länger als diese 4 Sekunden sein, sonst stauen sich die Befehle in der Warteschlange..

2. Abfrage-Puffer:
   Das Abfrage-Intervall (GET) muss deutlich über dem Timeout liegen, damit das Skript Zeit hat, die Warteschlange nach einem Fehler sauber zu leeren.

---

Wichtig: Bei schlechtem WLAN

Wenn das WLAN nicht absolut stabil ist, sollte man die Zeiten nicht verringern, sondern eher erhöhen:

• intervalGet: auf 10–12 Sekunden
• minTimeBreak (Pause): auf 8 Sekunden

Bei schlechtem Empfang laufen Anfragen evtl. oft in den 2-Sekunden-Timeout.
Wenn man dann zu schnell neue Anfragen nachschiebt, "verstopft" die Kommunikation zum Zendure-Gerät komplett und der interne Prozessor (ESP) kommt nicht mehr hinterher.
Könnte evtl. sogar die Kommunikation beenden.
Nur so ist sichergestellt, dass über HTTP alles reibungslos funktioniert.
Mir ist kein Weg bekannt, das auf andere Weise "sicherer" über HTTP zu gewährleisten.

Mit den Standard-Einstellungen funktioniert es im Dauerbetrieb sehr zuverlässig.

[maxclaudi]

Dufte 2 neue Geräte testen.

Herzlichen Dank an die Leihsteller (die nicht genannt werden möchten) für das Vertrauen und den Rabatt beim Übernehmen eines Geräts.

Schade ist nur, dass die gesetzliche EN 18031-Norm bei MQTT/TLS umgesetzt werden musste, was für mich keinen Mehrwert bedeutet.
Das Problem ist die fehlende Flexibilität:
Durch die strikte TLS-Umsetzung (Certificate Pinning) lassen sich die Geräte leider nicht mehr mit einem lokalen MQTT-Broker als Cloud-Ersatz verwenden.

Das herkömmliche 'offizielle, lokale MQTT' ist mit der langsamen Aktualisierung, der anderen Struktur und weniger Möglichkeiten zu reglementiert und für mich leider völlig unbrauchbar.

Hoffe nur, dass das zenSDK nicht weiter eingeschränkt wird.

Noch einmal vielen Dank.

[Daniel 8]

@maxclaudi

Habe gestern mal dein neues Script eingebunden. Irgendwie habe ich ein Problem, das er den Smartmode nicht immer auf 1 schaltet. Ich trigger auf änderung, lasse eine Email senden, das funktioniert immer. Und gleich im Anschluss steure ich auf 1. Kann es sein wenn der Status noch nicht aktualisert wurde das es dann zum Problem kommt? Habe jetzt mal eine Verweilzeit von 5 sekunden gemacht. Da scheint es zu funktionieren.

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

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