NEWS
Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2
-
Habe das neue Script mal getestet. Habe gefühlt mehr Timeouts. Kann aber auch zufall sein.
javascript.0 2026-05-09 18:09:57.999 warn script.js.common.Garten.Balkonkraftwerke.ZenSDK_Zendure_neue_Struktur: GET Fehler (1): timeout of 2000ms exceeded javascript.0 2026-05-09 18:09:57.998 error script.js.common.Garten.Balkonkraftwerke.ZenSDK_Zendure_neue_Struktur: httpGet(url=http://192.168.xxx.xxx/properties/report, error=timeout of 2000ms exceeded)Die beiden Meldungen sind technisch identisch und zeigen nur einen einzigen Fehlversuch an.
Da das Gerät nicht innerhalb von 2 Sekunden geantwortet hat, meldet ioBroker einen Fehler und mein Skript fängt diesen als Warnung ab, um stabil weiterzulaufen.
Das ist bei WLAN-Verbindungen normal und kein Grund zur Sorge, solange danach sofort wieder Daten kommen.Der Webserver vom Zendure-Gerät ist recht schmalbrüstig,
das wissen wir ja.Wenn das WLAN mal kurz hakt, läuft der 2000ms-Timer ab.
Mein Skript akzeptiert das und funktioniert weiterhin beim nächsten Durchgang.Wichtig: bitte nicht 2 Versionen meines Scripts gleichzeitig auf 1 Zendure-Gerät-Webserver laufen lassen.
Danke für Deine Antwort, bitte einfach mal 48h intensiv nutzen und beobachten.
@maxclaudi
Bei mir läuft dein Script seit Eine Woche schon und nicht mal ein einziges Timeout gehabt.Danke.
-
@maxclaudi
Bei mir läuft dein Script seit Eine Woche schon und nicht mal ein einziges Timeout gehabt.Danke.
-
Habe das neue Script mal getestet. Habe gefühlt mehr Timeouts. Kann aber auch zufall sein.
javascript.0 2026-05-09 18:09:57.999 warn script.js.common.Garten.Balkonkraftwerke.ZenSDK_Zendure_neue_Struktur: GET Fehler (1): timeout of 2000ms exceeded javascript.0 2026-05-09 18:09:57.998 error script.js.common.Garten.Balkonkraftwerke.ZenSDK_Zendure_neue_Struktur: httpGet(url=http://192.168.xxx.xxx/properties/report, error=timeout of 2000ms exceeded)Die beiden Meldungen sind technisch identisch und zeigen nur einen einzigen Fehlversuch an.
Da das Gerät nicht innerhalb von 2 Sekunden geantwortet hat, meldet ioBroker einen Fehler und mein Skript fängt diesen als Warnung ab, um stabil weiterzulaufen.
Das ist bei WLAN-Verbindungen normal und kein Grund zur Sorge, solange danach sofort wieder Daten kommen.Der Webserver vom Zendure-Gerät ist recht schmalbrüstig,
das wissen wir ja.Wenn das WLAN mal kurz hakt, läuft der 2000ms-Timer ab.
Mein Skript akzeptiert das und funktioniert weiterhin beim nächsten Durchgang.Wichtig: bitte nicht 2 Versionen meines Scripts gleichzeitig auf 1 Zendure-Gerät-Webserver laufen lassen.
Danke für Deine Antwort, bitte einfach mal 48h intensiv nutzen und beobachten.
Habe das neue Script mal getestet. Habe gefühlt mehr Timeouts. Kann aber auch zufall sein.
javascript.0 2026-05-09 18:09:57.999 warn script.js.common.Garten.Balkonkraftwerke.ZenSDK_Zendure_neue_Struktur: GET Fehler (1): timeout of 2000ms exceeded javascript.0 2026-05-09 18:09:57.998 error script.js.common.Garten.Balkonkraftwerke.ZenSDK_Zendure_neue_Struktur: httpGet(url=http://192.168.xxx.xxx/properties/report, error=timeout of 2000ms exceeded)Die beiden Meldungen sind technisch identisch und zeigen nur einen einzigen Fehlversuch an.
Da das Gerät nicht innerhalb von 2 Sekunden geantwortet hat, meldet ioBroker einen Fehler und mein Skript fängt diesen als Warnung ab, um stabil weiterzulaufen.
Das ist bei WLAN-Verbindungen normal und kein Grund zur Sorge, solange danach sofort wieder Daten kommen.Der Webserver vom Zendure-Gerät ist recht schmalbrüstig,
das wissen wir ja.Wenn das WLAN mal kurz hakt, läuft der 2000ms-Timer ab.
Mein Skript akzeptiert das und funktioniert weiterhin beim nächsten Durchgang.Wichtig: bitte nicht 2 Versionen meines Scripts gleichzeitig auf 1 Zendure-Gerät-Webserver laufen lassen.
Ich habe nur eins am laufen.
Danke für Deine Antwort, bitte einfach mal 48h intensiv nutzen und beobachten.
Hatte heute ziemliche viele Probleme. Sehr viele Meldungen bis hin das ich sogar die Ip Adresse prüfen sollte. Hatte aber auch festgestellt, das ich einen sehr schlechten Rssi Wert von -75 hatte.
Habe dann mal mein Wlan ausgemacht und wieder an und hatte dann gleich eine bessere Datenrate und auch einen veränderten Rssi von -67 in der Fritzbox.
Was mir aber jetzt auf fiel, das der Rssi Wert in den Objekten durch das Script nicht aktualisiert wurde. Da stand immer noch das Datum vom 7.5.2026 dran. Dann habe ich das Script neu gestartet und da hat sich auch der Rssi Wert verändert.
Warum heute so Viele meldungen anstanden kann ich mir noch nicht erklären, da ich eigentlich nichts verändert habe. -
Habe das neue Script mal getestet. Habe gefühlt mehr Timeouts. Kann aber auch zufall sein.
javascript.0 2026-05-09 18:09:57.999 warn script.js.common.Garten.Balkonkraftwerke.ZenSDK_Zendure_neue_Struktur: GET Fehler (1): timeout of 2000ms exceeded javascript.0 2026-05-09 18:09:57.998 error script.js.common.Garten.Balkonkraftwerke.ZenSDK_Zendure_neue_Struktur: httpGet(url=http://192.168.xxx.xxx/properties/report, error=timeout of 2000ms exceeded)Die beiden Meldungen sind technisch identisch und zeigen nur einen einzigen Fehlversuch an.
Da das Gerät nicht innerhalb von 2 Sekunden geantwortet hat, meldet ioBroker einen Fehler und mein Skript fängt diesen als Warnung ab, um stabil weiterzulaufen.
Das ist bei WLAN-Verbindungen normal und kein Grund zur Sorge, solange danach sofort wieder Daten kommen.Der Webserver vom Zendure-Gerät ist recht schmalbrüstig,
das wissen wir ja.Wenn das WLAN mal kurz hakt, läuft der 2000ms-Timer ab.
Mein Skript akzeptiert das und funktioniert weiterhin beim nächsten Durchgang.Wichtig: bitte nicht 2 Versionen meines Scripts gleichzeitig auf 1 Zendure-Gerät-Webserver laufen lassen.
Ich habe nur eins am laufen.
Danke für Deine Antwort, bitte einfach mal 48h intensiv nutzen und beobachten.
Hatte heute ziemliche viele Probleme. Sehr viele Meldungen bis hin das ich sogar die Ip Adresse prüfen sollte. Hatte aber auch festgestellt, das ich einen sehr schlechten Rssi Wert von -75 hatte.
Habe dann mal mein Wlan ausgemacht und wieder an und hatte dann gleich eine bessere Datenrate und auch einen veränderten Rssi von -67 in der Fritzbox.
Was mir aber jetzt auf fiel, das der Rssi Wert in den Objekten durch das Script nicht aktualisiert wurde. Da stand immer noch das Datum vom 7.5.2026 dran. Dann habe ich das Script neu gestartet und da hat sich auch der Rssi Wert verändert.
Warum heute so Viele meldungen anstanden kann ich mir noch nicht erklären, da ich eigentlich nichts verändert habe.@Daniel-8 sagte:
Hatte heute ziemliche viele Probleme. Sehr viele Meldungen bis hin das ich sogar die Ip Adresse prüfen sollte. Hatte aber auch festgestellt, das ich einen sehr schlechten Rssi Wert von -75 hatte.
Habe dann mal mein Wlan ausgemacht und wieder an und hatte dann gleich eine bessere Datenrate und auch einen veränderten Rssi von -67 in der Fritzbox.Das lag oder liegt eindeutig an Deiner WLAN-Verbindung.
Ein RSSI von -75 dBm ist für eine stabile HTTP-Kommunikation grenzwertig.
Dass es nach dem WLAN-Reset auf -67 dBm gesprungen ist, zeigt, dass der Solarflow zuvor keine saubere Verbindung hatte.Was mir aber jetzt auf fiel, das der Rssi Wert in den Objekten durch das Script nicht aktualisiert wurde. Da stand immer noch das Datum vom 7.5.2026 dran.
Das ist kein Fehler, sondern beabsichtigt.
Das Script ist auf maximale Effizienz optimiert:- es fragt im Intervall das JSON mit allen Daten ab.
- Eintreffende Daten werden mit den alten Werten verglichen.
- Nur wenn sich ein Wert (z. B. der RSSI) zum vorherigen Stand unterscheidet, wird er aktualisiert.
- Bleibt der Wert identisch, wird er nicht neu geschrieben. Das schont die Ressourcen deines ioBroker-Systems.
Dann habe ich das Script neu gestartet und da hat sich auch der Rssi Wert verändert.
Korrekt. Bei einem Script-Neustart gibt es noch keine Vergleichswerte im Speicher.
Daher werden beim Start einmalig alle Datenpunkte initial geschrieben.Warum heute so Viele meldungen anstanden kann ich mir noch nicht erklären, da ich eigentlich nichts verändert habe.
Wenn 4x hintereinander kein HTTP GET erfolgreich war
(z. B. wegen Deiner schlechten WLAN-Verbindung), schreibt mein Script zur Diagnose in das LOG:log("Keine Verbindung möglich. Zendure-Geräte IP prüfen!", "error")Das dient nur der Info und weist auf Handlungsbedarf hin.
Das Script selbst läuft weiter und funktioniert auch weiterhin.
Sollte ein GET wieder funktionieren, arbeitet es trotz der vorherigen Meldungen normal weiter.Dass mit dieser Version mehr LOG-Meldungen kommen, ist zur Fehlersuche im Feld beabsichtigt.
In einer künftigen Version werde ich evtl. eine Option einbauen, mit der bestimmte oder alle LOGs abgeschaltet werden können.Bitte versuche, Deine WLAN-Verbindung dauerhaft zu stabilisieren.
Bei einem RSSI von -75 ist der Webserver des Geräts meistens nicht mehr schnell genug erreichbar, was dann zwangsläufig zu Timeouts führt. -
@Daniel-8 sagte:
Hatte heute ziemliche viele Probleme. Sehr viele Meldungen bis hin das ich sogar die Ip Adresse prüfen sollte. Hatte aber auch festgestellt, das ich einen sehr schlechten Rssi Wert von -75 hatte.
Habe dann mal mein Wlan ausgemacht und wieder an und hatte dann gleich eine bessere Datenrate und auch einen veränderten Rssi von -67 in der Fritzbox.Das lag oder liegt eindeutig an Deiner WLAN-Verbindung.
Ein RSSI von -75 dBm ist für eine stabile HTTP-Kommunikation grenzwertig.
Dass es nach dem WLAN-Reset auf -67 dBm gesprungen ist, zeigt, dass der Solarflow zuvor keine saubere Verbindung hatte.Was mir aber jetzt auf fiel, das der Rssi Wert in den Objekten durch das Script nicht aktualisiert wurde. Da stand immer noch das Datum vom 7.5.2026 dran.
Das ist kein Fehler, sondern beabsichtigt.
Das Script ist auf maximale Effizienz optimiert:- es fragt im Intervall das JSON mit allen Daten ab.
- Eintreffende Daten werden mit den alten Werten verglichen.
- Nur wenn sich ein Wert (z. B. der RSSI) zum vorherigen Stand unterscheidet, wird er aktualisiert.
- Bleibt der Wert identisch, wird er nicht neu geschrieben. Das schont die Ressourcen deines ioBroker-Systems.
Dann habe ich das Script neu gestartet und da hat sich auch der Rssi Wert verändert.
Korrekt. Bei einem Script-Neustart gibt es noch keine Vergleichswerte im Speicher.
Daher werden beim Start einmalig alle Datenpunkte initial geschrieben.Warum heute so Viele meldungen anstanden kann ich mir noch nicht erklären, da ich eigentlich nichts verändert habe.
Wenn 4x hintereinander kein HTTP GET erfolgreich war
(z. B. wegen Deiner schlechten WLAN-Verbindung), schreibt mein Script zur Diagnose in das LOG:log("Keine Verbindung möglich. Zendure-Geräte IP prüfen!", "error")Das dient nur der Info und weist auf Handlungsbedarf hin.
Das Script selbst läuft weiter und funktioniert auch weiterhin.
Sollte ein GET wieder funktionieren, arbeitet es trotz der vorherigen Meldungen normal weiter.Dass mit dieser Version mehr LOG-Meldungen kommen, ist zur Fehlersuche im Feld beabsichtigt.
In einer künftigen Version werde ich evtl. eine Option einbauen, mit der bestimmte oder alle LOGs abgeschaltet werden können.Bitte versuche, Deine WLAN-Verbindung dauerhaft zu stabilisieren.
Bei einem RSSI von -75 ist der Webserver des Geräts meistens nicht mehr schnell genug erreichbar, was dann zwangsläufig zu Timeouts führt.Was mir aber jetzt auf fiel, das der Rssi Wert in den Objekten durch das Script nicht aktualisiert wurde. Da stand immer noch das Datum vom 7.5.2026 dran.
Das ist kein Fehler, sondern beabsichtigt.
Das Script ist auf maximale Effizienz optimiert:es fragt im Intervall das JSON mit allen Daten ab.
Eintreffende Daten werden mit den alten Werten verglichen.
Nur wenn sich ein Wert (z. B. der RSSI) zum vorherigen Stand unterscheidet, wird er aktualisiert.
Bleibt der Wert identisch, wird er nicht neu geschrieben. Das schont die Ressourcen deines ioBroker-Systems.Ich habe ja 5 Minuten gewartet und der Wert blieb auf dem alten mit -75 obwohl er laut fritzbox auf -67 war. Nach dem ich dann das Script manuell neu startete stimmte der wert mit der Fritzbox überein.
-
Gerade geschaut. Der Wert steht in der Fritzbox auf -69. In der Systemvariable immer noch auf -67. Erst nach Neustart des Scripts wurde der Wert aktualisiert.
Gerade geschaut. Der Wert steht in der Fritzbox auf -69. In der Systemvariable immer noch auf -67. Erst nach Neustart des Scripts wurde der Wert aktualisiert.
Richtig erkannt, Dankeschön.
Hatte bewusst den stetigen Vergleich speziell nur auf rssi (für mich) deaktiviert.
Wurde mit dem update wieder aktiviert.HINWEIS:
Beim update sind im CONFIG:
timeout: 1500ms, weil es hier seit > 1 Woche stabil läuft.// Timout Handler HTTP GET /POST // Wichtig: // getTimeoutMs < getIntervalMs // postTimeoutMs < getIntervalMs // Bei instabiler Verbindung ggf. erhöhen (z. B. 3000–5000 ms). const getTimeoutMs = 1500; // Empfehlung: 2000 ms. const postTimeoutMs = 1500; // Empfehlung: 2000 ms.@Daniel-8
bitte verwende bei Deinem WLAN-Problem lieber 2000ms oder mehr. -
Wir haben zu danken, das du so etwas auf die Beine stellst.
Ja den timeout werde ich erhöhen.
Ich kann leider nur mit solchen Kleinigkeiten helfen.
-
Wir haben zu danken, das du so etwas auf die Beine stellst.
Ja den timeout werde ich erhöhen.
Ich kann leider nur mit solchen Kleinigkeiten helfen.
Ohne vor allem Dich, anfangs noch @Michi-0 und auch die Rückmeldungen von @Mabbi, wäre das Script nie (so früh) entstanden.
Ein großes Dankeschön an alle, die mit ihren Feedbacks dazu beigetragen haben und vielleicht auch noch beitragen werden.
Ein ganz großes Dankeschön speziell an Dich, @Daniel-8.
Deine Rückmeldungen sind keine „Kleinigkeiten“ – sie sind für alle hilfreich.Mehr Augen sehen einfach mehr als nur meine zwei.
Dankeschön!
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden