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

[maxclaudi]

@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]

@maxclaudi sagte:

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.

[Daniel 8]

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.

[maxclaudi]

@Daniel-8 sagte:

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.

update 11.05.26 11:00h konfig getTimeoutMs / rssi.

[Daniel 8]

@maxclaudi

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.

[maxclaudi]

@Daniel-8

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!

[Daniel 8]

rssi wird jetzt regelmäßig aktualisiert. Danke

[maxclaudi]

Technischer Hinweis zur Kaskadierung von Speichersystemen:
In der Praxis taucht immer wieder der Wunsch auf, zwei Speichersysteme (z. B. großer Dach-PV-Akku + Zendure) nacheinander zu schalten.
Exemplarisch für dieses Denkmodell steht diese aktuelle Anfrage im Forum:

... Idee war aber eigentlich, dass ich in der App durch den EcoTracker, DANN ERST ins Haus einspeise, wenn der Stromzähler über 300Watt anzeigt.
Dann ist nämlich die grosse Batterie leer und schaltet sich ab.
Quelle

Bevor hier jemand auch so eine Idee umsetzen möchte:

LiFePO4-Zellen degenerieren durch Alterung im Standby (vor allem bei extrem hohen oder niedrigen SoC-Ständen) schneller als durch eine gleichmäßige, schonende Nutzung im optimalen mittleren Fenster.

Ein System künstlich „warten“ zu lassen, schadet der Hardware mehr, als es gut tut.

Wer zwei Systeme besitzt, sollte diese zeitgleich und unabhängig voneinander auf die Grundlast bzw. den aktuellen Hausverbrauch regeln lassen (echter Parallelbetrieb).

Jede künstliche Blockade („Warte bis System A leer ist“) widerspricht der Effizienz und der Physik einer PV-Regelung.

Eine evtl. Option wäre z. B., siehe HIER und HIER

[haselchen]

@maxclaudi

Jeder weiss vermutlich , dass ich gemeint bin
WR, Batterie und PV Wissen ist bei mir nur aus Lesen in den entsprechenden Foren und Erfahrung aus einem BKW vorhanden.
In der ganzen Materie wirst Du tiefer drinstecken.
Beim ganzen PV Thema habe ich gelernt, es gibt kein richtig oder falsch.
Dafür sind die Gegebenheiten in jedem Einzelfall zu speziell.
Beim Deye ist alles , für meine Belange, perfekt eingestellt.
Eventuell habe ich mich mißverständlich ausgedrückt.
Mit "leer" meine ich 30%. Das ist die Grenze für "Notstrom". Und in den Winter/Frühjahrsmonaten ein ganz normaler Wert.
Im Sommer wird die Batterie über Nacht nie auf 30% fallen.
Mein Szenario soll in den besagten Winter/Frühjahrsmonaten greifen.
Das Abschalten des Deye ist auch, entgegen Deiner Aussage, wenn ich das so richtig verstanden habe, unschädlich. In Absprache mit Solarteur und Hersteller.
Der zieht nämlich abends/nachts um die 150Watt für seine "Arbeit".
Um die Batterie vom Zendure mach ich mir keine Sorgen.
Die habe ich zu Testzwecken gekauft.
Um Gedankengänge auszuprobieren.
Viele Schreibvorgänge muss der Speicher gar nicht aushalten.
Eigentlich nur 2.
Wenn über 300 Watt , Batterie anschalten -> wenn bei 10% -> Batterie aus und dann Standby bis Sonne scheint.
Ich wurschtel mich nochmal durch alle Skripte, Informationen und Datenpunkte und sage einen grossen Dank an
Dich , @felli und @nograx für den Gehirnschmalz, den ihr für mein Anliegen aufgebracht habt!

[maxclaudi]

@haselchen
Alles gut, kein Ding! 👍

Der Hinweis war auch überhaupt nicht als persönlicher Angriff gemeint.
Zu Test- und Bastelzwecken kann man natürlich alles ausprobieren – genau dafür ist ein Hobby ja da.

Mir ging es mit dem Post rein um einen Hinweis für stille Mitleser, die so ein Setup nicht
als Hobby, sondern für den produktiven Regelbetrieb planen und sich der elektrochemischen und regelungstechnischen Hintergründe (Stichwort: Alterung im Standby) nicht bewusst sind.

Wenn der große Dach-Akku im Winter auf 30% gehalten wird, um als Notstrompuffer zu dienen, ist das völlig legitim.
Aber genau hier schnappt die Falle zu: Das Zendure-System steht während dieser gesamten Zeit (bis der Hauptakku auf 30% sinkt) ungenutzt bei 100% oder einem hohen SoC-Wert im Standby.
Das ist exakt das, was vermieden werden sollte.
Das Zendure-System altert im Winter primär durch das Herumstehen, nicht durch die Nutzung.

Viel Erfolg beim Tüfteln und Skript-Wurschteln!