Neues YouTube-Video: Visualisierung im Devices-Adapter

[maxclaudi]

@Daniel-8

Ich verstehe, dass die Umstellung nervig ist, aber ich muss hier um dein Verständnis bitten: Die Entwicklung und Pflege solcher Projekte ist extrem zeitintensiv.
Ich kann neben der Programmierung keinen individuellen Support für ioBroker wie die Alias-Verwaltung leisten.
Das Thema „Alias“ ist ein Standard-Feature von ioBroker, zu dem es hervorragende Anleitungen gibt. Da musst du dich leider selbst einarbeiten, das kann ich dir nicht abnehmen.

Suchbegriffe für Google/YouTube: "ioBroker Alias für Anfänger“ oder "Alias Adapter Anleitung“.

Evtl. auch hilfreich:

organisieren-mit-alias-wie-macht-ihr-das
best-practice-alias-raumstruktur
alias-best-practices-wie-kann-man-es-besser-machen

Ohne ein gewisses Maß an Eigeninitiative bei der Umstellung deiner Struktur wird es leider nicht gehen – egal ob du Aliase nutzt oder die Scripte umschreibst.

Viel Erfolg!

[Daniel 8]

@maxclaudi Vielen Dank für deine Nachricht. Trotzdem danke für das tolle Script. Ich habe es jetzt mit suchen und ersetzen umgestellt

[maxclaudi]

update 05.05.26 14:45h Error-sync.

Ich habe einen kleinen Error-Sync-Fix eingespielt.
Läuft bei euch alles rund?
Mich würde interessieren, ob eure Logs sauber bleiben und wie sich der smartModeWatcher im Alltag schlägt.
Schreibt doch kurz, mit welcher Hardware ihr es nutzt – ein kurzes "Läuft stabil" hilft mir auch schon.
Kurze Timeouts (ca. 2000ms) kommen beim Zendure-Webserver (nicht nur bei kurzem Intervall) ja leider ab und zu vor, aber mein Skript fängt das sauber ab und loggt die Wiederverbindung.

[Daniel 8]

Das mit dem Timeout habe ich auch. Aber meist nur ca. 1 mal am Tag.
Was für Error hattest du denn?
Den Smartmodewatcher habe ich noch nicht getestet

[maxclaudi]

@Daniel-8
Bei mir läuft es bisher stabil.
Nach 48h Dauerstress (5s Intervall):
Bei über 34.000 Abfragen hatte ich lediglich 9 kleine Aussetzer (Timeouts/ECONNRESET).
Das ist bei HTTP und WLAN-Umgebungen völlig normal und wird vom Skript im Hintergrund lautlos abgefangen.

ECONNRESET: bedeutet, dass der Zendure-Webserver die Verbindung abrupt schließt, weil er intern gerade zu beschäftigt ist
(z.B. Cloud-Sync oder interne Verarbeitung). Das liegt nicht am Skript.

Timeout: Bei einem WLAN-Umfeld mit viel Konkurrenz sind 2000ms zwar großzügig, aber Funkstörungen oder Paketverluste lassen sich nie ganz vermeiden.

wichtiger Hinweis:
Sollte ein Steuerungs-Befehl (POST) mal wirklich scheitern, versucht das Skript es 2x erneut.
Klappt es gar nicht, wird der Datenpunkt automatisch auf den echten Ist-Wert des Geräts zurückgesetzt.
So weiß man genau, was wirklich eingestellt ist und man hat keine "toten" Werte in den control dp.
Vorteil: Wert ist aktuell und lässt sich wieder auf den zuvor versuchten Wert ändern.
Das kam bei mir nach 1 Woche bisher nicht vor.

smartModeWatcher ist aktiviert, hatte aber nichts zu tun.
smartMode blieb bis jetzt stabil auf 1.

[Daniel 8]

@maxclaudi

Werde mal bei Gelegenheit das aktuelle Script nochmal einfügen mit deinem Update von gestern und werde berichten.

[Daniel 8]

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)

[maxclaudi]

@Daniel-8 sagte:

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.

[dimaiv]

@maxclaudi
Bei mir läuft dein Script seit Eine Woche schon und nicht mal ein einziges Timeout gehabt.

Danke.

[maxclaudi]

@dimaiv
Danke für die Antwort, freut mich.

[Daniel 8]

@maxclaudi sagte:

@Daniel-8 sagte:

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.

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