NEWS
Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2
-
wenn es nicht mit neuer Firmware verändert wurde
Es sieht danach aus. Log von heute:
2026-08-14 03:41:21.984 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 03:41:25.004 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 06:20:27.839 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 06:20:30.862 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 09:04:33.916 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 09:04:36.934 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 10:55:19.354 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 10:55:24.190 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 10:55:34.354 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 10:55:39.354 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (2): timeout of 2000ms exceeded 2026-08-14 10:55:42.398 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 10:55:49.355 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 10:55:54.355 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (2): timeout of 2000ms exceeded 2026-08-14 10:55:57.517 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OK 2026-08-14 11:48:39.606 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-08-14 11:48:42.624 - [32minfo[39m: javascript.0 (838) script.js.common.Solarflow: Verbindung wieder OKDer 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.
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 sagte:
Aber beides braucht man ja eigentlich nicht...Richtig, beides benötigt man nicht.
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..
Aber dafür muss ich mir mal Zeit nehmen. Das geht nicht mehr vor dem Urlaub.
Schönen Urlaub Deiner Familie und Dir.
@Daniel-8 sagte:
Aber beides braucht man ja eigentlich nicht...Richtig, beides benötigt man nicht.
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.
Aber dafür muss ich mir mal Zeit nehmen. Das geht nicht mehr vor dem Urlaub.
Schönen Urlaub Deiner Familie und Dir.
Danke.
-
-
@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
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@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 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 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. -
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.
-
Datenverkehr geloggt:
App <> Gerät
Cloud <> GerätWichtige Zeitpunkte gefiltert, entschlüsselt und analysiert.
Windows-Konsolen-Programm ist fertig:
zendureURLtool.exeDas Tool ist stabiler und schneller als die App :-)
Credits für die genutzte Bluetooth-Bibliothek gehen an Henrik Blidh:
https://github.com/hbldh/bleakMan füllt in der config.ini nur 3 Felder aus, speichert ab und los geht's mit Doppelklick auf "zendureURLtool.exe"...

entweder zu lokalem Broker wechseln:

oder zurück zur Cloud:

geht alles sehr schnell.
Selbst bei einem Hyper "ohne" stromlos machen.
Nicht mal Trennung von BT am Rechner war nötig.
Nur APP muss vollständig beendet sein.
Am besten in der Zeit zusätzlich BT am Smartphone ausgeschaltet lassen.



Bei einem Hyper habe ich für 3x IP wechseln nur ca. 2 min benötigt. Er war jedesmal sofort verbunden.
Am längsten dauerte das Aufstehen, den Button zu drücken und zu warten, dass er im Kopplungsmodus ist.
Es haben sich beim Analysieren noch mehr Wege geöffnet.
Allerdings sind die für mich aktuell unnötig und stehen – wenn überhaupt – ganz hinten an.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden