@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
Warum diese Mindestwerte?
Stabilität.
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..
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.
