Monatsrückblick Juli / August 2026 ist online!

[Daniel 8]

@maxclaudi sagte:

@Daniel-8 sagte:
Also noch schneller per ZenSDk wenn er von der cloud getrennt ist?

Ja, man kann aussuchen, ob man zenSDK verwendet oder reines MQTT. Wobei MQTT zu bevorzugen wäre, weil die Daten sofort und nur wenn nötig automatisch vom Gerät published werden.

Das heißt ich bräuchte dein zenSDK script gar nicht mehr sonder würde wieder alles über den MQTT Broker von iob machen. Wobei du ja geschrieben hast das du nicht weißt ob das funktioniert. Wollte nicht noch zusätzlich was anderes aufbauen.

Die Firmware selbst ist m. M. n. gut genug und reagiert selbstständig auf z. B. kritische Wärme.

Ja das denke ich auch das die Firmwar selbst gut genug ist. Es könnte ja auch mal die Cloud ausfallen und dann müssen die Geräte ja auch reagieren bevor etwas passiert

[maxclaudi]

@Daniel-8 sagte:
Das heißt ich bräuchte dein zenSDK script gar nicht mehr sonder würde wieder alles über den MQTT Broker von iob machen. Wobei du ja geschrieben hast das du nicht weißt ob das funktioniert. Wollte nicht noch zusätzlich was anderes aufbauen.

In dem Fall würde ich das zenSDK-Script zur MQTT-Steuerung anpassen.
Habe ich schon für einen HUB2000.
Einfach konfigurieren, Struktur und Datenpunkte bleiben identisch bzw. werden noch mehr und zusätzlich automatisch neu angelegt.

Triggern statt HTTP GET pollen. Statt POST leicht verändertes JSON erzeugen und an Datenpunkte des MQTT-Adapters übergeben.

PS: Es geht beides.
In meinen Tests läuft zenSDK weiter mit dem 1600AC+

[Daniel 8]

@maxclaudi sagte:

@Daniel-8 sagte:
Das heißt ich bräuchte dein zenSDK script gar nicht mehr sonder würde wieder alles über den MQTT Broker von iob machen. Wobei du ja geschrieben hast das du nicht weißt ob das funktioniert. Wollte nicht noch zusätzlich was anderes aufbauen.

In dem Fall würde ich das zenSDK-Script zur MQTT-Steuerung anpassen.
Habe ich schon für einen HUB2000.
Einfach konfigurieren, Struktur und Datenpunkte bleiben identisch bzw. werden noch mehr und zusätzlich automatisch neu angelegt.

Triggern statt HTTP GET pollen. Statt POST leicht verändertes JSON erzeugen und an Datenpunkte des MQTT-Adapters übergeben.

PS: Es geht beides.
In meinen Tests läuft zenSDK weiter mit dem 1600AC+

Aber beides braucht man ja eigentlich nicht oder gibt es da einen Vorteil?

Kann ich es riskieren mit dem direkten mqtt Adapter vom iobroker den Speicher auf lokal umzustellen?

Aber dafür muss ich mir mal Zeit nehmen. Das geht nicht mehr vor dem Urlaub.

[maxclaudi]

@Daniel-8 sagte:
Aber beides braucht man ja eigentlich nicht...

Richtig, beides benötigt man nicht.

@Daniel-8 sagte:
....oder gibt es da einen Vorteil?

Vorteile mit Cloud-Ersatz-Broker MQTT:

• MQTT ist komfortabler und schneller, weil es dann nicht reglementiert ist, wie das offizielle lokale MQTT. Es bietet viel mächtigere Möglichkeiten. (Was auch eine Gefahr birgt, wenn man nicht weiß, welche Topics beschrieben werden, was sie als Antwort erwarten usw.)

• MQTT ist schneller, weil nicht gepollt werden muss. Wenn Werte sich ändern, wird es automatisch published. Man muss nur Änderungen triggern und nicht alle x Sek. die Werte abfragen.

• WiFi / HTTP(S) wird entlastet. Man bekommt alle wahren Topics und kann Werte setzen, die sonst nicht gesetzt werden können. (Birgt auch eine Gefahr in sich, wenn man wild experimentiert oder Werte setzt, die normaler Weise für Funktionen bestimmt sind, die die Cloud nur im HEMS setzen würde. Am besten man nutzt nur zum Schreiben "properties" wie mit zenSDK.)

Vorteil von zenSDK mit Cloud-Ersatz-Broker:

• Bei der Umstellung erst mal alles bleiben kann wie es ist und läuft dann wirklich lokal.

• Schneller wie bisher, weil es keine Cloud gibt, die permanent irgendwas abfragen, senden oder "dazwischen funken" kann. zenSDK prüft immer wieder, ob die Verbindung zur Cloud besteht. Das ist sie ja – in Form eines lokalen Brokers.

Kann ich es riskieren mit dem direkten mqtt Adapter vom iobroker den Speicher auf lokal umzustellen?

Müsste man erst testen. Ich verwende nur mosquitto. Ausgereift, zuverlässig, schlank, ressourcenarm und schnell..

@Daniel-8 sagte:

Aber dafür muss ich mir mal Zeit nehmen. Das geht nicht mehr vor dem Urlaub.

Schönen Urlaub Deiner Familie und Dir.

[maxclaudi]

@paul53 sagte:

@maxclaudi [sagte]: keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.

Wie kommst du darauf?

maxclaudi sagte:

@paul53 sagte:
Wie kommst du darauf?

tcpdump, wireshark, Analyse, Erfahrung.
Gut, wenn es bei Deiner Firmware nicht so ist.

Das wurde auch vom Zendure-Entwickler David schon früher bestätigt - wenn es nicht mit neuer Firmware verändert wurde -, siehe:
Das Problem liegt nicht am Script, sondern an der Firmware

[paul53]

@maxclaudi sagte:

wenn es nicht mit neuer Firmware verändert wurde

Es sieht danach aus. Log von heute:

2026-08-14 03:41:21.984  - info: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded
2026-08-14 03:41:25.004  - info: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK
2026-08-14 06:20:27.839  - info: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded
2026-08-14 06:20:30.862  - info: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK
2026-08-14 09:04:33.916  - info: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded
2026-08-14 09:04:36.934  - info: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK
2026-08-14 10:55:19.354  - info: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded
2026-08-14 10:55:24.190  - info: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK
2026-08-14 10:55:34.354  - info: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded
2026-08-14 10:55:39.354  - info: javascript.0 (838) script.js.common.Solarflow: GET Fehler (2): timeout of 2000ms exceeded
2026-08-14 10:55:42.398  - info: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK
2026-08-14 10:55:49.355  - info: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded
2026-08-14 10:55:54.355  - info: javascript.0 (838) script.js.common.Solarflow: GET Fehler (2): timeout of 2000ms exceeded
2026-08-14 10:55:57.517  - info: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK
2026-08-14 11:48:39.606  - info: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded
2026-08-14 11:48:42.624  - info: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK

Der SF ist schon seit Wochen vom Internet getrennt. Mein Nachbar funkt zur Zeit auf dem gleichen Kanal wie ich.

Nachtrag: Habe die WLAN-Leistung meines Routers von 25 % auf 100 % erhöht. Dadurch hat der Router meines Nachbarn den Kanal gewechselt. Seitdem kein Timeout-Log.

[maxclaudi]

@paul53 sagte:

@maxclaudi sagte:

wenn es nicht mit neuer Firmware verändert wurde

Es sieht danach aus. Log von heute:....

super, wenn es so ist :-)
Beurteilen kann ich es nicht, weil ich keine Geräte "längere Zeit in die Finger" bekommen habe mit neuestem Update.

Nachtrag: Habe die WLAN-Leistung meines Routers von 25 % auf 100 % erhöht. Dadurch hat der Router meines Nachbarn den Kanal gewechselt. Seitdem kein Timeout-Log.

:-)))

[Daniel 8]

@maxclaudi sagte:

@Daniel-8 sagte:
Aber beides braucht man ja eigentlich nicht...

Richtig, beides benötigt man nicht.

@Daniel-8 sagte:
....oder gibt es da einen Vorteil?

Vorteile mit Cloud-Ersatz-Broker MQTT:

• MQTT ist komfortabler und schneller, weil es dann nicht reglementiert ist, wie das offizielle lokale MQTT. Es bietet viel mächtigere Möglichkeiten. (Was auch eine Gefahr birgt, wenn man nicht weiß, welche Topics beschrieben werden, was sie als Antwort erwarten usw.)

• MQTT ist schneller, weil nicht gepollt werden muss. Wenn Werte sich ändern, wird es automatisch published. Man muss nur Änderungen triggern und nicht alle x Sek. die Werte abfragen.

• WiFi / HTTP(S) wird entlastet. Man bekommt alle wahren Topics und kann Werte setzen, die sonst nicht gesetzt werden können. (Birgt auch eine Gefahr in sich, wenn man wild experimentiert oder Werte setzt, die normaler Weise für Funktionen bestimmt sind, die die Cloud nur im HEMS setzen würde. Am besten man nutzt nur zum Schreiben "properties" wie mit zenSDK.)

Dann sollte ja nichts passieren wenn man nur die properties nutzt. Mehr brauche ich ja sowieso nicht. Eigentlich brauche ich nur die einspeiseleistung und den min soc.

Vorteil von zenSDK mit Cloud-Ersatz-Broker:

• Bei der Umstellung erst mal alles bleiben kann wie es ist und läuft dann wirklich lokal.

• Schneller wie bisher, weil es keine Cloud gibt, die permanent irgendwas abfragen, senden oder "dazwischen funken" kann. zenSDK prüft immer wieder, ob die Verbindung zur Cloud besteht. Das ist sie ja – in Form eines lokalen Brokers.

Kann ich es riskieren mit dem direkten mqtt Adapter vom iobroker den Speicher auf lokal umzustellen?

Müsste man erst testen. Ich verwende nur mosquitto. Ausgereift, zuverlässig, schlank, ressourcenarm und schnell..

Das kann ich ja mal machen. Ich kann ja zur Not mit deinem Programm immer wieder auf die cloud umstellen falls es nicht geht.

@Daniel-8 sagte:

Aber dafür muss ich mir mal Zeit nehmen. Das geht nicht mehr vor dem Urlaub.

Schönen Urlaub Deiner Familie und Dir.

Danke.

[Daniel 8]

@maxclaudi
Bei wieviel volt schaltest du die einspeisung ab? Und wieviel soc ist das ca? Bei mir ist es grad häufig so, das der soc nach dem abschalten bei 8% ca ne halbe Stunde bis stunde später gerne mal um 3-4% nach unten springt und dann aber weiter langsam 1-2% sinkt. Somit habe ich in der früh nur noch ca.3% drinnen. Könnte es auch daran liegen das die Zellen dann kalt werden, weil es ja jetzt abends und nachts bisschen abkühlt und dann die spannung und der soc schlagartig einbricht? Spannung habe ich jetzt nicht beobachtet und geloggt

[maxclaudi]

@Daniel-8 sagte:
Bei wieviel volt schaltest du die einspeisung ab? Und wieviel soc ist das ca?

3.2V ~20 % SoC (Die Batterie neigt sich dem Ende)

Bei mir ist es grad häufig so, das der soc nach dem abschalten bei 8% ca ne halbe Stunde bis stunde später gerne mal um 3-4% nach unten springt und dann aber weiter langsam 1-2% sinkt. Somit habe ich in der früh nur noch ca.3% drinnen.

tpische Zendure Batterien (AB1000/2000) sind 15S1 LiFePO4

• 3,35 V – 3,40 V: ~100 % SoC (Voll)
• 3,28 V: ~50 % SoC (flaches Mittelfeld)
• 3,20 V: ~20 % SoC (Die Batterie neigt sich dem Ende)
• 3,15 V: ~10 % SoC (Die Spannung beginnt spürbar zu sinken)
  weniger Volt sind besser zu vermeiden!
  Weil meine Batterien indoor betrieben werden verwende ich einen Batteriechutz auch mal mit 3.16V Weniger nicht. Outdoor und sicherer ist m. M. minVol 3.2V.

