Neues YouTube-Video: Visualisierung im Devices-Adapter

[maxclaudi]

@Bernd1967
sorry im meeting.
Firmware aktuell?
Danach oder wenn ja:
To enable the local API, add HEMS and then exit to apply.

Also HEMS aktivieren. etwas warten und danach wieder deaktivieren.

[Bernd1967]

Ja, das hatte ich auch schon gelesen.
Habe HEMS in der App aktiviert und wieder deaktiviert, funktioniert nicht.

[Bernd1967]

Okay, Fehler gefunden, das Mistding hat sich ne neue IP im LAN gegönnt und war deswegen nicht erreichbar.Die Daten trudeln jetzt rein.
Super

[maxclaudi]

@Bernd1967
Freut mich.
Dann bitte nicht vergessen: mindestens über den Router eine dauerhafte, feste IP zuzuweisen

[maxclaudi]

@Daniel-8 sagte:

Habe jetzt mal eine Verweilzeit von 5 sekunden gemacht. Da scheint es zu funktionieren.

Damit meinst Du:

const minTimeBreakForSetDpSec = 5;

oder intervall?

minTimeBreakForSetDpSec ist eigentlich nicht nötig und nur eine Schutzfunktion, falls – wie Du richtig erkannt hast:

Kann es sein wenn der Status noch nicht aktualisert wurde das es dann zum Problem kommt?

oder

• wenn ein script zu schnell commands schreibt
• oder mehrere commands (fast) gleichzeitig feuern
  edit: dann bitte script(e) der Regelung kontrollieren.
• oder das intervall zu groß ist.

Gibt es eigentlich eine Möglichkeit, zu sehen ob in der Warteschlange befehle sind?

Nein, nicht nötig und geht zu schnell.

Bin gerade an einer kompletten Überarbeitung und einem neuen Skript, damit States nicht dauernd so oft geschrieben werden etc. Das geht leider nur schleppend voran, da mir momentan die Zeit fehlt und auch noch die Zeitverschiebung zu meinem Kontakt mit reinspielt.

Edit PPS:
Oder hast Du auf Änderung getriggert und sendest das command erst 5 sek. später?
Falls ja, ist das ein guter Ansatz für einen stabilen Ablauf.
Eventuell könntest du zusätzlich das Intervall noch etwas verkürzen. Das ist jedoch individuell vom Setup abhängig (WLAN-Qualität, Zendure-Geräte etc.).

[Daniel 8]

Ich habe Smartmode auf Änderung getrickert und wenn er auf 0 springt hat er gleich wieder 1 gesetzt. Und da habe ich jetzt ein Timeout mit 5 Sekunden rein gemacht. Seit dem funktioniert es.

[Daniel 8]

Ich habe heute mal angefangen mein ganzes Steuerungsscript umzuschreiben mit deinem Script zur Abfrage. Da ist mir aufgefallen, das im pass Modus der wert nicht 1 sondern 2 ist.

[maxclaudi]

@Daniel-8 sagte:

Ich habe heute mal angefangen mein ganzes Steuerungsscript umzuschreiben mit deinem Script zur Abfrage. Da ist mir aufgefallen, das im pass Modus der wert nicht 1 sondern 2 ist.

Ok, laut Dokumentation sollte es eigentlich nur 0 und 1 geben.

Das Skript schreibt exakt den Wert in den Datenpunkt, der im JSON-Stream unter dem Key pass geliefert wird.

Warum dort eine 2 ankommt, obwohl das SDK nur 0 und 1 vorsieht, ist mir rätselhaft.
Es gibt auch über die Cloud für pass nur 0 (Bypass aus) oder 1 (Bypass aktiv).

Zur Steuerung wird eigentlich ein separater, interner Key verwendet (passMode). Dieser hat die Werte 0 (Automatik), 1 (immer ausgeschaltet) und 2 (immer eingeschaltet).
pass selbst informiert normalerweise nur darüber, ob der Bypass aktiv ist oder nicht.

