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

[maxclaudi]

@Bernd1967 sagte:

Zum Bypass (properties.pass)
Ich hab dort alle drei Werte, also 0,1,2
Ich vermute folgendes:
pass = 1 Bypass + AC Entladen (wenn in der App überschüssige Energie einspeisen erlaubt)
pass = 2 Nur Bypass

Gut beobachtet und danke für diesen wertvollen Beitrag!

Solches Feedback hilft allen weiter.
Bei der Beschreibung der Datenpunkte habe ich mich an das offizielle zenSDK gehalten.
Dort ist bisher nur Folgendes dokumentiert:

• Attribute: pass
• Type: int
• Access: RO (readonly)
• Range: 0-1
• Description: Pass-through state

Es scheint also, dass die offizielle Doku nicht auf dem aktuellsten Stand der Firmware-Entwicklung ist.
Bitte weiter beobachten.
Wenn Du Dir sicher bist, werde ich die Beschreibung im Namen des Datenpunkts gerne erweitern.

edit 03.05.26:
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.

im Script übernommen:
pass - 0: Bypass Automatic, 1: Bypass OFF, 2: Bypass ON

[Daniel 8]

@maxclaudi sagte:

@Bernd1967 sagte:

Zum Bypass (properties.pass)
Ich hab dort alle drei Werte, also 0,1,2
Ich vermute folgendes:
pass = 1 Bypass + AC Entladen (wenn in der App überschüssige Energie einspeisen erlaubt)
pass = 2 Nur Bypass

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`?

[Daniel 8]

@maxclaudi
Vielen Dank für deine große Mühe der Scripte

• Struktur-Update: Die Verzeichnisse befinden sich nun direkt im Hauptordner:

Ich hoffe mal das ich dann jetzt nicht meine ganzen Scripte neu Anpassen muss, wenn sich eventuell die Datenpunkte verschieben. Ich werde es mal in Ruhe testen

Gibt es denn eine schnelle lösung, das ich meine Blocklys so anpassen kann. Habe festgestellt das die Struktur jetzt ja leider anderst ist.
Ich stellte fest, das ich auch noch meinen ganzen Energieflussadapter dann umprogrammieren muss.

Das bedeutet für mich wieder einige Abende hier

[maxclaudi]

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

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