Könnte es auch daran liegen das die Zellen dann kalt werden, weil es ja jetzt abends und nachts bisschen abkühlt ....

Wenn Deine Batterien outdoor sind: Ja.

und dann die spannung und der soc schlagartig einbricht? Spannung habe ich jetzt nicht beobachtet und geloggt

Spannung schlagartig wahrscheinlich nicht.
Dein Einsatzzweck und Ziel ist klar.
Leider ist eine PV-Batterie nicht für standby gedacht und vor allem nicht im entladenen Zustand zusätzlich an einem kalten/kühlen Ort.
Es ist ja noch Sommer.
Ich würde es mit 3.2V ca 20% probieren. minVol und energieLevel loggen.

[Daniel 8]

@maxclaudi sagte:

@Daniel-8 sagte:
Bei wieviel volt schaltest du die einspeisung ab? Und wieviel soc ist das ca?

3.2V ~20 % SoC (Die Batterie neigt sich dem Ende)

Bei mir ist es grad häufig so, das der soc nach dem abschalten bei 8% ca ne halbe Stunde bis stunde später gerne mal um 3-4% nach unten springt und dann aber weiter langsam 1-2% sinkt. Somit habe ich in der früh nur noch ca.3% drinnen.

tpische Zendure Batterien (AB1000/2000) sind 15S1 LiFePO4

• 3,35 V – 3,40 V: ~100 % SoC (Voll)
• 3,28 V: ~50 % SoC (flaches Mittelfeld)
• 3,20 V: ~20 % SoC (Die Batterie neigt sich dem Ende)
• 3,15 V: ~10 % SoC (Die Spannung beginnt spürbar zu sinken)
  weniger Volt sind besser zu vermeiden!
  Weil meine Batterien indoor betrieben werden verwende ich einen Batteriechutz auch mal mit 3.16V Weniger nicht. Outdoor und sicherer ist m. M. minVol 3.2V.

Dann werde ich die 3,2V mal anstreben

Könnte es auch daran liegen das die Zellen dann kalt werden, weil es ja jetzt abends und nachts bisschen abkühlt ....

Wenn Deine Batterien outdoor sind: Ja.

Ja sind sie.

und dann die spannung und der soc schlagartig einbricht? Spannung habe ich jetzt nicht beobachtet und geloggt

Spannung schlagartig wahrscheinlich nicht.
Dein Einsatzzweck und Ziel ist klar.
Leider ist eine PV-Batterie nicht für standby gedacht und vor allem nicht im entladenen Zustand zusätzlich an einem kalten/kühlen Ort.
Es ist ja noch Sommer.
Ich würde es mit 3.2V ca 20% probieren. minVol und energieLevel loggen.

Werde ich mal umsetzen. Also sollte ich sie nicht viel unter 20% entladen.
Im Winter bin ich sowieso weiter oben weil da bekommt man ja die speicher so gut wie nie voll.

[Murphy 0]

@daniel-8

Ich habe letzten Winter sehr gute Erfahrung mit meinem Wintermodus gemacht.

Mein Blockly stoppe das Entladen so lange bis der Akku voll ist. Dann startet Abends das Entladen nach Bedarf bis runter auf 50% oder minVolt <3.20 Volt - je nachdem was zuerst eintritt.

Dann stoppe ich das Entladen und lade wieder so lange bis der Akku wieder voll ist.

Mit meinen 2 kwp Solarmodulen und 3,9 kw Speicher wird der Speicher im Winter 1 bis 2 mal die Woche voll. Im Dez und Jan kann es auch mal fast 2 Wochen dauern.

Wichtig dazu, mein Speicher steht das ganze Jahr im Keller. So passen die Eckwerte für mich perfekt.

[maxclaudi]

zURLtool V 1.0 dch – Lokaler MQTT-Broker für Zendure 2026

Hallo zusammen,das zURLtool V 1.0 dch ist nun fertig!
Ich habe in den letzten Monaten eine eigene Bibliothek sowie eine komfortable grafische Oberfläche (GUI) für Windows entwickelt.

Das Programm ist in seiner Art einzigartig, neu und durch monatelanges Reverse-Engineering, Analysen und intensives Testen entstanden.
Es handelt sich um ein reines Windows-GUI-Programm, das ganz einfach per Doppelklick gestartet wird.
Es verwendet keinen Code von anderen bekannten Projekten (wie dem Solarflow Bluetooth Manager oder dem zendure-cloud-disconnector).

---

Technische Voraussetzungen & Basis:

Das Programm nutzt zur Kommunikation ausschließlich die offiziellen Windows-BT-Treiber ab Windows 11 und die integrierte Bluetooth-Bibliothek bleak:

---

LICENSE NOTICE FOR THE UTILIZED BLUETOOTH LIBRARY

---

This program uses "bleak" for Bluetooth functionality.
https://github.com
Copyright (c) 2020, Henrik Blidh
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND.

---

Die Bibliothek wurde fest in das Programm eingebunden.
Weitere Bibliotheken oder Frameworks müssen auf eurem PC nicht installiert werden.

• Betriebssystem: Windows 11 (64-Bit)
• Hardware: Interner Bluetooth-Chip oder ein standardmäßiger USB-Bluetooth-Stick am Rechner.
• Kompatibilität: Getestet mit Zendure-Geräten bis zur 2400er-Serie (sowohl ältere als auch neueste Generationen / Firmware-Stände).

---

Inhalt des Programmpakets (zURLtool.zip):
Das ZIP-Archiv enthält genau drei Dateien, die zwingend im selben Ordner liegen bleiben müssen:

• zURLtool_GUI.exe (Größe: ca. 11.6 MB / 11.921 KB)
• config.ini (Konfigurationsdatei für eure Zugangsdaten)
• ReadMe_zURLtool.txt (Ausführliche Anleitung in Deutsch & Englisch)

---

Was genau macht das zURLtool?

Das Tool schreibt im Zendure-Gerät die Konfiguration der Broker-URL um.