Bleibt abzuwarten, ob Zendure hier etwas an der API-Struktur ändert oder ob es ein temporärer Fehler im zenSDK-Output ist/war.

[Daniel 8]

Das könnten sie ja dann nur per Firmwareupdate beheben oder? Da warte ich immer bisschen ab welche Probleme da auftauchen.

[Daniel 8]

Ich logge gerade die Variable pass mit. Irgendwie schaltet die so ziemlich oft am Tag. In der früh ist das ja noch ok. Aber ab ca. 10 Uhr hat der Akku eigentlich genug SOC das der Speicher nicht in den Bypass schalten muss. Ich bin mir auch nicht sicher ob der Wirklich schaltet oder das nur ein Anzeigefehler ist. Hat jemand ein ähnliches Verhalten. Ich habe einen 800Pro

0 = Bypass aus
2 = Bypass ein
Die Zahl dazwischen ist nur eine addierte Zahl, das ich sehe wie oft er geschalten hat

[maxclaudi]

@Daniel-8 sagte:

Ich logge gerade die Variable pass mit. Irgendwie schaltet die so ziemlich oft am Tag. In der früh ist das ja noch ok. Aber ab ca. 10 Uhr hat der Akku eigentlich genug SOC das der Speicher nicht in den Bypass schalten muss. Ich bin mir auch nicht sicher ob der Wirklich schaltet oder das nur ein Anzeigefehler ist. Hat jemand ein ähnliches Verhalten. Ich habe einen 800Pro

0 = Bypass aus
2 = Bypass ein
Die Zahl dazwischen ist nur eine addierte Zahl, das ich sehe wie oft er geschalten hat

@Daniel-8, habe dich nicht vergessen, habe nur gerade viel Arbeit.
Nebenher ist ein neues, verbessertes Skript in Arbeit und zu 80 % fertig.

Ich wundere mich sehr, dass dir bei so vielen Aufrufen des Threads bisher niemand geantwortet hat.

Kurz zum Thema:
pass (Info) zeigt bei dir viele Schaltvorgänge des Bypass.
Auffällig ist zudem, dass hier anscheinend der passMode gespiegelt wird. Statt der reinen Info 0/1 siehst du 0/2
(was normalerweise der echte Set Key für den Bypass-Modus passMode wäre).

Das kann aber durchaus so sein und zusätzlich an bestimmten Tagen auftreten.

Der Bypass schaltet am Anfang öfter ein und aus, weil die Batterien bei 100 % SoC nicht sofort dauerhaft stabil auf diesem Wert bleiben.
Das BMS gönnt den Batterien gegen Ende "Ruhephasen",
wodurch sie abkühlen.
Nach der Ladung bzw. in der Ruhephase sinkt die Spannung leicht wieder ab (das nennt man auch Sackspannung).
Dann wird gewartet und der Bypass wieder aufgehoben, damit die Batterien noch einmal „langsam“ nachgeladen werden.
Dies wiederholt sich ein paar Mal, bis die Batterien letzten Endes als wirklich voll gelten.
Das wird von der Firmware und dem BMS anhand diverser Parameter festgestellt – wie z. B. minVol, maxVol oder der Differenz dazwischen (Zelldrift), Temperatur usw.
So bestimmt das BMS den Gesundheitszustand (State of Health) und den echten „Full“-Status.
Dass die Firmware hier bei wechselhafter Bewölkung (fluktuierende PV-Leistung) oder wechselnden Lasten etwas „nervös“ reagiert, ist ein bekanntes Verhalten bei Solar-Firmware-Logiken.

Bei mir funktionierte das mit allen Zendure-Geräten bisher immer zufriedenstellend.

Große Ausnahme war und ist das automatische Abschalten des Bypass.

Deshalb lasse ich den Bypass zwar automatisch einschalten, aber das Ausschalten erledige ich manuell bzw. per Skript.

Dazu nutze ich:

• Astronomischer Sonnenuntergang + Versatz von -x Min.
• Ab dann wird geprüft, ob die PV-Leistung für x Min. unter x Watt liegt.

