Neues YouTube-Video: Visualisierung im Devices-Adapter

[Bernd1967]

@Daniel-8 sagte:

Also ich habe in der App auch überschüssige Energie einspeisen erlaubt aktiviert.
Bei mir kommt aber immer nur pass=2.
Dann dürfte ja pass=1 kommen wenn der Speicher voll ist und die energie ins Haus geht oder`?

Ja, war auch erstmal eine Vermutung von mir.
Ich hatte dann Gestern noch festgestellt das wenn Speicher voll ist und in das Netz eingespeist wird pass=2 ist, also genau wie bei Dir.
Jetzt werde ich mal abwarten wann pass=1 ist.

[Daniel 8]

@maxclaudi sagte:

@Daniel-8
Du kannst dir das Ganze deutlich einfacher machen, ohne alles neu bauen zu müssen:

Nutze Alias-Datenpunkte in ioBroker.

Du legst dir für deine bisher verwendeten (alten) Datenpunkte einfach Aliase an, die auf die neuen Pfade aus dem aktuellen Script zeigen.
Deine Blocklys und Scripte können dann unverändert bleiben.

Prinzip:
Alter Pfad (den deine Blocklys nutzen): bleibt bestehen als Alias
Neuer Pfad (aus dem Script): wird als Ziel hinterlegt

Beispiel (schematisch):
alias.0.<alterPfad>
zeigt auf
0_userdata.0.<neuerPfad>

Dadurch:
Keine Anpassung deiner Blocklys nötig
Energieflussadapter bleibt unverändert
Einmalig Mapping erstellen, danach läuft alles wie vorher

Das spart dir die „mehreren Abende“ .

Künftig wird die Struktur, wie sie jetzt im aktuellen Script (02.05.2026) ist, beibehalten.

Danke. Da muss ich mich mal einlesen und testen

[maxclaudi]

@Bernd1967 @Daniel-8

Da zenSDK per HTTP für pass Werte liefert (0, 1, 2), die über die Cloud (MQTT) so nicht für pass verwendet werden (dort weiterhin 0/1),
wird es eher so sein, dass beim lokalen Webserver vermutlich ein direktes Mapping des internen passMode auf den Read-Only Key pass statt findet.
Die Firmware nutzt die Zustände 1 (fest AUS) und 2 (fest EIN) als Schutzmechanismus gegen zu häufiges Schalten der Relais, während zenSDK dies lediglich als Statuswert spiegelt, ohne Schreibzugriff (über passMode) zu ermöglichen.

[Daniel 8]

Daniel-8 sagte:

@maxclaudi sagte:

@Daniel-8
Du kannst dir das Ganze deutlich einfacher machen, ohne alles neu bauen zu müssen:

Nutze Alias-Datenpunkte in ioBroker.

Du legst dir für deine bisher verwendeten (alten) Datenpunkte einfach Aliase an, die auf die neuen Pfade aus dem aktuellen Script zeigen.
Deine Blocklys und Scripte können dann unverändert bleiben.

Prinzip:
Alter Pfad (den deine Blocklys nutzen): bleibt bestehen als Alias
Neuer Pfad (aus dem Script): wird als Ziel hinterlegt

Beispiel (schematisch):
alias.0.<alterPfad>
zeigt auf
0_userdata.0.<neuerPfad>

Irgendwie komme ich damit nicht klar. Ich weiß nicht wie ich den alten und den neuen Pfad in die alias eintragen kann. Vielleicht gibst du mir ja ne kurze Hilfestellung. Da muss ich ja die Blocklys auch auf die alias.0 Datenpunkte umprogrammieren oder was mache oder denke ich falsch

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