• Es wird NICHT in die Firmware eingegriffen und es wird nichts modifiziert. Die originale Firmware von Zendure bleibt zu 100 % unangetastet.

• Es werden lediglich die standardmäßigen Bluetooth-Befehle verwendet, die die Firmware von Haus aus für die App bereitstellt.

• Das Skript verhält sich für das Gerät exakt wie die originale App, greift auf die Konfigurations-Variablen im Speicher zu und überschreibt dort die Wi-Fi-Daten und den Eintrag für die Cloud-URL mit der IP eures eigenen lokalen Brokers.

Es funktioniert quasi wie eine zusätzliche Länderauswahl, bei der man sich einfach mit einem anderen Server verbindet.
Das bietet die Firmware von Haus aus an, da die Geräte sonst permanent fest an ganz bestimmte AWS-Server gebunden wären.

Zurück zur Cloud ist auch möglich. Beispiele sind in der config.ini enthalten.

Die Geräte verbinden sich und können beschrieben werden ohne hartes Reset und ohne hartes Trennen von allen Stromquellen.

---

Warum ist das Programm Closed Source?
Zu oft wurden meine Skripte, Codes oder Teile daraus in der Vergangenheit verwendet und/oder modifiziert – ohne Nennung meines Namens, ohne Danksagung / Anerkennung und unter Entfernung meiner originalen Hinweise.

Es wurde u. a. als eigener Erfolg ausgegeben oder kommentiert mit
"ich habe einen Weg gefunden".
Das ist ungerecht.
Monatelange harte Arbeit sollte zumindest anerkannt werden.

Sollte das Programm oder der Code in irgendeiner Form gehackt zur Verfügung gestellt oder verwendet werden, dann war dies mein letzter offizieller Beitrag in Form von Code für die Community.

---

edit/update 16.08.26 Freigabe vereinfacht.
Der Freischalt-Ablauf:

Damit das Programm funktioniert und um anonyme Massen-Weiterreichungen zu unterbinden, benötigt das Programm eine Seriennummer und Freigabe-Code.

1. Sende mir deinen (Foren-) Namen per privater Nachricht (PN) im Forum oder per E-Mail an: ztool.maxclaudi AT gmail . com

2. Du erhältst von mir eine persönliche "Seriennummer" und den dazu passenden "Freigabe-Code"

3. Sichere dir die Seriennummer und den Freigabe-Code unbedingt in einer Textdatei als Backup!
   Falls du die Datei mal verliert, hast du deine Seriennummer und Freigabe-Code als Backup griffbereit.

4. Starte die 'zURLtool_GUI.exe'.
   Trage beide Werte exakt so, wie du sie erhalten hast, in die dafür vorgesehenen Felder im Startfenster ein und klicke auf "Akzeptieren & Starten".
   Nach einmaliger Eingabe startet zURLtool zukünftig vollautomatisch in die Haupt-Oberfläche.
   Als Notfall hast du zusätzlich Seriennummer und Freigabecode als Backup.

---

Vor dem ersten Start muss die config.ini in einem einfachen Text-Editor mit euren echten Daten befüllt werden.

Auswählbare Beispiele und Erklärungen zu den WLAN-Modi sind direkt darin enthalten.

Bilder sagen mehr als Worte, ich denke die Screenshots sind selbsterklärend:

---

WICHTIGER HINWEIS ZU DEN NEUEN GERÄTEN ODER NEUER FIRMWARE (TLS/Port 8883):

Dieses Tool ist ein reines Konfigurations-Werkzeug und schreibt via Bluetooth ausschließlich die WLAN-Daten und die Broker-URL im Gerät um.
Das Tool generiert KEINE TLS-Zertifikate oder Keys!

Um die Bereitstellung der passenden Verschlüsselung auf eurem lokalen MQTT-Broker müsst ihr euch zwingend selbst kümmern.
Wer hierzu Fragen hat: Das Internet und bekannte Foren helfen zu verschlüsselten Mosquitto-Brokern weiter.

Von mir wird es dazu keinen Support und keine Zertifikats-Dateien geben.

Viel Spaß mit dem zURLtool!

---

DOWNLOAD & ENTPACK-ANLEITUNG

Die fertige zURLtool_GUI.exe überschreitet das Foren-Limit von 5 MB.
Deshalb musste ich das Archiv in 3 Teile aufteilen.
Die 3 Teile findet ihr direkt in den nächsten 3 Beiträgen unter diesem Post.

So entpackt ihr das Tool fehlerfrei:

1. Ladet alle 3 Dateien (zURLtool.zip, zURLtool.z01 und zURLtool.z02) in den exakt selben Ordner auf eurem PC herunter.

2. Macht zur eigenen Sicherheit vor dem Start gerne einen Virenscan.

3. Entpackt ausschließlich die Hauptdatei zURLtool.zip

4. Verwendet dazu bitte ein kostenloses Programm wie 7-Zip oder WinRAR
   (der Windows-eigene Entpacker scheitert leider an mehrteiligen ZIP-Archiven).
   Das Entpack-Programm zieht sich die Daten aus den Teilen .z01 und .z02 ganz automatisch dazu.

[maxclaudi]

zURLtool V 1.0 dch – Lokaler MQTT-Broker für Zendure
Erste Teil des Archivs zum Download.

Forum Upload nennt die Datei um.
Bitte kontrollieren.
Sonst Datei umbenennen in:
zURLtool.zip

zURLtool.zip

[maxclaudi]

zURLtool V 1.0 dch – Lokaler MQTT-Broker für Zendure
zweite Teil des Archivs zum Download.

Forum Upload nennt die Datei um.
Bitte kontrollieren.
Sonst Datei umbenennen in:
zURLtool.z01

zURLtool.z01

[maxclaudi]

zURLtool V 1.0 dch – Lokaler MQTT-Broker für Zendure
Dritte und letzte Teil des Archivs zum Download.

Forum Upload nennt die Datei um.
Bitte kontrollieren.
Sonst Datei umbenennen in:
zURLtool.z02

zURLtool.z02

Bitte denkt daran, dass alle 3 Dateien:

• zURLtool.zip
• zURLtool.z01
• zURLtool.z02

in denselben Ordner zu legen, bevor ihr den Entpackvorgang der zURLtool.zip startet.

HINWEIS BEIM ERSTEN START (Windows SmartScreen-Warnung):
Da die zURLtool_GUI.exe von mir privat kompiliert wurde und kein teures, kommerzielles Microsoft-Entwicklerzertifikat besitzt, wird Windows beim ersten Start eine blaue Warnmeldung anzeigen
"Der Computer wurde durch Windows geschützt / Unbekannte App"

Das ist völlig normal bei Privat-Software!
Um das Tool zu starten, klickt in dem blauen Fenster einfach auf den Link „Weitere Informationen“ und danach unten rechts auf den Button „Trotzdem ausführen“.

Danach startet das Tool ganz normal und die Meldung erscheint nie wieder. Macht zur eigenen Sicherheit vorab gerne einen Virenscan!

[Rico Sander]

@maxclaudi
Für Statistik-Fans hier mal eine begonnene Langzeitbeobachtung:

Datum;Zeit;SoC;maxVol;minVol;PV;IN/OUT;Tagesertrag,avgConsumtion;Bemerkung
04.08.2026;18:23;53;3,32;3,31;55;54;1,471;225;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
04.08.2026;20:00;53;3,30;3,30;8;0;1,515;225;Zwangsladung gesperrt, SoC < 80%
04.08.2026;21:00;52;3,30;3,29;0;0;1,518;225;Nachtmodus, Beginn Entladung mit 175 W
05.08.2026;02:06;10;3,18;3,17;0;0;0,000;225;Entladung vorzeitg beendet, SoC <= 10%
05.08.2026;06:04;9;3,20;3,19;0;0;1,000;225;Entladung vorzeitg beendet, SoC <= 10%
05.08.2026;08:00;9;3,20;3,19;24;0;0,015;262;08:00 Uhr: Entladung Ende, Beginn Tagmodus
05.08.2026;08:26;9;3,20;3,19;56;0;0,032;262;PV-Aufladung Start, inputLimit > 0
05.08.2026;18:27;89;3,36;3,34;55;52;2,677;262;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
05.08.2026;20:00;89;3,34;3,33;-1;0;2,708;262;Zwangsladung aktiv und mit 800 W gestartet, SoC > 80%
05.08.2026;20:32;98;3,59;3,45;0;800;2,709;262;Zwangsladung beendet, maxVol >= 3.59V
05.08.2026;20:33;98;3,59;3,44;0;800;2,709;262;Zwangsladung beendet, maxVol >= 3.59V
05.08.2026;20:34;98;3,59;3,44;0;800;2,709;262;Zwangsladung beendet, maxVol >= 3.59V
05.08.2026;21:00;100;3,47;3,37;0;0;2,709;262;Nachtmodus, Beginn Entladung mit 175 W
06.08.2026;07:08;10;3,18;3,16;28;0;0,016;64;Entladung vorzeitg beendet, SoC <= 10%
06.08.2026;08:00;10;3,20;3,19;29;0;0,043;64;08:00 Uhr: Entladung Ende, Beginn Tagmodus
06.08.2026;08:17;10;3,20;3,19;56;50;0,054;64;PV-Aufladung Start, inputLimit > 0
06.08.2026;09:12;12;3,23;3,22;55;55;0,162;64;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
06.08.2026;09:12;12;3,23;3,22;55;55;0,162;64;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
06.08.2026;17:36;89;3,34;3,34;55;56;2,727;64;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
06.08.2026;18:22;90;3,35;3,34;55;54;2,812;64;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
06.08.2026;18:29;90;3,35;3,34;55;55;2,819;64;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
06.08.2026;18:42;91;3,35;3,34;55;56;2,835;64;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
06.08.2026;18:53;91;3,35;3,34;55;54;2,845;64;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
06.08.2026;18:54;91;3,35;3,34;55;54;2,845;64;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
06.08.2026;18:55;91;3,34;3,34;55;53;2,846;64;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
06.08.2026;18:56;91;3,35;3,34;55;53;2,847;64;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
06.08.2026;20:00;91;3,34;3,33;11;0;2,878;64;Zwangsladung aktiv und mit 800 W gestartet, SoC > 80%
06.08.2026;20:41;98;3,59;3,45;0;800;2,882;64;Zwangsladung beendet, maxVol >= 3.59V
06.08.2026;20:42;98;3,59;3,45;0;800;2,882;64;Zwangsladung beendet, maxVol >= 3.59V
06.08.2026;20:43;98;3,59;3,44;0;800;2,882;64;Zwangsladung beendet, maxVol >= 3.59V
06.08.2026;20:44;98;3,59;3,44;0;800;2,882;64;Zwangsladung beendet, maxVol >= 3.59V
06.08.2026;20:44;98;3,60;3,44;0;800;2,882;64;Zwangsladung beendet, maxVol >= 3.59V
06.08.2026;20:44;100;3,59;3,44;0;0;2,882;64;Zwangsladung beendet, maxVol >= 3.59V
06.08.2026;21:00;100;3,50;3,39;0;0;2,882;64;Nachtmodus, Beginn Entladung mit 175 W
07.08.2026;06:59;10;3,17;3,16;14;0;0,012;165;Entladung vorzeitg beendet, SoC <= 10%
07.08.2026;08:00;10;3,20;3,19;25;0;0,032;165;08:00 Uhr: Entladung Ende, Beginn Tagmodus
07.08.2026;08:16;10;3,20;3,19;54;49;0,042;165;PV-Aufladung Start, inputLimit > 0
07.08.2026;08:16;10;3,20;3,19;55;49;0,042;165;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
07.08.2026;17:30;85;3,35;3,34;55;55;2,583;165;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
07.08.2026;17:30;85;3,35;3,34;55;55;2,583;165;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
07.08.2026;20:00;84;3,33;3,33;6;0;2,655;165;Zwangsladung aktiv und mit 800 W gestartet, SoC > 80%
07.08.2026;20:39;98;3,59;3,45;0;800;2,657;165;Zwangsladung beendet, maxVol >= 3.59V
07.08.2026;20:40;98;3,59;3,45;0;800;2,657;165;Zwangsladung beendet, maxVol >= 3.59V
07.08.2026;20:41;98;3,59;3,44;0;800;2,657;165;Zwangsladung beendet, maxVol >= 3.59V
07.08.2026;20:42;98;3,59;3,44;0;800;2,657;165;Zwangsladung beendet, maxVol >= 3.59V
07.08.2026;21:00;100;3,49;3,38;0;0;2,657;165;Nachtmodus, Beginn Entladung mit 175 W
08.08.2026;07:05;10;3,17;3,17;14;0;0,012;71;Entladung vorzeitg beendet, SoC <= 10%
08.08.2026;08:00;10;3,20;3,19;27;0;0,032;71;08:00 Uhr: Entladung Ende, Beginn Tagmodus
08.08.2026;08:15;10;3,20;3,19;57;50;0,041;71;PV-Aufladung Start, inputLimit > 0
08.08.2026;16:41;98;3,59;3,44;305;250;3,256;71;PV-Aufladung vorzeitig beendet, PV noch 305 W
08.08.2026;18:23;100;3,40;3,34;55;0;3,564;71;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
08.08.2026;20:00;99;3,35;3,33;7;0;3,604;71;Zwangsladung aktiv und mit 800 W gestartet, SoC > 80%
08.08.2026;21:00;99;3,34;3,32;0;0;3,606;71;Nachtmodus, Beginn Entladung mit 175 W
09.08.2026;07:00;10;3,16;3,15;18;0;0,012;143;Entladung vorzeitg beendet, SoC <= 10%
09.08.2026;08:00;10;3,20;3,19;26;0;0,035;143;08:00 Uhr: Entladung Ende, Beginn Tagmodus
09.08.2026;08:14;10;3,20;3,19;54;49;0,043;143;PV-Aufladung Start, inputLimit > 0
09.08.2026;15:59;99;3,41;3,38;386;300;3,243;143;PV-Aufladung vorzeitig beendet, PV noch 386 W
09.08.2026;20:00;99;3,35;3,33;8;0;3,804;143;Zwangsladung aktiv und mit 800 W gestartet, SoC > 80%
09.08.2026;21:00;99;3,34;3,32;0;0;3,808;143;Nachtmodus, Beginn Entladung mit 175 W
09.08.2026;21:00;98;3,32;3,31;0;0;3,808;143;SoC hat 98% erreicht
09.08.2026;21:21;95;3,31;3,30;0;0;3,808;143;SoC hat 95% erreicht
10.08.2026;07:02;10;3,18;3,16;17;0;0,007;78;Entladung vorzeitg beendet, SoC <= 10%
10.08.2026;08:00;10;3,20;3,19;53;0;0,044;78;08:00 Uhr: Entladung Ende, Beginn Tagmodus
10.08.2026;08:00;10;3,20;3,19;54;51;0,044;78;PV-Aufladung Start, inputLimit > 0
10.08.2026;08:20;10;3,20;3,19;55;54;0,059;78;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
10.08.2026;08:28;10;3,21;3,20;55;52;0,070;78;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
10.08.2026;14:40;71;3,35;3,34;55;54;2,197;78;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
10.08.2026;15:56;72;3,35;3,34;55;52;2,263;78;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
10.08.2026;16:14;73;3,35;3,34;55;53;2,286;78;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
10.08.2026;18:22;73;3,34;3,33;55;53;2,353;78;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
10.08.2026;20:00;73;3,34;3,33;6;0;2,408;78;Zwangsladung gesperrt, SoC < 80%
10.08.2026;21:00;73;3,33;3,33;0;0;2,411;78;Nachtmodus, Beginn Entladung mit 175 W
11.08.2026;04:15;10;3,16;3,15;0;0;0,000;78;Entladung vorzeitg beendet, SoC <= 10%
11.08.2026;08:00;10;3,19;3,19;26;0;0,031;234;08:00 Uhr: Entladung Ende, Beginn Tagmodus
11.08.2026;08:12;10;3,20;3,19;55;51;0,039;234;PV-Aufladung Start, inputLimit > 0
11.08.2026;18:23;92;3,32;3,31;54;0;2,641;234;PV-Aufladung beendet, inputLimit = 0
11.08.2026;20:00;91;3,33;3,33;10;0;2,709;234;Zwangsladung aktiv und mit 800 W gestartet, SoC > 80%
11.08.2026;20:06;95;3,44;3,40;5;800;2,710;234;Soc 95% erreicht
11.08.2026;20:12;98;3,45;3,41;3;800;2,710;234;Soc 98% erreicht
11.08.2026;20:15;98;3,44;3,40;2;0;2,711;234;Soc 98% erreicht, Neustart script 
11.08.2026;20:33;98;3,44;3,41;0;800;2,711;234;Soc 98% erreicht nach Neustart script
11.08.2026;20:50;98;3,59;3,45;0;800;2,711;234;Zwangsladung beendet, maxVol >= 3.59V
11.08.2026;20:52;98;3,59;3,45;0;800;2,711;234;Zwangsladung beendet, maxVol >= 3.59V
11.08.2026;20:53;100;3,58;3,44;0;0;2,711;234;Soc 100% erreicht
11.08.2026;21:00;100;3,51;3,40;0;0;2,711;234;Nachtmodus, Beginn Entladung mit 175 W
11.08.2026;21:08;98;3,31;3,30;0;0;2,711;234;Soc 98% erreicht
11.08.2026;21:28;95;3,31;3,30;0;0;2,711;234;Soc 95% erreicht
12.08.2026;07:05;10;3,16;3,15;12;0;0,010;80;Entladung vorzeitg beendet, SoC <= 10%
12.08.2026;08:00;10;3,20;3,19;24;0;0,028;80;08:00 Uhr: Entladung Ende, Beginn Tagmodus
12.08.2026;08:13;10;3,20;3,19;54;50;0,036;80;PV-Aufladung Start, inputLimit > 0
12.08.2026;15:53;95;3,39;3,37;405;287;3,296;80;Soc 95% erreicht
12.08.2026;16:09;98;3,40;3,38;373;271;3,397;80;Soc 98% erreicht
12.08.2026;16:35;98;3,60;3,45;319;245;3,553;80;PV-Aufladung vorzeitig beendet, PV noch 319 W
12.08.2026;16:35;100;3,59;3,45;318;245;3,554;80;Soc 100% erreicht
12.08.2026;18:23;100;3,39;3,34;55;0;3,889;80;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
12.08.2026;20:00;99;3,35;3,33;0;0;3,920;80;Zwangsladung aktiv und mit 800 W gestartet, SoC > 80%
12.08.2026;21:00:00.015;99;3,34;3,32;0;0;3,920;80;Nachtmodus, Beginn Entladung mit 175 W
12.08.2026;21:01:39.846;98;3,31;3,30;0;0;3,920;80;Soc 98% erreicht
12.08.2026;21:22:30.948;95;3,31;3,30;0;0;3,920;80;Soc 95% erreicht
13.08.2026;07:01:23.989;10;3,17;3,16;12;0;0,009;160;Entladung vorzeitg beendet, SoC <= 10%
13.08.2026;08:00:00.014;10;3,20;3,19;23;0;0,027;160;08:00 Uhr: Entladung Ende, Beginn Tagmodus
13.08.2026;08:14:15.568;10;3,20;3,19;54;51;0,035;160;PV-Aufladung Start, inputLimit > 0
13.08.2026;16:06:51.839;95;3,38;3,37;377;274;3,326;160;Soc 95% erreicht
13.08.2026;16:23:34.517;98;3,39;3,38;335;253;3,428;160;Soc 98% erreicht
13.08.2026;16:39:55.881;99;3,43;3,40;308;241;3,517;160;Soc 99% erreicht
13.08.2026;16:39:58.888;98;3,43;3,40;308;241;3,517;160;Soc 98% erreicht
13.08.2026;16:51:22.905;98;3,60;3,45;282;228;3,574;160;PV-Aufladung vorzeitig beendet, PV noch 282 W
13.08.2026;16:51:31.875;100;3,59;3,44;282;228;3,574;160;Soc 100% erreicht
13.08.2026;18:23:08.637;100;3,41;3,34;55;0;3,833;160;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
13.08.2026;18:49:34.119;99;3,39;3,34;22;0;3,850;160;Soc 99% erreicht
13.08.2026;20:00:00.030;99;3,36;3,33;3;0;3,867;160;Zwangsladung aktiv und gestartet falls SoC > 90%
13.08.2026;21:00:00.029;99;3,34;3,32;0;0;3,869;160;Nachtmodus, Beginn Entladung mit 175 W
13.08.2026;21:03:07.126;98;3,31;3,30;0;0;3,869;160;Soc 98% erreicht
13.08.2026;21:23:46.161;95;3,31;3,29;0;0;3,869;160;Soc 95% erreicht
14.08.2026;07:00:05.277;10;3,17;3,16;11;0;0,007;92;Entladung vorzeitg beendet, SoC <= 10%
14.08.2026;08:00:00.056;10;3,20;3,19;21;0;0,024;92;08:00 Uhr: Entladung Ende, Beginn Tagmodus
14.08.2026;08:15:04.074;10;3,20;3,19;54;51;0,033;92;PV-Aufladung Start, inputLimit > 0
14.08.2026;16:33:31.399;95;3,38;3,37;317;237;3,410;92;Soc 95% erreicht
14.08.2026;16:53:05.378;98;3,39;3,37;273;217;3,506;92;Soc 98% erreicht
14.08.2026;17:17:17.390;99;3,47;3,42;214;190;3,606;92;Soc 99% erreicht
14.08.2026;17:17:23.421;98;3,48;3,42;213;189;3,606;92;Soc 98% erreicht
14.08.2026;17:22:20.393;98;3,60;3,44;202;184;3,624;92;PV-Aufladung vorzeitig beendet, PV noch 202 W
14.08.2026;17:22:29.400;100;3,59;3,44;201;184;3,624;92;Soc 100% erreicht
14.08.2026;18:22:36.114;100;3,43;3,36;55;0;3,752;92;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
14.08.2026;19:14:22.479;99;3,39;3,34;15;0;3,778;92;Soc 99% erreicht
14.08.2026;20:00:00.030;99;3,37;3,33;2;0;3,786;92;Zwangsladung aktiv und gestartet falls SoC > 90%
14.08.2026;21:00:00.031;99;3,35;3,33;0;0;3,787;92;Nachtmodus, Beginn Entladung mit 175 W
14.08.2026;21:02:22.388;98;3,31;3,30;0;0;3,787;92;Soc 98% erreicht
14.08.2026;21:23:13.494;95;3,31;3,29;0;0;3,787;92;Soc 95% erreicht
15.08.2026;06:58:13.504;10;3,16;3,15;11;0;0,007;906;Entladung vorzeitg beendet, SoC <= 10%
15.08.2026;08:00:00.015;10;3,20;3,19;23;0;0,026;906;08:00 Uhr: Entladung Ende, Beginn Tagmodus
15.08.2026;08:15:50.770;10;3,20;3,19;54;50;0,035;906;PV-Aufladung Start, inputLimit > 0
15.08.2026;17:02:49.994;95;3,38;3,36;221;192;3,416;906;Soc 95% erreicht
15.08.2026;17:28:50.972;98;3,39;3,37;168;164;3,497;906;Soc 98% erreicht
15.08.2026;18:17:36.588;98;3,38;3,37;55;53;3,579;906;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
15.08.2026;18:19:21.612;98;3,39;3,37;55;54;3,581;906;Unterer Grenzwert zum aufladen via PV erreicht, PV <= 55 W
15.08.2026;20:00:00.014;98;3,33;3,33;0;0;3,617;906;Zwangsladung aktiv und gestartet falls SoC > 90%
15.08.2026;20:05:34.163;98;3,59;3,44;0;800;3,618;906;Zwangsladung beendet, maxVol >= 3.59V
15.08.2026;20:06:21.185;98;3,59;3,43;0;800;3,618;906;Zwangsladung beendet, maxVol >= 3.59V
15.08.2026;20:06:58.225;98;3,59;3,43;0;800;3,618;906;Zwangsladung beendet, maxVol >= 3.59V
15.08.2026;20:07:04.206;98;3,60;3,43;0;800;3,618;906;Zwangsladung beendet, maxVol >= 3.59V
15.08.2026;20:07:13.580;100;3,59;3,43;0;0;3,618;906;Soc 100% erreicht
15.08.2026;20:07:13.591;100;3,59;3,43;0;0;3,618;906;Zwangsladung beendet, maxVol >= 3.59V
15.08.2026;21:00:00.033;100;3,44;3,36;0;0;3,618;906;Nachtmodus, Beginn Entladung mit 175 W
15.08.2026;21:02:02.350;99;3,37;3,32;0;0;3,618;906;Soc 99% erreicht
15.08.2026;21:07:02.385;98;3,31;3,30;0;0;3,618;906;Soc 98% erreicht
15.08.2026;21:27:50.498;95;3,31;3,30;0;0;3,618;906;Soc 95% erreicht
16.08.2026;07:01:19.260;10;3,17;3,16;8;0;0,000;135;Entladung vorzeitg beendet, SoC <= 10%
16.08.2026;08:00:00.013;10;3,20;3,19;9;0;0,011;135;08:00 Uhr: Entladung Ende, Beginn Tagmodus

Den Letzten Wert könnt ihr ignorieren, ist nur für mich interessant.

[maxclaudi]

hallo @Rico-Sander,

danke für das Teilen dieser interessanten Langzeitbeobachtung!

Für Daten- und Batterie-Analysten ist so ein lückenloses MQTT-Protokoll ein Traum.
Man kann die Zellchemie der LiFePO4-Akkus gut bei der Arbeit analysieren.

Am 11.08. um 20:12 Uhr hatte sich dein Steuerungsskript offenbar kurz verabschiedet („Soc 98% erreicht, Neustart script“). Nach dem automatischen Neustart um 20:33 Uhr lief die 800W-Zwangsladung aber sofort wieder bis zum Spannungsziel weiter.

---

Erlaube mir jedoch einen gut gemeinten und rein pragmatischen Hinweis zu deiner Steuerung aus Sicht der Batterie-Lebensdauer.

Deine Abschaltgrenze bei 3,59 V (maxVol) ist für den täglichen Dauerbetrieb chemisch leider etwas zu gierig und stresst die Zellen massiv.

Besser ist wenn du deine Abschaltgrenze optimieren würdest, denn

1. Keine Mehrkapazität, aber maximaler Stress
   Eine Lithium-Eisenphosphat-Zelle (LiFePO4) ist bei 3,45 V bereits zu etwa 98 % voll.
   Alles, was an Spannung darüber hinaus in die Zelle gepresst wird (von 3,45 V hoch auf deine 3,59 V), bringt keine messbare Mehrkapazität oder zusätzliche Energie.
   Du pumpst lediglich die Spannung künstlich auf und erzeugst enormen chemischen Druck sowie Hitze in den hauchdünnen Separatoren der Zelle.
   Zudem kratzt du mit 3,59 V schon gefährlich nah an der absoluten, unumstößlichen Grenze von 3,65 V, ab der Zellen dauerhaft Schaden nehmen.