Wenn ja, setze ich Bypass auf „immer aus“ (passMode: 1). In der Nacht schalte ich dann wieder auf passMode: 0 (Bypass auf Automatik).

Leider ist (zumindest Stand heute, 28.04.2026) das Umschalten des Bypass-Modus im offiziellen zenSDK (noch?) nicht vorgesehen.

Bei der Verwendung eines 1600AC+ stört mich das weniger, da ich selbst entscheide, wann geladen/entladen wird und keine PV-DC-Anschlüsse vorhanden sind.
Aber bei Systemen mit direkten PV-Modul-Anschlüssen ist das natürlich.... nicht ideal.

Jetzt war's mal wieder doch nicht so "kurz zum Thema", sorry.

[Daniel 8]

Vielen Dank für die Infos.
Ja das in der Früh der Bypass öfter hin und her schaltet sehe ich ja noch ein. Aber das er am Mittag hin und her schaltet ist komisch. Weil da der Akku definitiv nicht voll war. Er war gestern auf maximal 66%. Ich bin mir auch nicht sicher ob er wirklich umschaltet. Denn PassMode kann ich ja leider nicht umschalten beim Solarflow 800Pro. Zumindest habe ich noch keine Möglichkeit gefunden

[Daniel 8]

@maxclaudi
"Nebenher ist ein neues, verbessertes Skript in Arbeit und zu 80 % fertig."

Was wird denn verbessert? hat es was mit meinem Smartmode zu tun? Ich hoffe ich muss nicht nochmal alles neu machen für mein Steuerungsscript.

[peschu]

Hallo,

ich habe ein für mich unerklärliches Problem mit dem Script. Alles läuft problemlos und dann kommt eine Fehlermeldung:

javascript.0
2026-04-30 21:35:55.654 info script.js.Scripte.Zendure_Pro_2: Stopping script

javascript.0
2026-04-30 21:35:55.654 error script.js.Scripte.Zendure_Pro_2: Script is calling setState more than 1000 times per minute! Stopping Script now! Please check your script!
Ich habe nur ein kleines Script laufen, was alle 10 Sekunden Setoutputlimit anhand eines Bedarfswertes ändert.

[peschu]

Scheinbar tritt der Fehler alle drei Minuten auf:

[peschu]

Hat sich erledigt. Ich habe diese Erklärung zu den Einstellungen erst im Nachgang gefunden:
-> Instanzen -> javascript-Adapter -> Allgemeine Einstellungen -> "Maximale setState-Anfragen pro Minute pro Skript" auf 5000 erhöhen.

[maxclaudi]

@peschu und @Alle

Bitte auch sicherstellen, dass Zendure-Gerät(e) immer die gleiche IP im Heimnetz zugewiesen bekommen.

Beispiel FRITZ!Box 7590:
Übersicht -> Heimnetz -> Netzwerk -> Netzwerkverbindungen.
Hier Zendure-Gerät(e) ausfindig machen.
Dann auf Stiftsymbol (rechts davon) klicken (bearbeiten).
Oben klicken auf TAB (Reiter) "Heimnetz".

"IPv4-Adresse dauerhaft zuweisen" aktivieren.

Danach "übernehmen" (speichern).

[Bernd1967]

@maxclaudi
Kommt man über zenSDK auch über den selbst vergebenen Namen in der App für das Gerät heran ?

[peschu]

@maxclaudi
Danke für die Erinnerung. Hatte ich glatt vergessen.

[maxclaudi]

Zendure-Geräte Webserver: Steuerung über das zenSDK (HTTP)
2026.05.02_00.39h; update 19.05.26 16:50h BatteryType.
für das ioBroker-Forum
In memory of Daisy 02.05.24 – miss you.

