Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2
-
@Daniel-8
Deine Rückmeldung bestärkt meine Vermutung.
Dein Akku steht ja draußen im Kalten?Ja der steht draußen.
Wenn ja, tippe ich stark darauf, dass die integrierte Akkuheizung aktiv war.
Aber war es bis jetzt nicht so, das die Heizung erst angeht, wenn er unter 0° hat und laden will?
Ich hatte noch nie gesehen, das die Akkuheizung nachts an war. Zudem diese ja sowieso nur mit AC funktioniert. Man kann die Heizung nicht über Solarenergie betreiben.
Die Heizung zieht extrem viel Strom.
Wenn das Wetter tagsüber so schlecht war, dass der Akku ohnehin kaum geladen wurde, und nachts die Heizung anspringt, ist der Energiebedarf gigantisch.
Um zu verhindern, dass die Heizung den Akku im Winter komplett leersaugt (selbst wenn du den Schutz auf 50 % minSoc gestellt hast), greift vermutlich der Sicherheitsmechanismus der Firmware:
Bei Erreichen des Limits wird dem gesamten System - inklusive WLAN - komplett der Saft abgedreht, um die Zellen zu schützen.
Ein SolarFlow 800 Pro geht normalerweise nicht einfach so grundlos in einen so tiefen Schlaf, dass selbst WLAN abgeschaltet wird – es sei denn, ein interner Großverbraucher wie die Heizung hat das System in den Not-Standby gezwungen.
Da die App das Gerät als offline anzeigt, brauchst du auch keine Wertänderungen testen.
Falls du doch mal die Gelegenheit hast, schau morgens (wenn das Gerät erwacht) mal auf die Werte und ob Heizung aktiv ist.Auf welche werte meinst du?
Die Temperaturen und vor allem die Zellspannungen (minVol) wären dennoch extrem interessant.
So kann man sehen, ob die tatsächlichen Werte mit den 50 % SoC übereinstimmen oder ob die SoC-Berechnung aufgrund einer fehlenden Kalibrierung einfach nicht mehr stimmt.Kann ich mal schauen. Die Kalibrierung ist erst 5 Tage her.
Du solltest deinen Akku am besten einpacken (isolieren) oder anderweitig vor den tieferen Temperaturen schützen, um diesen massiven nächtlichen Energieverlust zu verhindern.
Ich habe nur ca. 2 Prozent über Nacht Verlust
-
Hallo guten Morgen,
ich hatte mit meunemSF800Pro die Tage das gleiche Problem, dass der offline ging und ich erinnere mich, dass ich das letzten Winter auch schon mal hatte, die gleichen Symptome wie hier beschrieben. Ich habe dann den Netzstecker gezogen, die Module abgeklemmt und neu gestartet. Danach wieder alles abgeklemmt und dann hat wieder alles funktioniert. Mein SF800Pro steht allerdings im warmen, da läuft sicher keine Heizung. -
Hallo guten Morgen,
ich hatte mit meunemSF800Pro die Tage das gleiche Problem, dass der offline ging und ich erinnere mich, dass ich das letzten Winter auch schon mal hatte, die gleichen Symptome wie hier beschrieben. Ich habe dann den Netzstecker gezogen, die Module abgeklemmt und neu gestartet. Danach wieder alles abgeklemmt und dann hat wieder alles funktioniert. Mein SF800Pro steht allerdings im warmen, da läuft sicher keine Heizung.Für mich ist das auch kein Problem. Es war eigentlich nur eine feststellung und auch Mitteilung damit andere auch informiert sind und sich nicht über das verhalten wundern
-
zum Vergleich:
aktuell ist das 2400ACpro-Testsystem auf der Terrasse mit
• hyperTmp 9°C
• maxTemp 8°C
Wie es dann in der Nacht aussah kann man sich vorstellen.zum Vergleich:
aktuell ist das 2400ACpro-Testsystem auf der Terrasse mit
• hyperTmp 9°CBei mir aktuell 20°C
• maxTemp 8°C
Im Moment auch 7 und 6.
Wie es dann in der Nacht aussah kann man sich vorstellen.
Nachts vermutlich bisschen weniger. Hatten heute Morgen 2°C Außentemperatur.
-
Hallo guten Morgen,
ich hatte mit meunemSF800Pro die Tage das gleiche Problem, dass der offline ging und ich erinnere mich, dass ich das letzten Winter auch schon mal hatte, die gleichen Symptome wie hier beschrieben. Ich habe dann den Netzstecker gezogen, die Module abgeklemmt und neu gestartet. Danach wieder alles abgeklemmt und dann hat wieder alles funktioniert. Mein SF800Pro steht allerdings im warmen, da läuft sicher keine Heizung.Für mich ist das auch kein Problem. Es war eigentlich nur eine feststellung und auch Mitteilung damit andere auch informiert sind und sich nicht über das verhalten wundern
@Daniel-8 sagte:
Für mich ist das auch kein Problem. Es war eigentlich nur eine feststellung und auch Mitteilung damit andere auch informiert sind und sich nicht über das verhalten wundernFinde das für Alle eine wertvolle Information.
Wenn sowieso Standby ist und es absolut nichts zu tun gibt, dann ist dieses Verhalten der Firmware aus Sicht des Energiemanagements doch nahezu ideal, oder nicht?
WLAN und Bluetooth im Dauer-Standby ziehen über die vielen Stunden der Dunkelheit nur unnötig Strom aus den Zellen.
Die MCU komplett schlafen zu legen und morgens rein hardwareseitig über den ersten PV-Strom wieder zu wecken, ist die effizienteste Methode, um den Akku im Winter zu schonen. Man benötigt ja keine Live-Infos auf dem Dashboard, wenn es ohnehin nichts zu steuern gibt. Sobald das Gerät morgens wieder von allein erwacht, ist alles perfekt gelöst.Hätte man es als Software-Architekt besser lösen können?
Persönlich denke ich: Nein, im Kern nicht. Das harte Abschalten ist die sicherste Methode. Wenn die Verbindung gekappt ist, kann kein (fehlerhaftes) externes Skript oder eine hängende Cloud-Verbindung das System nachts ungewollt wachhalten und den Akku leersaugen.Das Einzige, was ich als Entwickler zusätzlich implementiert hätte, wäre eine saubere Status-Meldung vor dem Einschlafen: Dass das Gerät einen letzten MQTT- oder HTTP-Befehl absetzt ("Inaktivität - gehe in Deep-Sleep"), bevor es die Funkmodule abschaltet. Dann würde die App oder ein Skript nicht "Verbindung verloren / Fehler" melden, sondern den sauberen Status "Schläft tief (Warten auf Sonne)" ausgeben.
edit/PS:
ich hätte mir allerdings schon zusätzlich Gedanken gemacht, ob es nicht sinnvoll gewesen wäre, eine echte Sicherheitsabfrage einzubauen.
Ideal wäre eine Logik wie: „Standby vorgesehen in X Minuten/Sekunden“. Wenn innerhalb dieses definierten Zeitfensters kein aktiver Wachhaltebefehl (wie z. B. ein neuer Lade- oder Steuerbefehl) vom Skript oder der App reinkommt, fährt das System erst dann kontrolliert in den Deep-Sleep.So wie es jetzt gelöst ist, ist es eben ein sehr harter, kompromissloser Schnitt der Firmware, ohne dem lokalen System noch eine Chance zur Reaktion zu geben.
-
@Berny-K
Nun, das ist – verzeih mir die Ausdrucksweise – Hardcore für die Hardware.
Das funktioniert und bekämpft die Symptome, aber es behebt nicht die Ursache ;-) -
@maxclaudi
Da gib ich dir absolut recht aber ich wusste mir einfach nicht anders zu helfen. Werde das mal beobachten, wenn es wieder passiert, ob er von selbst wieder online geht sobald genügend PV-Leistung anliegt.@Berny-K
Alles gut, man erschrickt ja erst mal, wenn das System plötzlich totzuspringen scheint.
Beobachte das beim nächsten Mal einfach ganz entspannt.
Sobald die Panels morgens wieder um die ca. 40 Watt liefern, sollte der Eigenverbrauch gedeckt sein und das Gerät taucht von alleine wieder im WLAN auf. Der harte Reboot sollte nicht nötig sein.edit/PS:
Wundere dich aber nicht über die Zahlen in der App: Das System zieht den internen Eigenverbrauch ab und meldet dann meist nur ca. 10 Watt Einspeisung.edit/PPS:
@Berny-K (und @Daniel-8)
Noch eine Vermutung von mir:
Ich denke nicht, dass so ein radikales Steckerziehen überhaupt nötig ist, wenn man das System mal zwischendurch manuell wecken möchte.
Theoretisch müsste es reichen, das System kurz aufzuwecken, indem man die physische IoT-Taste am Gerät kurz 1 oder 2x betätigt.
Das sollte die MCU und die Funkmodule (zumindest für paar Sekunden/Minuten) manuell triggern, ohne dass man die ganze Hardware unter Last abklemmen muss.
Hat das von euch schon mal jemand in diesem Zustand ausprobiert? -
@Daniel-8 sagte:
Für mich ist das auch kein Problem. Es war eigentlich nur eine feststellung und auch Mitteilung damit andere auch informiert sind und sich nicht über das verhalten wundernFinde das für Alle eine wertvolle Information.
Wenn sowieso Standby ist und es absolut nichts zu tun gibt, dann ist dieses Verhalten der Firmware aus Sicht des Energiemanagements doch nahezu ideal, oder nicht?
WLAN und Bluetooth im Dauer-Standby ziehen über die vielen Stunden der Dunkelheit nur unnötig Strom aus den Zellen.
Die MCU komplett schlafen zu legen und morgens rein hardwareseitig über den ersten PV-Strom wieder zu wecken, ist die effizienteste Methode, um den Akku im Winter zu schonen. Man benötigt ja keine Live-Infos auf dem Dashboard, wenn es ohnehin nichts zu steuern gibt. Sobald das Gerät morgens wieder von allein erwacht, ist alles perfekt gelöst.Hätte man es als Software-Architekt besser lösen können?
Persönlich denke ich: Nein, im Kern nicht. Das harte Abschalten ist die sicherste Methode. Wenn die Verbindung gekappt ist, kann kein (fehlerhaftes) externes Skript oder eine hängende Cloud-Verbindung das System nachts ungewollt wachhalten und den Akku leersaugen.Das Einzige, was ich als Entwickler zusätzlich implementiert hätte, wäre eine saubere Status-Meldung vor dem Einschlafen: Dass das Gerät einen letzten MQTT- oder HTTP-Befehl absetzt ("Inaktivität - gehe in Deep-Sleep"), bevor es die Funkmodule abschaltet. Dann würde die App oder ein Skript nicht "Verbindung verloren / Fehler" melden, sondern den sauberen Status "Schläft tief (Warten auf Sonne)" ausgeben.
edit/PS:
ich hätte mir allerdings schon zusätzlich Gedanken gemacht, ob es nicht sinnvoll gewesen wäre, eine echte Sicherheitsabfrage einzubauen.
Ideal wäre eine Logik wie: „Standby vorgesehen in X Minuten/Sekunden“. Wenn innerhalb dieses definierten Zeitfensters kein aktiver Wachhaltebefehl (wie z. B. ein neuer Lade- oder Steuerbefehl) vom Skript oder der App reinkommt, fährt das System erst dann kontrolliert in den Deep-Sleep.So wie es jetzt gelöst ist, ist es eben ein sehr harter, kompromissloser Schnitt der Firmware, ohne dem lokalen System noch eine Chance zur Reaktion zu geben.
Wenn sowieso Standby ist und es absolut nichts zu tun gibt, dann ist dieses Verhalten der Firmware aus Sicht des Energiemanagements doch nahezu ideal, oder nicht?
Ja ideal ist es mehr oder weniger gut Die Zeit mit ca. 13 Stunden ist schon lange. Er ist grad mal so ne Stunde im Tiefschlaf.
-
@Berny-K
Alles gut, man erschrickt ja erst mal, wenn das System plötzlich totzuspringen scheint.
Beobachte das beim nächsten Mal einfach ganz entspannt.
Sobald die Panels morgens wieder um die ca. 40 Watt liefern, sollte der Eigenverbrauch gedeckt sein und das Gerät taucht von alleine wieder im WLAN auf. Der harte Reboot sollte nicht nötig sein.edit/PS:
Wundere dich aber nicht über die Zahlen in der App: Das System zieht den internen Eigenverbrauch ab und meldet dann meist nur ca. 10 Watt Einspeisung.edit/PPS:
@Berny-K (und @Daniel-8)
Noch eine Vermutung von mir:
Ich denke nicht, dass so ein radikales Steckerziehen überhaupt nötig ist, wenn man das System mal zwischendurch manuell wecken möchte.
Theoretisch müsste es reichen, das System kurz aufzuwecken, indem man die physische IoT-Taste am Gerät kurz 1 oder 2x betätigt.
Das sollte die MCU und die Funkmodule (zumindest für paar Sekunden/Minuten) manuell triggern, ohne dass man die ganze Hardware unter Last abklemmen muss.
Hat das von euch schon mal jemand in diesem Zustand ausprobiert?Theoretisch müsste es reichen, das System kurz aufzuwecken, indem man die physische IoT-Taste am Gerät kurz 1 oder 2x betätigt.
Das sollte die MCU und die Funkmodule (zumindest für paar Sekunden/Minuten) manuell triggern, ohne dass man die ganze Hardware unter Last abklemmen muss.
Hat das von euch schon mal jemand in diesem Zustand ausprobiert?Nein weil ich sehr schlecht hin komme wo der Speicher steht.
Solarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno
-
Theoretisch müsste es reichen, das System kurz aufzuwecken, indem man die physische IoT-Taste am Gerät kurz 1 oder 2x betätigt.
Das sollte die MCU und die Funkmodule (zumindest für paar Sekunden/Minuten) manuell triggern, ohne dass man die ganze Hardware unter Last abklemmen muss.
Hat das von euch schon mal jemand in diesem Zustand ausprobiert?Nein weil ich sehr schlecht hin komme wo der Speicher steht.
@Daniel-8 sagte:
Nein weil ich sehr schlecht hin komme wo der Speicher steht.Für so ein Szenario fällt mir spontan ein kleiner Fingerbot mit Akku ein, den man einfach über das Handy oder ioBroker triggert! :-)))
Der drückt dann per Funk den Knopf für dich, und du musst nicht jedes Mal in die schwer zugängliche Ecke krabbeln.
Das wäre eine Smart-Home-Lösung für das "Deep-Sleep-Problem" im Winter :-)War nur scherzhaft ;-)
Wobei - mich erinnert das Ganze an die Anfangszeit mit dem HUB2000 und dem ACE1500.
Da gab es auch Fälle, in denen nur vor Ort ein physisches Aus- und wieder Einschalten half.
Weil ich öfter nicht vor Ort bin, ist so etwas für mich der absolute Worst Case. Ich war damals tatsächlich kurz drauf und dran, einen Fingerbot zu verwenden.Aber der Hub ließ sich - im Gegensatz zu den neuen Geräten - noch zerstörungsfrei öffnen.
Ich habe damals einfach einen kleinen ESP8266 mit Optokoppler parallel zur physischen IoT-Taste gelötet, um eine zuverlässige Fernsteuerung zu ermöglichen. -
@Berny-K
Alles gut, man erschrickt ja erst mal, wenn das System plötzlich totzuspringen scheint.
Beobachte das beim nächsten Mal einfach ganz entspannt.
Sobald die Panels morgens wieder um die ca. 40 Watt liefern, sollte der Eigenverbrauch gedeckt sein und das Gerät taucht von alleine wieder im WLAN auf. Der harte Reboot sollte nicht nötig sein.edit/PS:
Wundere dich aber nicht über die Zahlen in der App: Das System zieht den internen Eigenverbrauch ab und meldet dann meist nur ca. 10 Watt Einspeisung.edit/PPS:
@Berny-K (und @Daniel-8)
Noch eine Vermutung von mir:
Ich denke nicht, dass so ein radikales Steckerziehen überhaupt nötig ist, wenn man das System mal zwischendurch manuell wecken möchte.
Theoretisch müsste es reichen, das System kurz aufzuwecken, indem man die physische IoT-Taste am Gerät kurz 1 oder 2x betätigt.
Das sollte die MCU und die Funkmodule (zumindest für paar Sekunden/Minuten) manuell triggern, ohne dass man die ganze Hardware unter Last abklemmen muss.
Hat das von euch schon mal jemand in diesem Zustand ausprobiert?@maxclaudi
Bei mir hat das mit der IoT Taste leider auch nicht funktioniert.Ich konnte ihn auch nach mehreren Versuchen damit nicht wieder aufwecken. -
@Daniel-8 sagte:
Nein weil ich sehr schlecht hin komme wo der Speicher steht.Für so ein Szenario fällt mir spontan ein kleiner Fingerbot mit Akku ein, den man einfach über das Handy oder ioBroker triggert! :-)))
Der drückt dann per Funk den Knopf für dich, und du musst nicht jedes Mal in die schwer zugängliche Ecke krabbeln.
Das wäre eine Smart-Home-Lösung für das "Deep-Sleep-Problem" im Winter :-)War nur scherzhaft ;-)
Wobei - mich erinnert das Ganze an die Anfangszeit mit dem HUB2000 und dem ACE1500.
Da gab es auch Fälle, in denen nur vor Ort ein physisches Aus- und wieder Einschalten half.
Weil ich öfter nicht vor Ort bin, ist so etwas für mich der absolute Worst Case. Ich war damals tatsächlich kurz drauf und dran, einen Fingerbot zu verwenden.Aber der Hub ließ sich - im Gegensatz zu den neuen Geräten - noch zerstörungsfrei öffnen.
Ich habe damals einfach einen kleinen ESP8266 mit Optokoppler parallel zur physischen IoT-Taste gelötet, um eine zuverlässige Fernsteuerung zu ermöglichen.Für so ein Szenario fällt mir spontan ein kleiner Fingerbot mit Akku ein, den man einfach über das Handy oder ioBroker triggert! :-)))
Sowas hätte ich fast schon mal gekauft aber nicht für den zendure sondern für den Growatt.
Also ich habe den Tausch zu Zendure bis jetzt nicht bereut.
-
packData.xxxx.
- maxTemp
beide 8°C
- maxVol
beide 3,27V
- minVol
3,27V und 3,28V
properties:
- BatVolt
49,39V
- electricLevel
49%
- faultLevel
0
- heatStat
0 unverändert seit 23.06.2026
- hyperTmp
8°C
- is_error
0
- socStatus
0
- dataReady
1
Anbei mal die Werte
Solarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno
-
packData.xxxx.
- maxTemp
beide 8°C
- maxVol
beide 3,27V
- minVol
3,27V und 3,28V
properties:
- BatVolt
49,39V
- electricLevel
49%
- faultLevel
0
- heatStat
0 unverändert seit 23.06.2026
- hyperTmp
8°C
- is_error
0
- socStatus
0
- dataReady
1
Anbei mal die Werte
@Daniel-8
Die Zahlen sind aufschlussreich und bestätigen ein altbekanntes Phänomen bei LiFePO4-Zellen:Deine Zellspannungen liegen stabil bei 3,27V bis 3,28V, die Gesamtspannung bei 49,39V.
Bei einem 15S-Akku ist das physikalisch ein absolut gesunder, noch gut gefüllter Zustand - chemisch entspricht das eher 60% bis 70% realer Kapazität.Dass die Firmware 49% ausgibt und das Gerät wegen deines Limits (50%) kurz darauf schlafen schickt, bedeutet:
Die softwareseitige SoC-Berechnung der Firmware läuft zu ungenau, selbst wenn deine Kalibrierung erst 5 Tage her ist.
Vermutlich wurde nicht richtig bzw. vollständig kalibriert.Wenn das die Werte sind nach dem Aufwachen, dann schaltet das Gerät nicht ab, weil der Akku real leer ist oder die Heizung ihn leergesaugt hat, sondern weil die Firmware sich "verrechnet" hat und fälschlicherweise denkt, der Mindest-SoC sei erreicht.
Physikalisch ist die Batterie noch top. -
packData.xxxx.
- maxTemp
beide 8°C
- maxVol
beide 3,27V
- minVol
3,27V und 3,28V
properties:
- BatVolt
49,39V
- electricLevel
49%
- faultLevel
0
- heatStat
0 unverändert seit 23.06.2026
- hyperTmp
8°C
- is_error
0
- socStatus
0
- dataReady
1
Anbei mal die Werte
Du hättest zwei Optionen, um das Problem zu lösen:
-
Option 1 (Neukalibrierung): Die Kalibrierung noch einmal durchführen. Akku auf 100 % laden und ruhen lassen.
Danach noch mal sanft nachladen, bis die 100 % garantiert erreicht sind.
Anschließend bis auf 5 % entladen und nochmals vollständig auf 100 % aufladen.
Dann sollte die SoC-Berechnung der Firmware eher stimmen. -
Option 2 (Die Skript-Lösung):
Die kennst Du doch inzwischen ;-)
Den minSoc in der Firmware auf 10 bis 15 % absenken und die Abschaltung vollständig einem geprüften, sicheren Skript anvertrauen.
Das Skript überwacht die realen Zellspannungen und schaltet den Entladevorgang sicher ab, sobald die minVol einer einzigen Zelle aller Batterien einen definierten Spannungswert erreicht.
Ich bevorzuge den zweiten Weg, unabhängig von der ungenauen Prozentberechnung der Firmware.
-
Ja die 49 kommen daher das er halt über Nacht was verliert. Die Akkus werden dann in Standby geschickt. Da ist er aber noch erreichbar. Das ein bisschen mehr drinnen ist wie angezeigt habe ich auch schon festgestellt, wenn er mal auf 100 Prozent lädt und viel weniger rein geht als soll.
Aber das tiefe abschalten ist erst nach ca 13 Stunden der letzten BefehlEingabe.
Das ist für mich kein Problem und wollte es nur mitteilen. Ich bin so zufrieden wenn er bei 50% soc aufhört zum einspeisen.
Mir ist das ganze ja nur aufgefallen weil dann von deinem Script die Meldung IP prüfen kam. Dann schaute ich ob er vom wlan getrennt war. Aber sobald sonne kommt läuft ja wieder alles. Deswegen unternehme ich da auch nichts.
Solarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno
-
Ja die 49 kommen daher das er halt über Nacht was verliert. Die Akkus werden dann in Standby geschickt. Da ist er aber noch erreichbar. Das ein bisschen mehr drinnen ist wie angezeigt habe ich auch schon festgestellt, wenn er mal auf 100 Prozent lädt und viel weniger rein geht als soll.
Aber das tiefe abschalten ist erst nach ca 13 Stunden der letzten BefehlEingabe.
Das ist für mich kein Problem und wollte es nur mitteilen. Ich bin so zufrieden wenn er bei 50% soc aufhört zum einspeisen.
Mir ist das ganze ja nur aufgefallen weil dann von deinem Script die Meldung IP prüfen kam. Dann schaute ich ob er vom wlan getrennt war. Aber sobald sonne kommt läuft ja wieder alles. Deswegen unternehme ich da auch nichts.
@Daniel-8
Alles klar, dann passt das ja perfekt für dein Setup :-)
Es ist auf jeden Fall gut, dass das für alle Mitleser hier im Thread dokumentiert ist.Sobald mit der Sonne morgens die MCU erwacht, läuft das Skript ja wie gewohnt weiter.
Ein zusätzliches Isolieren der Batterie(n) wäre zu empfehlen, wenn schon im Oktober nur 8°C erreicht werden.
-
zURLtool_V20 (c) maxclaudi 2026 - Version 2.0 cdh
Neu in zURLtool V 2.0 dch
• Sprachauswahl: Deutsch und Englisch sind auswählbar und während der Laufzeit umschaltbar.• Reset-Funktion: Geräte können zurückgesetzt werden (Hinweis: Zum vollständigen Abmelden - z.B. bei Verkauf - Gerät auch in der App entfernen!).
• WLAN-Handling: Das manuelle Setzen des WiFi-Mode entfällt. Ein automatischer Scan zeigt alle vom Zendure-Gerät erreichbaren Netze an. Bei zur config.ini abweichendem, manuell ausgewählten WLAN muss auch das Passwort in der GUI angepasst werden.
• Offline-Modus: Die Option OFFLINE = 1 in der config.ini überspringt den WLAN-Scan, ideal für Vorbereitungen oder Konfigurationen ohne aktiven Router.
• Token & User-ID: Gerätespezifischer Token wird in mqtt_creds.txt gesichert. Für die korrekte userId (bzw. consumerId) empfiehlt sich der Einsatz des Zusatztools zAppEmulationDeviceInfo
• Ein Backup mit den verwendeten Daten in der config.ini wird zusätzlich gespeichert. Beispiel: bak_config_26.10.26_14.51.35.ini
• Hinweis zu TLS / Port 8883: Das Tool ist ein reiner Konfigurator per Bluetooth und generiert keine TLS-Zertifikate oder Keys.
Beschreibung im Spoiler.
Bitte ReadMe_zURLtoolV20.txt beachten, enthält die deutsche und englische Beschreibung.
HINWEIS FÜR BESTEHENDE NUTZER:
Wer bereits für die Version 1.0 eine Seriennummer und einen Freischalt-Code erhalten hat, kann diese Daten direkt weiterverwenden!
Sie sind auch für die Version 2.0 gültig.
Bitte in diesem Fall keine erneute Anfrage.RECHTLICHER HINWEIS ZUR FREIGABE:
Eine Weitergabe von Seriennummer und Freigabe-Code
sowie deren Mehrfachnutzung durch verschiedene Personen ist ausdrücklich UNZULÄSSIG.
Please note ReadMe_zURLtoolV20.txt: contains the German and English description.
NOTE FOR EXISTING USERS:
If you have already received a serial number and activation code for version 1.0, you can reuse them directly!
They are valid for version 2.0 as well. Please do not submit a new request in this case.LEGAL NOTICE ON ACTIVATION:
Sharing the serial number and activation code, as well as their multiple use by different individuals, is strictly PROHIBITED.zURLtool goes to ESP32!
Zuerst wollte ich eine Android-App schreiben.
Außerdem war im Hinterstübchen immer noch die Idee für ein eigenständiges BT-MQTT-Gateway vorhanden.Dann dachte ich an Nebelkerzenwerfer mit Verschwörungstheorien, was mein Windows-Programm angeblich alles auf dem PC anstellen könnte.
Open-Source ist für mich in diesem Umfeld leider nicht mehr möglich, weil ich es nicht einsehe, dass meine Erkenntnisse und mein Code ungefragt übernommen werden, ohne dass auch nur eine einzige Namensnennung oder ein Danke erfolgt.Heute Mittag kam mir dann die Idee, eine zURLtool-Firmware für einen ESP32 mit integriertem Webserver zu schreiben.
In einer Schublade lag noch ein passendes ESP32-Board mit 4MB Flash.Also ab ans Proggen...
Ich habe eine einfache Prototyp-Benutzeroberfläche als Website erstellt (natürlich auch Smartphone-tauglich) und den Code für den ESP32 umgesetzt.
Die .bin-Datei wurde erstellt, kompiliert, geflasht und ... NICHTS.
Es wurde kein Access Point zur Verfügung gestellt und der Chip blieb stumm.
Dann kam mir der Gedanke an diese günstigen ESP32-Entwicklungsboards und deren Empfindlichkeit gegenüber Spannungsspitzen. Fehlende oder zu kleine Blockkondensatoren (C)?
In der Tat, das war das Problem! Ich habe zwei noch vorhandene Elkos auf die Schnelle hinten auf das Board gelötet: einen 220µF-Kondensator an die 3V3-Schiene und einen 10µF-Kondensator an die 5V-Leitung.
Dazu noch ein gutes 5V DC 2.4A Mean Well Hutschienen-Netzteil über ein altes Kabel mit dem Micro-USB-Stecker verbunden und ...
läuft! :-)
Es wird also wahrscheinlich demnächst eine zURLtool-Firmware für den ESP32 geben.
Damit ist für das Umschreiben der Geräte-Konfiguration kein Notebook mit Bluetooth, keine EXE und keine Zusatzsoftware mehr nötig.
Das eigene Heimnetzwerk, ein Smartphone oder ein beliebiger Rechner reichen dann völlig aus – zusammen mit einem ESP32, zwei Kondensatoren und einem 5V-Netzteil.
endlich schlafen :-)
Allen eine erholsame und gute Nacht ;-)
-
@Daniel-8
Alles klar, dann passt das ja perfekt für dein Setup :-)
Es ist auf jeden Fall gut, dass das für alle Mitleser hier im Thread dokumentiert ist.Sobald mit der Sonne morgens die MCU erwacht, läuft das Skript ja wie gewohnt weiter.
Ein zusätzliches Isolieren der Batterie(n) wäre zu empfehlen, wenn schon im Oktober nur 8°C erreicht werden.
03.11.2026
(Testgeräte HUB2000 / Hyper 2000 / 1600AC+ / 2400 ACpro)Technische Beobachtung in aktuellen Zendure-Firmware-Versionen:
Es fällt auf, dass das Verhalten bei (Cloud-)MQTT-Publishes angepasst wurde, was das Echtzeit-Streaming von Werten betrifft. Alle Beobachtungen beziehen sich hierbei auf die properties/report-Meldungen:
-
Früher: Sobald sich Werte von PV-Modulen oder Batterien änderten, wurden diese sofort per MQTT (in Echtzeit) im Report gemeldet.
-
Jetzt: Unabhängig von tatsächlichen Wertänderungen wird die properties/report-Meldung nun starr in einem festen Intervall von 5000 ms publiziert. Werte scheinen dort gesammelt übertragen zu werden.
-
Aktive Abfrage / externe Befehle: Werden explizite Anfragen oder Befehle an das Gerät gerichtet, erfolgt die Antwort-Veröffentlichung und Änderung – wie bisher – sofort.
-
HEMS-Ausnahme: Ist HEMS „in der App aktiviert“ und die Steuerung läuft über die Cloud, scheint es Ausnahmen von dieser Begrenzung zu geben. Zum Teil läuft es scheinbar wie zuvor, damit vermutlich schneller geregelt werden kann (Wertänderungen werden schneller gesendet als das Intervall).
edit 05.11.2026 10:15h
Ob bei deaktiviertem HEMS bei extrem drastischen Wertsprüngen zwischendurch doch ein Sofort-Publish vom Gerät getriggert wird,weiß ich (noch) nicht.
Ich kann es nur hoffen und werde das Verhalten weiter beobachten und versuchen, es in zwei Firmware-Versionen zu analysieren.-
bei wechselhafter PV-Leistung werden die Werte schneller via MQTT veröffentlicht (Sofort-Publish). Das Gerät reagiert demnach dynamisch auf starke Leistungsschwankungen, auch ohne aktives HEMS.
-
zusätzlich bisher unbekannter Schalter (enable/false) in der Firmware identifiziert. Der Status dieses Schalters lässt sich direkt über ein MQTT-Publish steuern.
edit-Ende
Die Anpassung dient vermutlich der Reduzierung des Traffics der Geräte zur Cloud und der Entlastung des ESP32.
Die aktuellen Firmware-Versionen von HUB2000, ace1500 und die letzte Firmware-Version vom Hyper < 2 (vor TLS) sind von dieser Änderung nach meinem Kenntnisstand und den vorhandenen Test-Geräten nicht betroffen.
-
-
03.11.2026
(Testgeräte HUB2000 / Hyper 2000 / 1600AC+ / 2400 ACpro)Technische Beobachtung in aktuellen Zendure-Firmware-Versionen:
Es fällt auf, dass das Verhalten bei (Cloud-)MQTT-Publishes angepasst wurde, was das Echtzeit-Streaming von Werten betrifft. Alle Beobachtungen beziehen sich hierbei auf die properties/report-Meldungen:
-
Früher: Sobald sich Werte von PV-Modulen oder Batterien änderten, wurden diese sofort per MQTT (in Echtzeit) im Report gemeldet.
-
Jetzt: Unabhängig von tatsächlichen Wertänderungen wird die properties/report-Meldung nun starr in einem festen Intervall von 5000 ms publiziert. Werte scheinen dort gesammelt übertragen zu werden.
-
Aktive Abfrage / externe Befehle: Werden explizite Anfragen oder Befehle an das Gerät gerichtet, erfolgt die Antwort-Veröffentlichung und Änderung – wie bisher – sofort.
-
HEMS-Ausnahme: Ist HEMS „in der App aktiviert“ und die Steuerung läuft über die Cloud, scheint es Ausnahmen von dieser Begrenzung zu geben. Zum Teil läuft es scheinbar wie zuvor, damit vermutlich schneller geregelt werden kann (Wertänderungen werden schneller gesendet als das Intervall).
edit 05.11.2026 10:15h
Ob bei deaktiviertem HEMS bei extrem drastischen Wertsprüngen zwischendurch doch ein Sofort-Publish vom Gerät getriggert wird,weiß ich (noch) nicht.
Ich kann es nur hoffen und werde das Verhalten weiter beobachten und versuchen, es in zwei Firmware-Versionen zu analysieren.-
bei wechselhafter PV-Leistung werden die Werte schneller via MQTT veröffentlicht (Sofort-Publish). Das Gerät reagiert demnach dynamisch auf starke Leistungsschwankungen, auch ohne aktives HEMS.
-
zusätzlich bisher unbekannter Schalter (enable/false) in der Firmware identifiziert. Der Status dieses Schalters lässt sich direkt über ein MQTT-Publish steuern.
edit-Ende
Die Anpassung dient vermutlich der Reduzierung des Traffics der Geräte zur Cloud und der Entlastung des ESP32.
Die aktuellen Firmware-Versionen von HUB2000, ace1500 und die letzte Firmware-Version vom Hyper < 2 (vor TLS) sind von dieser Änderung nach meinem Kenntnisstand und den vorhandenen Test-Geräten nicht betroffen.
Heute hatte ich wieder einen langen Tag.
Ein Zendure-Gerät und dafür extra einen Broker aufsetzen?
Jemand wollte sein Zendure-Gerät (mit TLS) cloudfrei betreiben und direkt mit dem ioBroker-MQTT-Adapter verbinden.
Bedingungen:
- Zendure-Gerät (TLS)soll sich mit MQTT-Adapter verbinden
- MQTT und zenSDK Steurung sollen möglich sein
- Cloudfrei
- auf keinen Fall extra einen eigenen Broker wie Mosquitto aufsetzen
- Setup sollte simpel, leicht änderbar und direkt einsatzbereit sein
- nichts kompliziertes
Dachte: nicht realisierbar.
Wo fängt man da an?Nach einigem Grübeln habe ich mir angeschaut was vorhanden ist und was genutzt werden kann und angefangen zu proggen.
Viele Stunden später....
Ergebnis: eine echte eierlegende Wollmilchsau:
TLS-Entschlüsselung und Plain-Brücke für ioBroker in einem.Das absolut Sensationelle daran:
Der ESP32 verhält sich wie ein Mosquitto-Broker (inklusive Echos und RAM-geschütztem Retain-Speicher) und das mit nur 4MB Flash.
Konnte dafür keine 3rd Party Libs verwenden.
Alle verfügbaren Libs hatten entweder Fehler, waren aufgebläht oder die Funktionen wurden nicht unterstützt.Also wieder ans Eingemachte....
Der Code baut nur auf den nackten Bordmitteln des ESP-IDF-Frameworks (bzw. Arduino-Core) auf.
Schlanker und effizienter geht es kaum.
Ich dachte selbst erst nicht, dass es klappt ohne PSRAM und mit nur 4MB Flash, aber das Ergebnis läuft stabil und sicher.
Funktionierendes Multi-User-System:
-
2x TLS-Clients (Port 8883): für bis zu zwei Zendure-Geräte.
-
3x Plain-Clients (Port 1883): ohne TLS, z. B. für den ioBroker-Adapter, MQTT-Explorer und MQTTX.
Ein separater MQTT-Broker wird damit komplett überflüssig.
Die Konfiguration (WLAN und TLS-Zugangsdaten) erfolgt einfach einmalig seriell über USB am Rechner, z.B. mit Arduino-Serial-Monitor oder PuTTY.Man kann im laufenden Betrieb:
• "setup" eingeben und schnell Daten ändern.
• "status" eingeben und man erhält Infos (siehe Bilder)
Also wurde nur kurz zURLtool benutzt und nun übernimmt ein alter Standard ESP32 mit 4MB flash (noch mit Micro-USB) den Broker.
Bild im Spoiler.
Einrichtung von Zendure-Gerät und ESP32-Broker komplett in ca. 10min.Wahnsinn.... Ziel erreicht!
Wieder so spät, hoffe Popcorn ist noch vorhanden ;-)
und wieder Allen eine erholsame und gute Nacht ;-)
-
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 AnmeldenSupport us
226
Online33.1k
Benutzer84.2k
Themen1.4m
Beiträge