2. Der Zelldrift-Effekt
   Sehr schön in deinem eigenen Log zu sehen.
   Schau mal auf deinen Eintrag vom 05.08. um 20:32 Uhr:
   maxVol: 3,59 V
   minVol: 3,45 V

Das ist ein massiver Zelldrift von satten 0,14 V!
Weil du mit brutalen 800 Watt bis ganz nach oben ballerst, rennen dir die Zellen am steilen Ende der Ladekurve komplett auseinander.
Das Zendure-BMS muss hier Schwerstarbeit (Balancing) leisten, um die vollste Zelle krampfhaft einzubremsen, bevor sie die 3,65 V reißt und das System wegen Überspannung hart abschaltet.

---

Empfehlung für eine lange Akku-Lebenszeit:

Riegele die Zwangsladung bei 3,45 V bis maximal 3,50 V ab.
Optimaler Aufbau: Sobald die erste Zelle 3,45 V erreicht, schalte die Leistung nicht hart ab, sondern reduziere sie von 800 W langsam auf z. B. 50 W (Absorptionsphase).
Dann gleiten die Zellen ohne jeden Stress, völlig gleichmäßig und ohne brutale Drifts auf echte 100 % SoC.
Damit schonst du die Hardware und sorgst dafür, dass dein Akku auch in vielen Jahren noch die volle Leistung bringt.