Dieses Skript ermöglicht die lokale Steuerung eines Zendure-Geräts.
Es funktioniert sofort und benötigt keinerlei Keys oder sonstige Authentifizierungen.
Es ist mit APP und Cloud nutzbar.
Oder auch nur lokal, wenn für Gerät(e) der Internetzugang gesperrt wird.
Dann ist jedoch die Verwendung der App per WLAN nicht mehr möglich.
Außerdem sollte eine Möglichkeit geschaffen werden, einen Zeitserver zu erreichen.
Also nur die Zendure spezifischen URL sperren.
Näher möchte ich hier nicht darauf eingehen.

Voraussetzungen:

• Hardware: Zendure-Geräte (Generation 2025/2026) mit integriertem Webserver.

• Aktivierung: Vor der ersten Nutzung muss HEMS einmalig aktiviert, kurz abgewartet und anschließend wieder deaktiviert werden.

• Netzwerk: Die IP-Adresse des Zendure-Geräts muss bekannt sein. Empfehle dringend, dem Gerät im Router oder Access Point eine dauerhafte, feste IP zuzuweisen.

Wichtiger Hinweis zum Flash-Speicher:
Ich bin kein Freund von automatischen Befehlsketten, die für den Nutzer nicht nachvollziehbar sind – vor allem, wenn sie zu unnötigen Schreibvorgängen im Flash-Speicher führen.

Nach aktuellem Stand ist sicher: Wenn smartMode: 1 gesetzt ist, werden zumindest die Werte für outputLimit und inputLimit lediglich in den RAM geschrieben.

Ein Modewechsel (z. B. acMode, Energiepläne, Automodi, MQTT-Konfiguration) wird hingegen fast immer in den Flash-Speicher geschrieben.
Dabei wird oft nicht nur der einzelne Wert, sondern die gesamte Konfiguration dauerhaft gespeichert.

---

Neue Datenpunkte unter "control"
Im aktuellen Skript gibt es zusätzliche Datenpunkte sowie den Ordner automaticKonfig mit zwei Schaltern (Boolean):

1. auto_inputLimitMode (Watt)
   Hier kann ein Wert in Watt für das Ladelimit (inputLimit) gesetzt werden.
   Das Skript prüft daraufhin automatisch:

• Ist acMode: 1 und outputLimit: 0 W gesetzt?

• Falls nicht, wird automatisch acMode: 1 und outputLimit: 0 gesetzt, bevor mit dem gewählten Wert vom Netz geladen wird.

• Ist der Schalter input_output_LimitMode_smartMode_RAM aktiviert, wird vor dem Senden zusätzlich geprüft, ob smartMode: 1 aktiv ist.
  Wenn nicht, wird dieser automatisch mitgesendet.

• Prinzip: Es wird nur gesendet, was zwingend nötig ist (Vorab-Prüfung).

2. auto_outputLimitMode (Watt)
   Dies ist das Gegenstück zum auto_inputLimitMode für die Entladesteuerung.

3. smartModeWatcher (Schalter)
   Wenn dieser Slider aktiviert ist (true), wird bei jedem empfangenen Report automatisch geprüft, ob smartMode: 1 gesetzt ist.
   Sollte der Wert auf 0 stehen, setzt das Skript ihn automatisch wieder auf 1. Dieser Slider kann manuell oder per Skript (de-)aktiviert werden.

Weitere Hinweise

• inverseMaxPower: Dieser Wert sollte nicht zur laufenden Regelung verwendet werden. Er definiert die Obergrenze, die der Wechselrichter maximal ausgeben darf, und wird sehr wahrscheinlich in den Flash geschrieben.

• chargeMaxLimit:
  Mit Vorsicht zu genießen. Diesen Wert am besten nicht für regelmäßige Limit-Anpassungen verwenden.

• Verbraucher-Geräte:
  Vorsicht bei Consumer-Produkten (auch Zendure); hier wird oft bei jeder Parameteränderung die komplette Konfiguration in den Flash geschrieben.

• mDNS: Funktioniert zwar, hat sich in Tests jedoch als unzuverlässig erwiesen. Eine feste IP-Adresse ist die bessere Wahl.

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

• control (inkl. automaticKonfig)

• packData (unter Cxxxxx finden sich die jeweiligen Batteriedaten)

• properties