Viele Grüße und weiterhin frohes Daten-Loggen!

[Rico Sander]

@maxclaudi
Einen schönen Sonntag und danke für die Tipps.
Da ich eh noch in der Optinmierungsphase bin, werde ich die Werte einmal ändern.

Andereseits versuche ich die PV-Ladekurve so "hinzubiegen", dass ich zum Spätnachmittag/Frühabend bei knapp 100% oder 100% lande, um nicht nachladen zu müssen. In diesem Fall wird gegen Ende der Vollladung eh mit weit geringerer Leistung (PV) eingespeist, so dass sich der von Dir genannte Effekt eher nicht einstellen wird.
Für die Zwangsladung jedoch werde ich das einmal ändern.

Ich arbeite nach wie vor mit Deinem HTTP-Script und der eigenen Steuerung.

[Murphy 0]

Guter Tipp,
momentan regle ich beim Hyper 2000 mit 2x AB2000 die Ladeleistung ab 90% SOC auf 900 Watt und ab 99% SOC auf 600 Watt und schalte bei 3.45 Volt maxVolt ab.

Werde nun mal einen Test machen und ab 3.42 Volt mit 50 Watt bis 3.45 Volt laden.
Ich beobachte bei mir ebenfalls einen Zelldrift ab ca. 3.40 Volt. (Tippfehler verbessert)