Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2
-
Hallo @Daniel-8 ,
das lässt sich im Grunde mit Fakten auswerten:-
App-Fakt:
Wenn über die originale Zendure-App auf dem Smartphone keine Steuerung mehr möglich ist und die Werte dort starr einfrieren und nicht mehr aktualisiert werden, weißt Du sicher: Deine Internetsperre im Router ist aktiv und die Cloud-Verbindung ist gekappt. -
zenSDK-Fakt
Wenn trotz dieser aktiven Internetsperre Deine lokale zenSDK-Ansteuerung weiterhin unverändert schnell funktioniert, das Polling absolut plausible, frische Werte liefert und das Setzen von Parametern (wie Limits) sofort und ohne weitere Verzögerung durchgeht – UND JETZT KOMMT DER ENTSCHEIDENDE PUNKT:
Wenn Du beobachtest, dass der einlaufende timestamp (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet, das System aber trotzdem absolut stabil weiterläuft, dann hast Du die absolute Gewissheit:
Du besitzt eine Firmware-Version, die eine echte, isolierte lokale Steuerung zulässt, ohne sich bei blockierter Cloud intern aufzuhängen.
Wer eine Firmware-Version hat bei dem das System nach einer Zeit der Internetsperre träge wird und lokal bleiben möchte oder muss (z. B. Gartenhaus ohne Internetverbindung etc.) der muss eben den Weg über die DNS-Umleitung (z. B. Pi-hole / AdGuard) oder das Umschreiben der URL via Bluetooth wählen, damit der interne Kommunikations-Stack des Geräts nicht ins Leere läuft.
Liebe Grüße
maxclaudi
@maxclaudi [sagte]: (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet
Bei mir geht der JSON-Zeitstempel jetzt 37 s nach.
Ich habe vor einer Stunde das Intervall auf 2000 ms und den Timeout auf 1500 ms verringert: Bisher keine Probleme.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN42: N100 / 8 GB / 500 GB; Proxmox mit 2 VM (ioBroker / openCCU) -
-
@maxclaudi [sagte]: (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet
Bei mir geht der JSON-Zeitstempel jetzt 37 s nach.
Ich habe vor einer Stunde das Intervall auf 2000 ms und den Timeout auf 1500 ms verringert: Bisher keine Probleme.
@maxclaudi [sa
gte]: (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftetBei mir geht der JSON-Zeitstempel jetzt 37 s nach.
@paul53
Damit bist Du nun gesichert vollständig lokal, wenn es weiterhin so bleibt.
und der Zeitstempel weiter driftet. :-)Ich habe vor einer Stunde das Intervall auf 2000 ms und den Timeout auf 1500 ms verringert: Bisher keine Probleme.
Siehst Du, wie plötzlich Probleme verschwinden und der ESP32 nicht mehr überfordert wird :-)
Sobald der kleine ESP32-Chip nicht mehr ununterbrochen im Sekundentakt versuchen muss, die verschlüsselte Verbindung nach China aufzubauen, hat er plötzlich alle Rechenleistung der Welt frei, um Deine lokalen zenSDK-Befehle im Millisekundentakt abzuarbeiten -
Guten Morgen @paul53,
mir ging es hier primär um die technische Aufklärung zu dem Beitrag
@nograx sagte:
....Ich bin von Zendure angehalten worden mit dem Adapter bei den neuen Geräten die offiziell unterstützten Möglichkeiten zu nutzen. Und daran werde ich mich auch halten.Die offiziell unterstützten Möglichkeiten von Zendure beinhalten im zenSDK-Protokoll weder ein Cloud-Relay noch die unvollständige Manipulation von Modi wie HEMS über intransparente Funktionen.
Das halte ich technisch für riskanter – vor allem, wenn durch unvollständige Code-Basteleien Geräte-Befehle, Invoke-Methoden oder Modi verwendet werden, deren exakte Systemmatrix und Syntax gar nicht vollumfänglich bekannt sind.Zendure-Geräte sind zum Teil explizit für den Outdoor-, Camping- und Gartenhaus-Bereich konzipiert – Umgebungen, die oft weder über 230V Netzstrom noch über eine permanente Internetverbindung verfügen.
Zu Deiner Frage
@maxclaudi [sagte:
Es wird lediglich über den vorhandenen BLE-Konfigurationsmechanismus die MQTT-Serveradresse geändert, die das Gerät für seine Kommunikation verwendet.Damit bist du von der Überschrift "zenSDK local API" mittlerweile entfernt. Oder ist die Aktivierung der lokalen MQTT-Kommunikation Bestandteil des zenSDK?
Um das präzise zu beantworten:
Ja, die Aktivierung der lokalen MQTT-Kommunikation ist integraler Bestandteil des offiziellen zenSDK.Zendure dokumentiert genau diese RPC-Methoden zur lokalen Konfiguration transparent in den offiziellen Repositories Zendure/zenSDK.
Die Aktivierung erfolgt über exakt definierte API-Aufrufe wie:
POST /rpc Content-Type: application/json { "sn": "WOB1NHMAMXXXXX3", "method": "HA.Mqtt.SetConfig", "params": { "config": { "enable": true, "server": "192.168.50.48", "port":1883, "protocol":"mqtt", "username": "zendure", "password": "zendure" } } }sowie die MQTT status Abfrage:
GET /rpc?method=HA.Mqtt.GetStatusoder Get MQTT configuration
GET /rpc?method=HA.Mqtt.GetConfigAllerdings ist dieser von Zendure bereitgestellte lokale MQTT-Weg stark reglementiert und in der Übertragungsgeschwindigkeit gedrosselt.
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern.
Um mit diesen Versionen eine wirklich ruhige, stressfreie und vollständig lokale Steuerung zu betreiben, bietet der Weg über das lokale Bluetooth-Umschreiben der URL die sauberste Alternative.
In diesem Thread geht es mir um eine ganzheitliche Gesamtlösung:
Die zenSDK-Ansteuerung über mein Steuerungsskript, die Bereitstellung meines lokalen Konfigurations-Tools UND vor allem die praxisnahe, unkomplizierte Hilfe für Anfänger durch z. B. einfache Beispiel-Blockly-Skripte als Vorlage, wie die Realisierung einer 0-Einspeisung.Hierzu möchte ich ausdrücklich jeden herzlich einladen, aktiv mitzuwirken!
Ein solches Projekt lebt vom Austausch:
-
Jede(r) ist herzlich eingeladen Fragen zu stellen, Logiken zu testen und Rückmeldungen zu geben, wo Hürden liegen.
-
Erfahrene Experten und Skript-Profis – sehr gerne auch Du, @paul53 – sind eingeladen, eigene optimierte Skripte, Blocklys oder Ideen zur Verfügung zu stellen, Fehler im Code zu jagen, Timing-Probleme zu melden oder Verbesserungen einzubringen.
Wenn ein Nutzer mein Tool verwendet, um die Route auf einen eigenen, lokalen Broker umzubiegen, läuft das gesamte System m. M. n. – inklusive der lokalen zenSDK-API – um ein Vielfaches schneller, flüssiger und stabiler.
Man hat dann die freie Wahl, ob man das gedrosselte, offizielle MQTT, die zenSDK API nutzen möchte oder die uneingeschränkte MQTT-Transparenz.
Alternativ lässt sich auch pihole oder Adguard verwenden um die Cloud-URL auf eine lokale IP umzuleiten.
Falls der aktuelle Titel des Threads:
"Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2“
für die hier angebotene Gesamtlösung mittlerweile nicht mehr aussagekräftig genug oder unpräzise erscheint, freue ich mich über jeden konstruktiven Vorschlag zur Änderung.Da das Forum den Titel leider auf maximal 60 Zeichen beschränkt, ist es gar nicht so einfach, API, Skripte, Blocklys und Konfigurations-Tools in einer einzigen Zeile prägnant unterzubringen.
Liebe Grüße
maxclaudi
maxclaudi sagte:
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern....
Demnächst bekomme ich einen SolarFlow 2400 AC Pro zum Testen bereitgestellt.
Sobald das Gerät eintrifft und die Zeit es zulässt, werde ich mit einer extra alten Firmware-Version des 2400 AC Pro sowie dem vorhandenen 1600 AC Plus umfassende Testreihen durchführen.
Geplant sind tiefgehende Bluetooth- und WLAN-Analysen.
Danach erhalten die Geräte das Update auf die aktuellen Firmware-Versionen und werden im direkten Vergleich neu analysiert.
Weil diese Testreihen extrem umfangreich werden, ich die Daten präzise bewerten und die Ergebnisse detailliert dokumentieren muss, werde ich ab dann deutlich weniger Zeit haben.
Ich bitte daher jetzt schon um Verständnis und Berücksichtigung, wenn ich auf Fragen oder Anfragen künftig nicht mehr gewohnt schnell antworten kann.
Für das Vertrauen, den Gutschein und diese geniale Möglichkeit möchte ich mich an dieser Stelle ganz herzlich bedanken!
Viele Grüße
maxclaudi
-
-
Hallo @Daniel-8 ,
das lässt sich im Grunde mit Fakten auswerten:-
App-Fakt:
Wenn über die originale Zendure-App auf dem Smartphone keine Steuerung mehr möglich ist und die Werte dort starr einfrieren und nicht mehr aktualisiert werden, weißt Du sicher: Deine Internetsperre im Router ist aktiv und die Cloud-Verbindung ist gekappt. -
zenSDK-Fakt
Wenn trotz dieser aktiven Internetsperre Deine lokale zenSDK-Ansteuerung weiterhin unverändert schnell funktioniert, das Polling absolut plausible, frische Werte liefert und das Setzen von Parametern (wie Limits) sofort und ohne weitere Verzögerung durchgeht – UND JETZT KOMMT DER ENTSCHEIDENDE PUNKT:
Wenn Du beobachtest, dass der einlaufende timestamp (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet, das System aber trotzdem absolut stabil weiterläuft, dann hast Du die absolute Gewissheit:
Du besitzt eine Firmware-Version, die eine echte, isolierte lokale Steuerung zulässt, ohne sich bei blockierter Cloud intern aufzuhängen.
Wer eine Firmware-Version hat bei dem das System nach einer Zeit der Internetsperre träge wird und lokal bleiben möchte oder muss (z. B. Gartenhaus ohne Internetverbindung etc.) der muss eben den Weg über die DNS-Umleitung (z. B. Pi-hole / AdGuard) oder das Umschreiben der URL via Bluetooth wählen, damit der interne Kommunikations-Stack des Geräts nicht ins Leere läuft.
Liebe Grüße
maxclaudi
Hallo @Daniel-8 ,
das lässt sich im Grunde mit Fakten auswerten:- App-Fakt:
Wenn über die originale Zendure-App auf dem Smartphone keine Steuerung mehr möglich ist und die Werte dort starr einfrieren und nicht mehr aktualisiert werden, weißt Du sicher: Deine Internetsperre im Router ist aktiv und die Cloud-Verbindung ist gekappt.
Das ist bei mir so
- zenSDK-Fakt
Wenn trotz dieser aktiven Internetsperre Deine lokale zenSDK-Ansteuerung weiterhin unverändert schnell funktioniert, das Polling absolut plausible, frische Werte liefert und das Setzen von Parametern (wie Limits) sofort und ohne weitere Verzögerung durchgeht
Wenn ich setoutputLImit setzte dann dauert es schon eine gewisse Zeit bist outputlimit aktualiseirt ist. Aber das sind laut Zeitstempel Millisekunden und sollte denke ich.Siehe beide Screenshoots.
– UND JETZT KOMMT DER ENTSCHEIDENDE PUNKT:
Wenn Du beobachtest, dass der einlaufende timestamp (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet, das System aber trotzdem absolut stabil weiterläuft, dann hast Du die absolute Gewissheit:
Was meinst du mit JSON Zeitstempel? Den Datenpunkt timestamp bzw. timeUpdateTimestamp?
Du besitzt eine Firmware-Version, die eine echte, isolierte lokale Steuerung zulässt, ohne sich bei blockierter Cloud intern aufzuhängen.
Dann kann ich ja es mal so weiter laufen lassen mit dem ZenSDK Script ohne die DNS Umleitung
-
-
maxclaudi sagte:
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern....
Demnächst bekomme ich einen SolarFlow 2400 AC Pro zum Testen bereitgestellt.
Sobald das Gerät eintrifft und die Zeit es zulässt, werde ich mit einer extra alten Firmware-Version des 2400 AC Pro sowie dem vorhandenen 1600 AC Plus umfassende Testreihen durchführen.
Geplant sind tiefgehende Bluetooth- und WLAN-Analysen.
Danach erhalten die Geräte das Update auf die aktuellen Firmware-Versionen und werden im direkten Vergleich neu analysiert.
Weil diese Testreihen extrem umfangreich werden, ich die Daten präzise bewerten und die Ergebnisse detailliert dokumentieren muss, werde ich ab dann deutlich weniger Zeit haben.
Ich bitte daher jetzt schon um Verständnis und Berücksichtigung, wenn ich auf Fragen oder Anfragen künftig nicht mehr gewohnt schnell antworten kann.
Für das Vertrauen, den Gutschein und diese geniale Möglichkeit möchte ich mich an dieser Stelle ganz herzlich bedanken!
Viele Grüße
maxclaudi
maxclaudi sagte:
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern....
Demnächst bekomme ich einen SolarFlow 2400 AC Pro zum Testen bereitgestellt.
Sobald das Gerät eintrifft und die Zeit es zulässt, werde ich mit einer extra alten Firmware-Version des 2400 AC Pro sowie dem vorhandenen 1600 AC Plus umfassende Testreihen durchführen.
Geplant sind tiefgehende Bluetooth- und WLAN-Analysen.
Danach erhalten die Geräte das Update auf die aktuellen Firmware-Versionen und werden im direkten Vergleich neu analysiert.
Weil diese Testreihen extrem umfangreich werden, ich die Daten präzise bewerten und die Ergebnisse detailliert dokumentieren muss, werde ich ab dann deutlich weniger Zeit haben.
Ich bitte daher jetzt schon um Verständnis und Berücksichtigung, wenn ich auf Fragen oder Anfragen künftig nicht mehr gewohnt schnell antworten kann.
Für das Vertrauen, den Gutschein und diese geniale Möglichkeit möchte ich mich an dieser Stelle ganz herzlich bedanken!
Viele Grüße
maxclaudi
Bekommst du die von Zendure?
Solarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno
-
maxclaudi sagte:
Zudem versuchen ältere Firmware-Generationen der neuen Gerätegenerationen die zenSDK unterstützen, sich parallel ununterbrochen mit der Cloud zu verbinden.
Anscheinend erst mit neuesten Firmwareversionen wie bei Dir, soll das nicht mehr so sein.
Das kann ich (noch) nicht bestätigen, glaube es Dir aber gerne.Wer nicht updaten kann oder möchte, kann mit den älteren zenSDK Frimware-Versionen nicht vollständig lokal, isoliert steuern....
Demnächst bekomme ich einen SolarFlow 2400 AC Pro zum Testen bereitgestellt.
Sobald das Gerät eintrifft und die Zeit es zulässt, werde ich mit einer extra alten Firmware-Version des 2400 AC Pro sowie dem vorhandenen 1600 AC Plus umfassende Testreihen durchführen.
Geplant sind tiefgehende Bluetooth- und WLAN-Analysen.
Danach erhalten die Geräte das Update auf die aktuellen Firmware-Versionen und werden im direkten Vergleich neu analysiert.
Weil diese Testreihen extrem umfangreich werden, ich die Daten präzise bewerten und die Ergebnisse detailliert dokumentieren muss, werde ich ab dann deutlich weniger Zeit haben.
Ich bitte daher jetzt schon um Verständnis und Berücksichtigung, wenn ich auf Fragen oder Anfragen künftig nicht mehr gewohnt schnell antworten kann.
Für das Vertrauen, den Gutschein und diese geniale Möglichkeit möchte ich mich an dieser Stelle ganz herzlich bedanken!
Viele Grüße
maxclaudi
Bekommst du die von Zendure?
- Zum Zeitstempel (Timestamp):
Ja, genau. Ich meine den Datenpunkt timestamp im JSON-Objekt,das vom Gerät über die API geliefert wird.
Oder den Datenpunkt timeUpdate das den timestamp in lesbarer Zeit darstellt.
Wenn das Gerät komplett vom Internet isoliert ist, kann es die Uhrzeit nicht mehr synchronisieren.
Die interne Uhr läuft dann starr auf der eigenen Hardware-Basis weiter und fängt mit der Zeit an, leicht nachzugehen (zu driften).
Wenn das System trotz dieser Drift absolut flüssig läuft und Deine Limits in Millisekunden quittiert werden, läuft Deine Firmware-Version lokal stabil
und Du kannst es genau so weiterlaufen lassen.- Zur Bereitstellung des Testgeräts:
Ich habe im Nachgang die Korrespondenz noch einmal genauer geprüft und wurde auf eine entsprechende Vertraulichkeit (NDA / Confidentiality Notice) hingewiesen.
Bitte habt daher Verständnis, dass ich mich zu den Hintergründen der Bereitstellung nicht weiter öffentlich äußern werde.
- Zum Zeitstempel (Timestamp):
-
- Zum Zeitstempel (Timestamp):
Ja, genau. Ich meine den Datenpunkt timestamp im JSON-Objekt,das vom Gerät über die API geliefert wird.
Oder den Datenpunkt timeUpdate das den timestamp in lesbarer Zeit darstellt.
Wenn das Gerät komplett vom Internet isoliert ist, kann es die Uhrzeit nicht mehr synchronisieren.
Die interne Uhr läuft dann starr auf der eigenen Hardware-Basis weiter und fängt mit der Zeit an, leicht nachzugehen (zu driften).
Wenn das System trotz dieser Drift absolut flüssig läuft und Deine Limits in Millisekunden quittiert werden, läuft Deine Firmware-Version lokal stabil
und Du kannst es genau so weiterlaufen lassen.- Zur Bereitstellung des Testgeräts:
Ich habe im Nachgang die Korrespondenz noch einmal genauer geprüft und wurde auf eine entsprechende Vertraulichkeit (NDA / Confidentiality Notice) hingewiesen.
Bitte habt daher Verständnis, dass ich mich zu den Hintergründen der Bereitstellung nicht weiter öffentlich äußern werde.
- Zum Zeitstempel (Timestamp):
Ja, genau. Ich meine den Datenpunkt timestamp im JSON-Objekt,das vom Gerät über die API geliefert wird.
Oder den Datenpunkt timeUpdate das den timestamp in lesbarer Zeit darstellt.
Wenn das Gerät komplett vom Internet isoliert ist, kann es die Uhrzeit nicht mehr synchronisieren.
Die interne Uhr läuft dann starr auf der eigenen Hardware-Basis weiter und fängt mit der Zeit an, leicht nachzugehen (zu driften).
Wenn das System trotz dieser Drift absolut flüssig läuft und Deine Limits in Millisekunden quittiert werden, läuft Deine Firmware-Version lokal stabil
und Du kannst es genau so weiterlaufen lassen.Dann werde ich dies mal beobachten. Ob diese Zeit überhaupt mal abweicht von der systemzeit.
Ich werde es einfach mal so laufen lassen ohne umschreiben von dns. Wenn das Gerät als inselanlage läuft hat es ja oft auch keinen Internetzugang.
- Zur Bereitstellung des Testgeräts:
Ich habe im Nachgang die Korrespondenz noch einmal genauer geprüft und wurde auf eine entsprechende Vertraulichkeit (NDA / Confidentiality Notice) hingewiesen.
Bitte habt daher Verständnis, dass ich mich zu den Hintergründen der Bereitstellung nicht weiter öffentlich äußern werde.
Kein Problem. Ist auf jedenfall gut das du was zum testen bekommst und damit ja auch weitere Erkenntnisse sammeln kannst ohne an dein eigenes System gehen zu müssen.
Es kann sich ja nur positiv auswirken was du schon alles aufgeklärt hast hier.Vielen Dank nochmals.
- Zum Zeitstempel (Timestamp):
-
wann messt ihr den Zellendrift? Wie groß sollte der maximal sein?
Ich habe jetzt die Steuerung mal so aufgebaut, das er ab 3,45V bis 3,5V an jedem Akku mit 100 Watt lädt. Wenn er über 3,5V kommt, geht die ganze energie soweit es mir möglich ist mit meinen 800W ins Haus, so das ich dann auf 0W Ladung komme.
Bei 3,54V war der eine und bei 3,52V der andere auf 100% Soc.
-
-
Also misst du den Zelldrift direkt nach dem voll laden. Problem ist ich kann das mit dem 800Pro nicht so 100% steuern, da ich ja über pv modul lade und wenn halt noch zuviel runter kommt also über 800 Watt ist der Rest halt die ladeleistung. Werde es jetzt mal so laufen lassen oder eventuell die reduzierte Ladung schon vorher einsetzen lassen. Aber das ich bei 99% stoppe geht nicht. Dann hoffe ich das der drift weniger wird
-
Hallo @Daniel-8 ,
das lässt sich im Grunde mit Fakten auswerten:-
App-Fakt:
Wenn über die originale Zendure-App auf dem Smartphone keine Steuerung mehr möglich ist und die Werte dort starr einfrieren und nicht mehr aktualisiert werden, weißt Du sicher: Deine Internetsperre im Router ist aktiv und die Cloud-Verbindung ist gekappt. -
zenSDK-Fakt
Wenn trotz dieser aktiven Internetsperre Deine lokale zenSDK-Ansteuerung weiterhin unverändert schnell funktioniert, das Polling absolut plausible, frische Werte liefert und das Setzen von Parametern (wie Limits) sofort und ohne weitere Verzögerung durchgeht – UND JETZT KOMMT DER ENTSCHEIDENDE PUNKT:
Wenn Du beobachtest, dass der einlaufende timestamp (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet, das System aber trotzdem absolut stabil weiterläuft, dann hast Du die absolute Gewissheit:
Du besitzt eine Firmware-Version, die eine echte, isolierte lokale Steuerung zulässt, ohne sich bei blockierter Cloud intern aufzuhängen.
Wer eine Firmware-Version hat bei dem das System nach einer Zeit der Internetsperre träge wird und lokal bleiben möchte oder muss (z. B. Gartenhaus ohne Internetverbindung etc.) der muss eben den Weg über die DNS-Umleitung (z. B. Pi-hole / AdGuard) oder das Umschreiben der URL via Bluetooth wählen, damit der interne Kommunikations-Stack des Geräts nicht ins Leere läuft.
Liebe Grüße
maxclaudi
Vorläufige Hinweise:
Auszüge aus der Firmware-Analyse (ESP32-Core) demaskieren einen eigenständigen, parallelen Hintergrund-Dienst.
Neben dem bekannten MQTT-Steuerungskanal existiert ein separater, unabhänger HTTP-Client (log-c-tiny_0.1.0), der fest in den Maschinencode einkompiliert ist.
Der technische Befund (siehe ASCII-Auszug des Speichers; die unleserlichen Rohdaten-Spalten wurden zur besseren Übersicht und aus Datenschutzgründen entfernt):
Die Firmware enthält einen dedizierten REST-API-Endpunkt für den Export von Telemetrie-, Fehler- und Systemdaten an das europäische Alibaba-Cloud-Rechenzentrum:
https://zendure-device-log-eu.eu-central-1.log.aliyuncs.comDieser Dienst läuft als eigenständige Task.
Das bedeutet:
Wer in den Filtereinstellungen seines Routers lediglich Standard-MQTT-Serverdev.zendure.tech zen-iot.com mq.zen-iot.com mqtteu.zen-iot.com app.zendure.tech app.zendure.tech/asetc. sperrt, blockiert zwar die App-Steuerung und MQTT, verhindert jedoch nicht den zusätzlichen Datenabfluss über diesen expliziten HTTPS-Kanal.
Das Gerät streamt weiterhin Log-Pakete nach draußen.
Was ist zu tun, wenn man das nicht möchte?
Um den ungewollten Datenverkehr zu unterbinden, müssen in der Firewall des Routers (z. B. in den Filterregeln der Fritz!Box) für die IP-Adresse des Zendure-Geräts mindestens zusätzlich folgende Domains auf die Blacklist (Sperrliste) gesetzt werden:- Zendure-Logstore:
zendure-device-log-eu.eu-central-1.log.aliyuncs.com- Alibaba-Basis-Server:
eu-central-1.log.aliyuncs.com
IOTState
Der Datenpunkt bzw. Key verwendet folgende Werte:
0: Netzwerkverbindung getrennt
1: Netzwerk wird konfiguriert
2: Verbindung erfolgreichDies fand ich bisher nicht öffentlich und ist auch wieder für die Kopierer interessant. Der State wurde noch nirgendwo exakt beschrieben und auch fälschlicher Weise als boolean interpretiert.
Es wurde mir auch Original bestätigt:
1: 配网中 2:连接成功 0: 网络断开
Getestet wurden die alte Firmware Version: V1.0.2 mit API2 und die neue Firmwareversion: V2.0.x bzw. V2.0.2 mit API3
Analysen werden fortgesetzt.
Aus den bisherigen Erkenntnissen kann ich das Update zumindest bei den Geräten:
- Hyper 2000 (außer man möchte kein TLS!)
- 1600 AC Plus
- 2400 AC Pro
nur empfehlen.
Speziell bei den 2 letzteren, neuen Geräten kann ich nur dazu raten.
edit/PS: 15:07h
Internes SmartMeter-Abfrageintervall der Regelschleife (LCN-srv).Ein tieferer Blick in den Maschinencode der lokalen Steuerungstask LCN-srv (Local Control Network Service) legt die exakte Taktung offen, mit der der SolarFlow angebundene SmartMeter abfragt.
<edit 27.10.2026 Datenschutz; entfernt.>
technische Fakt:
Sobald ein SmartMeter (z. B. Shelly 3EM, Zendure Satellite etc.) offiziell im System registriert ist, schaltet die Firmware auf ein einkompiliertes Standard-Intervall von exakt 2,059 Sekunden (2059 Millisekunden).Dieses Intervall ist hardcodiert und kann über die Zendure-App von außen nicht beeinflusst oder verändert werden.
Das ist technisch auch absolut sinnvoll, da direkt danach im Code die Berechnung des gleitenden Durchschnitts des Hausverbrauchs erfolgt:<edit 27.10.2026 Datenschutz; entfernt.>
Praxis-Tipp für Entwickler lokaler Tools (z.B. ioBroker / Skripte):
Da die interne Hauptschleife der Firmware ohnehin in diesem starren ~2-Sekunden-Takt operiert, bringt es absolut keinen Vorteil, das Gerät lokal im kleinsten Sekundentakt mit Abfragen zu bombardieren.
Ein lokales Abfrage- oder Sende-Intervall von 2 Sekunden läuft absolut synchron zur internen Hardware-Regelung des SolarFlow und schont die Ressourcen des ESP32-Controllers.Zuzüglich weiterer hardwarebedingter und Netzwerk-Latenzen macht es meiner Meinung nach keinen Sinn, im kleinsten Sekundenbereich jedem einzelnen Watt hinterherzujagen.
edit 15:21h zURLtool und Zendure Smartmeter 3CT
Es wird in einiger Zeit ein Update von zURLtool mit erweiterten, geprüften Funktionsumfang geben.Mit der bisherigen Version ist es jetzt schon möglich das
Zendure Smartmeter 3CT umzuschreiben.Dazu bekam ich schon feedbacks:
...also tried zURLtool on zendure smart meter 3CT and it worked. -
-
Vorläufige Hinweise:
Auszüge aus der Firmware-Analyse (ESP32-Core) demaskieren einen eigenständigen, parallelen Hintergrund-Dienst.
Neben dem bekannten MQTT-Steuerungskanal existiert ein separater, unabhänger HTTP-Client (log-c-tiny_0.1.0), der fest in den Maschinencode einkompiliert ist.
Der technische Befund (siehe ASCII-Auszug des Speichers; die unleserlichen Rohdaten-Spalten wurden zur besseren Übersicht und aus Datenschutzgründen entfernt):
Die Firmware enthält einen dedizierten REST-API-Endpunkt für den Export von Telemetrie-, Fehler- und Systemdaten an das europäische Alibaba-Cloud-Rechenzentrum:
https://zendure-device-log-eu.eu-central-1.log.aliyuncs.comDieser Dienst läuft als eigenständige Task.
Das bedeutet:
Wer in den Filtereinstellungen seines Routers lediglich Standard-MQTT-Serverdev.zendure.tech zen-iot.com mq.zen-iot.com mqtteu.zen-iot.com app.zendure.tech app.zendure.tech/asetc. sperrt, blockiert zwar die App-Steuerung und MQTT, verhindert jedoch nicht den zusätzlichen Datenabfluss über diesen expliziten HTTPS-Kanal.
Das Gerät streamt weiterhin Log-Pakete nach draußen.
Was ist zu tun, wenn man das nicht möchte?
Um den ungewollten Datenverkehr zu unterbinden, müssen in der Firewall des Routers (z. B. in den Filterregeln der Fritz!Box) für die IP-Adresse des Zendure-Geräts mindestens zusätzlich folgende Domains auf die Blacklist (Sperrliste) gesetzt werden:- Zendure-Logstore:
zendure-device-log-eu.eu-central-1.log.aliyuncs.com- Alibaba-Basis-Server:
eu-central-1.log.aliyuncs.com
IOTState
Der Datenpunkt bzw. Key verwendet folgende Werte:
0: Netzwerkverbindung getrennt
1: Netzwerk wird konfiguriert
2: Verbindung erfolgreichDies fand ich bisher nicht öffentlich und ist auch wieder für die Kopierer interessant. Der State wurde noch nirgendwo exakt beschrieben und auch fälschlicher Weise als boolean interpretiert.
Es wurde mir auch Original bestätigt:
1: 配网中 2:连接成功 0: 网络断开
Getestet wurden die alte Firmware Version: V1.0.2 mit API2 und die neue Firmwareversion: V2.0.x bzw. V2.0.2 mit API3
Analysen werden fortgesetzt.
Aus den bisherigen Erkenntnissen kann ich das Update zumindest bei den Geräten:
- Hyper 2000 (außer man möchte kein TLS!)
- 1600 AC Plus
- 2400 AC Pro
nur empfehlen.
Speziell bei den 2 letzteren, neuen Geräten kann ich nur dazu raten.
edit/PS: 15:07h
Internes SmartMeter-Abfrageintervall der Regelschleife (LCN-srv).Ein tieferer Blick in den Maschinencode der lokalen Steuerungstask LCN-srv (Local Control Network Service) legt die exakte Taktung offen, mit der der SolarFlow angebundene SmartMeter abfragt.
<edit 27.10.2026 Datenschutz; entfernt.>
technische Fakt:
Sobald ein SmartMeter (z. B. Shelly 3EM, Zendure Satellite etc.) offiziell im System registriert ist, schaltet die Firmware auf ein einkompiliertes Standard-Intervall von exakt 2,059 Sekunden (2059 Millisekunden).Dieses Intervall ist hardcodiert und kann über die Zendure-App von außen nicht beeinflusst oder verändert werden.
Das ist technisch auch absolut sinnvoll, da direkt danach im Code die Berechnung des gleitenden Durchschnitts des Hausverbrauchs erfolgt:<edit 27.10.2026 Datenschutz; entfernt.>
Praxis-Tipp für Entwickler lokaler Tools (z.B. ioBroker / Skripte):
Da die interne Hauptschleife der Firmware ohnehin in diesem starren ~2-Sekunden-Takt operiert, bringt es absolut keinen Vorteil, das Gerät lokal im kleinsten Sekundentakt mit Abfragen zu bombardieren.
Ein lokales Abfrage- oder Sende-Intervall von 2 Sekunden läuft absolut synchron zur internen Hardware-Regelung des SolarFlow und schont die Ressourcen des ESP32-Controllers.Zuzüglich weiterer hardwarebedingter und Netzwerk-Latenzen macht es meiner Meinung nach keinen Sinn, im kleinsten Sekundenbereich jedem einzelnen Watt hinterherzujagen.
edit 15:21h zURLtool und Zendure Smartmeter 3CT
Es wird in einiger Zeit ein Update von zURLtool mit erweiterten, geprüften Funktionsumfang geben.Mit der bisherigen Version ist es jetzt schon möglich das
Zendure Smartmeter 3CT umzuschreiben.Dazu bekam ich schon feedbacks:
...also tried zURLtool on zendure smart meter 3CT and it worked.Getestet wurden die alte Firmware Version: V1.0.2 mit API2 und die neue Firmwareversion: V2.0.x bzw. V2.0.2 mit API3
Analysen werden fortgesetzt.
Aus den bisherigen Erkenntnissen kann ich das Update zumindest bei den Geräten:
Hyper 2000 (außer man möchte kein TLS!)
1600 AC Plus
2400 AC Pro
nur empfehlen.
Speziell bei den 2 letzteren, neuen Geräten kann ich nur dazu raten.Kannst du die 2.0.2 auch für den 800 Pro empfehlen?
Im Moment läuft bei mir noch 2.0.1Solarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno
-
Getestet wurden die alte Firmware Version: V1.0.2 mit API2 und die neue Firmwareversion: V2.0.x bzw. V2.0.2 mit API3
Analysen werden fortgesetzt.
Aus den bisherigen Erkenntnissen kann ich das Update zumindest bei den Geräten:
Hyper 2000 (außer man möchte kein TLS!)
1600 AC Plus
2400 AC Pro
nur empfehlen.
Speziell bei den 2 letzteren, neuen Geräten kann ich nur dazu raten.Kannst du die 2.0.2 auch für den 800 Pro empfehlen?
Im Moment läuft bei mir noch 2.0.1@Daniel-8
Ja.
Bzw. obwohl zum Teil unterschiedliche Firmware-Versionen bei diversen Geräten wie z.B. V2.0.2 in der App gemeldet wurden, ist die eigentlichemodule-ESP32-Firmware: V2.0.59Aber auch die master-, AC- und BMS- Firmware ist im Update enthalten.
Sollte jetzt ein Update möglich sein und Du schon auf 2.x bist, würde ich alle Updates machen.
Wie es nach einiger Zeit bei neuen Updates in der Zukunft aussieht, kann man nicht vorhersagen.
Zum aktuellen Zeitpunkt sehe ich im Vergleich nur Positives.
Aber die Analysen sind umfangreich und nicht beendet. -
Vorläufige Hinweise:
Auszüge aus der Firmware-Analyse (ESP32-Core) demaskieren einen eigenständigen, parallelen Hintergrund-Dienst.
Neben dem bekannten MQTT-Steuerungskanal existiert ein separater, unabhänger HTTP-Client (log-c-tiny_0.1.0), der fest in den Maschinencode einkompiliert ist.
Der technische Befund (siehe ASCII-Auszug des Speichers; die unleserlichen Rohdaten-Spalten wurden zur besseren Übersicht und aus Datenschutzgründen entfernt):
Die Firmware enthält einen dedizierten REST-API-Endpunkt für den Export von Telemetrie-, Fehler- und Systemdaten an das europäische Alibaba-Cloud-Rechenzentrum:
https://zendure-device-log-eu.eu-central-1.log.aliyuncs.comDieser Dienst läuft als eigenständige Task.
Das bedeutet:
Wer in den Filtereinstellungen seines Routers lediglich Standard-MQTT-Serverdev.zendure.tech zen-iot.com mq.zen-iot.com mqtteu.zen-iot.com app.zendure.tech app.zendure.tech/asetc. sperrt, blockiert zwar die App-Steuerung und MQTT, verhindert jedoch nicht den zusätzlichen Datenabfluss über diesen expliziten HTTPS-Kanal.
Das Gerät streamt weiterhin Log-Pakete nach draußen.
Was ist zu tun, wenn man das nicht möchte?
Um den ungewollten Datenverkehr zu unterbinden, müssen in der Firewall des Routers (z. B. in den Filterregeln der Fritz!Box) für die IP-Adresse des Zendure-Geräts mindestens zusätzlich folgende Domains auf die Blacklist (Sperrliste) gesetzt werden:- Zendure-Logstore:
zendure-device-log-eu.eu-central-1.log.aliyuncs.com- Alibaba-Basis-Server:
eu-central-1.log.aliyuncs.com
IOTState
Der Datenpunkt bzw. Key verwendet folgende Werte:
0: Netzwerkverbindung getrennt
1: Netzwerk wird konfiguriert
2: Verbindung erfolgreichDies fand ich bisher nicht öffentlich und ist auch wieder für die Kopierer interessant. Der State wurde noch nirgendwo exakt beschrieben und auch fälschlicher Weise als boolean interpretiert.
Es wurde mir auch Original bestätigt:
1: 配网中 2:连接成功 0: 网络断开
Getestet wurden die alte Firmware Version: V1.0.2 mit API2 und die neue Firmwareversion: V2.0.x bzw. V2.0.2 mit API3
Analysen werden fortgesetzt.
Aus den bisherigen Erkenntnissen kann ich das Update zumindest bei den Geräten:
- Hyper 2000 (außer man möchte kein TLS!)
- 1600 AC Plus
- 2400 AC Pro
nur empfehlen.
Speziell bei den 2 letzteren, neuen Geräten kann ich nur dazu raten.
edit/PS: 15:07h
Internes SmartMeter-Abfrageintervall der Regelschleife (LCN-srv).Ein tieferer Blick in den Maschinencode der lokalen Steuerungstask LCN-srv (Local Control Network Service) legt die exakte Taktung offen, mit der der SolarFlow angebundene SmartMeter abfragt.
<edit 27.10.2026 Datenschutz; entfernt.>
technische Fakt:
Sobald ein SmartMeter (z. B. Shelly 3EM, Zendure Satellite etc.) offiziell im System registriert ist, schaltet die Firmware auf ein einkompiliertes Standard-Intervall von exakt 2,059 Sekunden (2059 Millisekunden).Dieses Intervall ist hardcodiert und kann über die Zendure-App von außen nicht beeinflusst oder verändert werden.
Das ist technisch auch absolut sinnvoll, da direkt danach im Code die Berechnung des gleitenden Durchschnitts des Hausverbrauchs erfolgt:<edit 27.10.2026 Datenschutz; entfernt.>
Praxis-Tipp für Entwickler lokaler Tools (z.B. ioBroker / Skripte):
Da die interne Hauptschleife der Firmware ohnehin in diesem starren ~2-Sekunden-Takt operiert, bringt es absolut keinen Vorteil, das Gerät lokal im kleinsten Sekundentakt mit Abfragen zu bombardieren.
Ein lokales Abfrage- oder Sende-Intervall von 2 Sekunden läuft absolut synchron zur internen Hardware-Regelung des SolarFlow und schont die Ressourcen des ESP32-Controllers.Zuzüglich weiterer hardwarebedingter und Netzwerk-Latenzen macht es meiner Meinung nach keinen Sinn, im kleinsten Sekundenbereich jedem einzelnen Watt hinterherzujagen.
edit 15:21h zURLtool und Zendure Smartmeter 3CT
Es wird in einiger Zeit ein Update von zURLtool mit erweiterten, geprüften Funktionsumfang geben.Mit der bisherigen Version ist es jetzt schon möglich das
Zendure Smartmeter 3CT umzuschreiben.Dazu bekam ich schon feedbacks:
...also tried zURLtool on zendure smart meter 3CT and it worked.zURLtool Zendure Smart Plug Pro
können auch mit zURLTool umgeschrieben und per MQTT gesteuert werden.
Persönlich mag ich die Smart Plug Pro nicht, u. a. wegen des schlechten WLAN-Empfangs und einiger Exemplare, die zu viele Fehlfunktionen haben.
Dazu kann man die Rezensionen und Kommentare auf Amazon und der Herstellerseite lesen.zURLtool TLS
Wird damit der DNS auf eine andere DNS oder IP umgeschrieben, funktioniert die Zertifikatskette mit Keys.
Aktuell ist es so, dass dann die Zertifikatsgültigkeiten (Beginn 2020 / Ende 2030) nicht geprüft werden.
Tatsächlich ist und wäre das auch schwer realisierbar.
Zumindest meine Geräte haben sich auch mit gesetztem Datum von 1999 und 2041 verbunden.
Das Gerät im Auslieferungszustand „kann“ eine Zeit von 1970 haben.
Die Zeit wird per Cloud bzw. Broker und/oder HTTPS synchronisiert.
Das kann und wird auch erst nach erfolgter MQTT(S)-Verbindung über TLS und Registrierung der Geräte vorgenommen.
Setzt man einen Broker als Bridge ein, dann werden auch Geräte, die kein TLS unterstützen, über TLS verbunden.
Wie z. B. Hub2000, ace1500.Garantie:
- Solange Variablen verändert werden, die im System für den Nutzer oder das System-Setup vorgesehen sind (z. B. Server-URLs, IDs, MQTT-Pfade), ist das rechtlich wie eine Konfiguration zu werten. Davon fängt kein Gerät an zu brennen!
- Rechtliche Nuance: Sollte ein Firmware-Mod jedoch Schutzmechanismen aushebeln (z. B. Ladeströme oder Temperaturlimits manipulieren), könnte im schlimmsten Fall die Betriebserlaubnis (CE-Konformität) erlöschen. Da es sich beim zURLtool aber ausschließlich um das Setzen von Serververbindungen (URLs/Broker) und IDs handelt, führt ein Ändern von dafür vorgesehenen Variablen zu keinem Brand – die Brandgefahr ist hier ein reines Schreckgespenst.
Beim Umschreiben von Variablen verliert man keine gesetzliche Gewährleistung. Alles, was über Gesetze hinausgeht, sind freiwillige Leistungen des Herstellers; diese können, müssen aber nicht gewährt werden.
Lokale API ein- und ausschaltbar
Mit Cloud-Ersatz-Broker (lokaler Broker statt Cloud) kann localAPIenable aus- und eingeschaltet werden.
Wenn es ausgeschaltet ist, ist der ESP zusätzlich entlastet und ein Steuern über zenSDK ist nicht möglich.
Erfolgreiche Umsetzung nach Firmware-Analyse (erste öffentliche Dokumentation): Für die Aktivierung von 'localAPIenable' ist kein vorheriges Ein-/Ausschalten von HEMS in der App erforderlich; der Vorgang lässt sich alternativ via MQTT nicht nur Einschalten sondern nach Belieben ein- und ausschalten.localAPIEnable eingeschaltet:
localAPIEnable ausgeschaltet:
localAPIEnable wieder eingeschaltet:
Cloudless:
-
Zeitsynchronisation über MQTT möglich. Über NTP und zusätzliches Skript.
Entweder reales oder auch berechnetes, willkürliches Datum und Zeit.
Ist aber aufgrund von zURLTool nicht nötig, weil die Zertifikatsgültigkeit dann nicht geprüft wird. -
Inbetriebnahme eines neuen Geräts.
Es ist jederzeit möglich, mittels zURLTool ein Gerät sofort, lokal ohne Account und ohne App in Betrieb zu nehmen und zu steuern.
Sowohl über MQTT-Broker als auch per zenSDK. Für zenSDK muss die lokale API aktiviert sein / werden.
Reset:
Es ist möglich, ein Zendure-Gerät über MQTT oder BT auf den Auslieferungszustand zurückzusetzen.
Diese Option wird im Update von zURLtool 2.0 dch implementiert sein.
Achtung: Wenn ein Reset zum Verkauf des Geräts ausgeführt werden soll und/oder man es nicht mehr in der Cloud auf sich registriert haben möchte, muss das Gerät zusätzlich in der App entfernt werden!
Das bisherige setzen des WIFI MODE wie in Version 1.0 ist nicht mehr nötig.
Das WiFi wird gescannt und bei Auswahl des WiFi wird beim übernehmen automatisch der richtige Mode gesetzt.Token:
Bisherige BT-Tools haben Fehler und verwend(et)en einen nicht richtigen Token.
Der erfundene Token wird nur bei einigen „älteren“ Geräten – ohne Probleme – akzeptiert.
Richtig und empfehlenswert ist er nicht.
Aus verständlichen Gründen kann und werde ich nicht weiter darauf eingehen.userId
wird bei Account-Erstellung von der Cloud erstellt und zugewiesen. Berechnet wird sie weder von der App noch durch die Firmware.
Sie wird einmalig gesetzt und danach nur ausgelesen und verwendet. Ebenso die consumerId, die nach "bisherigen" Analysen identisch mit der userId ist.Wird ein Gerät lokal oder mit Cloud-Verbindung in Betrieb genommen, ohne dass ein Account generiert wurde oder die ID fehlerhaft ist, dann wird eine Universal-ID als Fallback akzeptiert.
Für lokalen Betrieb ausreichend.
Bei vorhandenem Cloud- und App-Account mit Benutzername und Passwort und evtl. gleichzeitigem Betrieb mit Cloud ist es besser, die richtige, zugewiesene userId bei allen vorhandenen Geräten zu verwenden.Die userId kann nur über HTTP(S) gezielt, direkt und sofort abgerufen werden.
zURLtool nutzt beim Schreiben eine gültige Universal-Fallback-userId.
Das ist ausreichend. Aber m. M. n. sinnvoll und besser ist es, die explizit zugewiesene userId zu verwenden, um dem Original vollständig zu entsprechen.Dazu habe ich ein neues Tool geschrieben: zAppEmulationDeviceInfo
Dabei gibt man in der GUI von der App die Zugangsdaten ein oder in:
deviceInfoConfig.ini; zAppEmulationDeviceInfo ; example: ; ; [ACCOUNT] ; EMAIL = user123@gmail.com ; PASSWORD = tOpS3kRet17090811Bc74 ; [ACCOUNT] EMAIL = user123@gmail.com PASSWORD = tOpS3kRet17090811Bc74
zAppEmulationDeviceInfo emuliert die App und führt einen Request aus.
Die Antwort steht dann im Textfeld und speichert die wichtigsten Daten in der Datei: Device-List.txtEs handelt sich hierbei NICHT um die Standard-Device-List. Es sind viel mehr Daten vorhanden, die für die App vorgesehen sind.
HINWEIS: zAppEmulationDeviceInfo verbindet sich über HTTP(S) mit der Cloud, wie die eigentliche App, und ruft nur einmalig die erforderlichen Daten ab.
Mehr nicht.
Es kann und soll gerne ein Virenscan erfolgen!
Wenn man dem Tool wegen der Zugangsdaten nicht vertraut, kann man auch temporär sein Account-Passwort dafür ändern.zAppEmulationDeviceInfo benötigt eine Seriennummer und einen Activationcode.
Wer bereits zURLtool verwendet, kann die Seriennummer und den Freischaltcode von zURLtool verwenden.
Bzw. zAppEmulationDeviceInfo kann direkt ausgeführt werden, wenn zURLtool schon verwendet wird.
Man kann User-E-Mail und Passwort händisch in der GUI eingeben oder vorbelegen in der Datei: deviceInfoConfig.ini; zAppEmulationDeviceInfo ; example: ; ; [ACCOUNT] ; EMAIL = userAccount@gmail.com ; PASSWORD = tOpS3kRet17090811Bc74 ; [ACCOUNT] EMAIL = userAccount@gmail.com PASSWORD = tOpS3kRet17090811Bc74Wenn die consumerId ausgelesen wurde und man seine Geräte auf seine originale, von der Cloud zugewiesene userID setzen möchte, dann kann die bisherige zURLtool-Version das bereits.
zURLtool wurde schon dafür vorbereitet.
In der Datei: config.ini; config.ini zURLtool (c) maxclaudi 2026 ; Für WiFi SSID und PASSWORD bitte keine Leerzeichen, Umlaute etc. verwenden ; Broker: Bitte nur reine IP oder DNS eingeben. Kein ":" und kein Port. ; Der Port ist in der Firmware fest hinterlegt. Entweder Port:1883 ohne TLS oder Port 8883 mit TLS. ; TLS-Verbindungen können nur mit gültigen Zertif. / Keys verwendet werden. ; ; MODE = WLAN-Sicherheitsmodus ; 3 = WPA2-PSK (Standard) ; 4 = WPA/WPA2-PSK ; 5 = WPA2-Enterprise ; 6 = WPA3-PSK ; 7 = WPA2/WPA3-PSK ; Gültige Werte: 3-7; bei fehlendem/ungültigem Wert wird automatisch 3 verwendet. ; MODE = 3 ; ; Zurück zur Cloud: ; BROKER = mq.zen-iot.com ; ; Beispiele: ; [WIFI] ; SSID = meinWLAN ; PASSWORD = tOpS3kRet17090811Bc74 ; MODE = 3 ; ; [MQTT] ; BROKER = 192.168.12.200 ; MODE = 3 ; [WIFI] SSID = meinWLAN PASSWORD = tOpS3kRet17090811Bc74 MODE = 3 EXTRA = <userID> [MQTT] BROKER = 192.168.12.200 ;BROKER = mq.zen-iot.comStatt "<userId>" die tatsächlich abgefragte userId einfügen.
Beispiel:EXTRA = 43521Wenn consumerId in EXTRA angeben wird, überträgt das zURLtool genau diese Nummer als lokale userId auf das Gerät.
Dadurch wird sichergestellt, dass die lokale Broker-Konfiguration exakt mit der Identität übereinstimmt, die von in der Cloud registrierten Geräten erwartet wird; auf diese Weise werden jegliche internen Diskrepanzen bei der Autorisierung auf Chip-Ebene vollständig beseitigt.
Wird das zURLtool ohne das Feld EXTRA verwendet, kommt eine gültige, generische Fallback-userId zum Einsatz.
Dies funktioniert wie vorgesehen, da sie als universelle userId akzeptiert wird.
Sie stimmt jedoch nicht mit der spezifischen userId überein, die von der Cloud für den jeweiligen Benutzer generiert wurde.Auch wenn die universelle Fallback-userId funktioniert, ist es meiner Meinung nach sinnvoller, die von der Cloud zugewiesene userId zu verwenden.
Die Cloud-basierte userId wird üblicherweise erst bei der Einrichtung eines Kontos erstellt.Der Fallback-Mechanismus ist für die Verbindung zur Cloud gedacht, wenn das Gerät vollständig offline betrieben wird oder die userId ungültig ist.
Da das zURLtool nur vorhandene, bekannte oder vordefinierte Werte setzen kann – und während der Einrichtung weder über eine HTTP(S)-Verbindung verfügt noch weiß, ob ein Konto existiert –, wird standardmäßig die universelle Fallback-userId verwendet, wenn das Feld EXTRA weggelassen wird oder einen ungültigen Wert enthält.
Download zAppEmulationDeviceInfo in 3 Teilen:
zAppEmulationDeviceInfo.zip
zAppEmulationDeviceInfo.z01
zAppEmulationDeviceInfo.z02 -
zURLtool Zendure Smart Plug Pro
können auch mit zURLTool umgeschrieben und per MQTT gesteuert werden.
Persönlich mag ich die Smart Plug Pro nicht, u. a. wegen des schlechten WLAN-Empfangs und einiger Exemplare, die zu viele Fehlfunktionen haben.
Dazu kann man die Rezensionen und Kommentare auf Amazon und der Herstellerseite lesen.zURLtool TLS
Wird damit der DNS auf eine andere DNS oder IP umgeschrieben, funktioniert die Zertifikatskette mit Keys.
Aktuell ist es so, dass dann die Zertifikatsgültigkeiten (Beginn 2020 / Ende 2030) nicht geprüft werden.
Tatsächlich ist und wäre das auch schwer realisierbar.
Zumindest meine Geräte haben sich auch mit gesetztem Datum von 1999 und 2041 verbunden.
Das Gerät im Auslieferungszustand „kann“ eine Zeit von 1970 haben.
Die Zeit wird per Cloud bzw. Broker und/oder HTTPS synchronisiert.
Das kann und wird auch erst nach erfolgter MQTT(S)-Verbindung über TLS und Registrierung der Geräte vorgenommen.
Setzt man einen Broker als Bridge ein, dann werden auch Geräte, die kein TLS unterstützen, über TLS verbunden.
Wie z. B. Hub2000, ace1500.Garantie:
- Solange Variablen verändert werden, die im System für den Nutzer oder das System-Setup vorgesehen sind (z. B. Server-URLs, IDs, MQTT-Pfade), ist das rechtlich wie eine Konfiguration zu werten. Davon fängt kein Gerät an zu brennen!
- Rechtliche Nuance: Sollte ein Firmware-Mod jedoch Schutzmechanismen aushebeln (z. B. Ladeströme oder Temperaturlimits manipulieren), könnte im schlimmsten Fall die Betriebserlaubnis (CE-Konformität) erlöschen. Da es sich beim zURLtool aber ausschließlich um das Setzen von Serververbindungen (URLs/Broker) und IDs handelt, führt ein Ändern von dafür vorgesehenen Variablen zu keinem Brand – die Brandgefahr ist hier ein reines Schreckgespenst.
Beim Umschreiben von Variablen verliert man keine gesetzliche Gewährleistung. Alles, was über Gesetze hinausgeht, sind freiwillige Leistungen des Herstellers; diese können, müssen aber nicht gewährt werden.
Lokale API ein- und ausschaltbar
Mit Cloud-Ersatz-Broker (lokaler Broker statt Cloud) kann localAPIenable aus- und eingeschaltet werden.
Wenn es ausgeschaltet ist, ist der ESP zusätzlich entlastet und ein Steuern über zenSDK ist nicht möglich.
Erfolgreiche Umsetzung nach Firmware-Analyse (erste öffentliche Dokumentation): Für die Aktivierung von 'localAPIenable' ist kein vorheriges Ein-/Ausschalten von HEMS in der App erforderlich; der Vorgang lässt sich alternativ via MQTT nicht nur Einschalten sondern nach Belieben ein- und ausschalten.localAPIEnable eingeschaltet:
localAPIEnable ausgeschaltet:
localAPIEnable wieder eingeschaltet:
Cloudless:
-
Zeitsynchronisation über MQTT möglich. Über NTP und zusätzliches Skript.
Entweder reales oder auch berechnetes, willkürliches Datum und Zeit.
Ist aber aufgrund von zURLTool nicht nötig, weil die Zertifikatsgültigkeit dann nicht geprüft wird. -
Inbetriebnahme eines neuen Geräts.
Es ist jederzeit möglich, mittels zURLTool ein Gerät sofort, lokal ohne Account und ohne App in Betrieb zu nehmen und zu steuern.
Sowohl über MQTT-Broker als auch per zenSDK. Für zenSDK muss die lokale API aktiviert sein / werden.
Reset:
Es ist möglich, ein Zendure-Gerät über MQTT oder BT auf den Auslieferungszustand zurückzusetzen.
Diese Option wird im Update von zURLtool 2.0 dch implementiert sein.
Achtung: Wenn ein Reset zum Verkauf des Geräts ausgeführt werden soll und/oder man es nicht mehr in der Cloud auf sich registriert haben möchte, muss das Gerät zusätzlich in der App entfernt werden!Das bisherige setzen des WIFI MODE wie in Version 1.0 ist nicht mehr nötig.
Das WiFi wird gescannt und bei Auswahl des WiFi wird beim übernehmen automatisch der richtige Mode gesetzt.Token:
Bisherige BT-Tools haben Fehler und verwend(et)en einen nicht richtigen Token.
Der erfundene Token wird nur bei einigen „älteren“ Geräten – ohne Probleme – akzeptiert.
Richtig und empfehlenswert ist er nicht.
Aus verständlichen Gründen kann und werde ich nicht weiter darauf eingehen.userId
wird bei Account-Erstellung von der Cloud erstellt und zugewiesen. Berechnet wird sie weder von der App noch durch die Firmware.
Sie wird einmalig gesetzt und danach nur ausgelesen und verwendet. Ebenso die consumerId, die nach "bisherigen" Analysen identisch mit der userId ist.Wird ein Gerät lokal oder mit Cloud-Verbindung in Betrieb genommen, ohne dass ein Account generiert wurde oder die ID fehlerhaft ist, dann wird eine Universal-ID als Fallback akzeptiert.
Für lokalen Betrieb ausreichend.
Bei vorhandenem Cloud- und App-Account mit Benutzername und Passwort und evtl. gleichzeitigem Betrieb mit Cloud ist es besser, die richtige, zugewiesene userId bei allen vorhandenen Geräten zu verwenden.Die userId kann nur über HTTP(S) gezielt, direkt und sofort abgerufen werden.
zURLtool nutzt beim Schreiben eine gültige Universal-Fallback-userId.
Das ist ausreichend. Aber m. M. n. sinnvoll und besser ist es, die explizit zugewiesene userId zu verwenden, um dem Original vollständig zu entsprechen.Dazu habe ich ein neues Tool geschrieben: zAppEmulationDeviceInfo
Dabei gibt man in der GUI von der App die Zugangsdaten ein oder in:
deviceInfoConfig.ini; zAppEmulationDeviceInfo ; example: ; ; [ACCOUNT] ; EMAIL = user123@gmail.com ; PASSWORD = tOpS3kRet17090811Bc74 ; [ACCOUNT] EMAIL = user123@gmail.com PASSWORD = tOpS3kRet17090811Bc74zAppEmulationDeviceInfo emuliert die App und führt einen Request aus.
Die Antwort steht dann im Textfeld und speichert die wichtigsten Daten in der Datei: Device-List.txtEs handelt sich hierbei NICHT um die Standard-Device-List. Es sind viel mehr Daten vorhanden, die für die App vorgesehen sind.
HINWEIS: zAppEmulationDeviceInfo verbindet sich über HTTP(S) mit der Cloud, wie die eigentliche App, und ruft nur einmalig die erforderlichen Daten ab.
Mehr nicht.
Es kann und soll gerne ein Virenscan erfolgen!
Wenn man dem Tool wegen der Zugangsdaten nicht vertraut, kann man auch temporär sein Account-Passwort dafür ändern.zAppEmulationDeviceInfo benötigt eine Seriennummer und einen Activationcode.
Wer bereits zURLtool verwendet, kann die Seriennummer und den Freischaltcode von zURLtool verwenden.
Bzw. zAppEmulationDeviceInfo kann direkt ausgeführt werden, wenn zURLtool schon verwendet wird.
Man kann User-E-Mail und Passwort händisch in der GUI eingeben oder vorbelegen in der Datei: deviceInfoConfig.ini; zAppEmulationDeviceInfo ; example: ; ; [ACCOUNT] ; EMAIL = userAccount@gmail.com ; PASSWORD = tOpS3kRet17090811Bc74 ; [ACCOUNT] EMAIL = userAccount@gmail.com PASSWORD = tOpS3kRet17090811Bc74Wenn die consumerId ausgelesen wurde und man seine Geräte auf seine originale, von der Cloud zugewiesene userID setzen möchte, dann kann die bisherige zURLtool-Version das bereits.
zURLtool wurde schon dafür vorbereitet.
In der Datei: config.ini; config.ini zURLtool (c) maxclaudi 2026 ; Für WiFi SSID und PASSWORD bitte keine Leerzeichen, Umlaute etc. verwenden ; Broker: Bitte nur reine IP oder DNS eingeben. Kein ":" und kein Port. ; Der Port ist in der Firmware fest hinterlegt. Entweder Port:1883 ohne TLS oder Port 8883 mit TLS. ; TLS-Verbindungen können nur mit gültigen Zertif. / Keys verwendet werden. ; ; MODE = WLAN-Sicherheitsmodus ; 3 = WPA2-PSK (Standard) ; 4 = WPA/WPA2-PSK ; 5 = WPA2-Enterprise ; 6 = WPA3-PSK ; 7 = WPA2/WPA3-PSK ; Gültige Werte: 3-7; bei fehlendem/ungültigem Wert wird automatisch 3 verwendet. ; MODE = 3 ; ; Zurück zur Cloud: ; BROKER = mq.zen-iot.com ; ; Beispiele: ; [WIFI] ; SSID = meinWLAN ; PASSWORD = tOpS3kRet17090811Bc74 ; MODE = 3 ; ; [MQTT] ; BROKER = 192.168.12.200 ; MODE = 3 ; [WIFI] SSID = meinWLAN PASSWORD = tOpS3kRet17090811Bc74 MODE = 3 EXTRA = <userID> [MQTT] BROKER = 192.168.12.200 ;BROKER = mq.zen-iot.comStatt "<userId>" die tatsächlich abgefragte userId einfügen.
Beispiel:EXTRA = 43521Wenn consumerId in EXTRA angeben wird, überträgt das zURLtool genau diese Nummer als lokale userId auf das Gerät.
Dadurch wird sichergestellt, dass die lokale Broker-Konfiguration exakt mit der Identität übereinstimmt, die von in der Cloud registrierten Geräten erwartet wird; auf diese Weise werden jegliche internen Diskrepanzen bei der Autorisierung auf Chip-Ebene vollständig beseitigt.
Wird das zURLtool ohne das Feld EXTRA verwendet, kommt eine gültige, generische Fallback-userId zum Einsatz.
Dies funktioniert wie vorgesehen, da sie als universelle userId akzeptiert wird.
Sie stimmt jedoch nicht mit der spezifischen userId überein, die von der Cloud für den jeweiligen Benutzer generiert wurde.Auch wenn die universelle Fallback-userId funktioniert, ist es meiner Meinung nach sinnvoller, die von der Cloud zugewiesene userId zu verwenden.
Die Cloud-basierte userId wird üblicherweise erst bei der Einrichtung eines Kontos erstellt.Der Fallback-Mechanismus ist für die Verbindung zur Cloud gedacht, wenn das Gerät vollständig offline betrieben wird oder die userId ungültig ist.
Da das zURLtool nur vorhandene, bekannte oder vordefinierte Werte setzen kann – und während der Einrichtung weder über eine HTTP(S)-Verbindung verfügt noch weiß, ob ein Konto existiert –, wird standardmäßig die universelle Fallback-userId verwendet, wenn das Feld EXTRA weggelassen wird oder einen ungültigen Wert enthält.
Download zAppEmulationDeviceInfo in 3 Teilen:
zAppEmulationDeviceInfo.zip
zAppEmulationDeviceInfo.z01
zAppEmulationDeviceInfo.z02Download zAppEmulationDeviceInfo in 3 Teilen.
Teil 1:Achtung: Falls die Datei nach dem Download einen anderen Namen als zAppEmulationDeviceInfo.zip hat, benenne sie bitte entsprechend um.
-
zURLtool Zendure Smart Plug Pro
können auch mit zURLTool umgeschrieben und per MQTT gesteuert werden.
Persönlich mag ich die Smart Plug Pro nicht, u. a. wegen des schlechten WLAN-Empfangs und einiger Exemplare, die zu viele Fehlfunktionen haben.
Dazu kann man die Rezensionen und Kommentare auf Amazon und der Herstellerseite lesen.zURLtool TLS
Wird damit der DNS auf eine andere DNS oder IP umgeschrieben, funktioniert die Zertifikatskette mit Keys.
Aktuell ist es so, dass dann die Zertifikatsgültigkeiten (Beginn 2020 / Ende 2030) nicht geprüft werden.
Tatsächlich ist und wäre das auch schwer realisierbar.
Zumindest meine Geräte haben sich auch mit gesetztem Datum von 1999 und 2041 verbunden.
Das Gerät im Auslieferungszustand „kann“ eine Zeit von 1970 haben.
Die Zeit wird per Cloud bzw. Broker und/oder HTTPS synchronisiert.
Das kann und wird auch erst nach erfolgter MQTT(S)-Verbindung über TLS und Registrierung der Geräte vorgenommen.
Setzt man einen Broker als Bridge ein, dann werden auch Geräte, die kein TLS unterstützen, über TLS verbunden.
Wie z. B. Hub2000, ace1500.Garantie:
- Solange Variablen verändert werden, die im System für den Nutzer oder das System-Setup vorgesehen sind (z. B. Server-URLs, IDs, MQTT-Pfade), ist das rechtlich wie eine Konfiguration zu werten. Davon fängt kein Gerät an zu brennen!
- Rechtliche Nuance: Sollte ein Firmware-Mod jedoch Schutzmechanismen aushebeln (z. B. Ladeströme oder Temperaturlimits manipulieren), könnte im schlimmsten Fall die Betriebserlaubnis (CE-Konformität) erlöschen. Da es sich beim zURLtool aber ausschließlich um das Setzen von Serververbindungen (URLs/Broker) und IDs handelt, führt ein Ändern von dafür vorgesehenen Variablen zu keinem Brand – die Brandgefahr ist hier ein reines Schreckgespenst.
Beim Umschreiben von Variablen verliert man keine gesetzliche Gewährleistung. Alles, was über Gesetze hinausgeht, sind freiwillige Leistungen des Herstellers; diese können, müssen aber nicht gewährt werden.
Lokale API ein- und ausschaltbar
Mit Cloud-Ersatz-Broker (lokaler Broker statt Cloud) kann localAPIenable aus- und eingeschaltet werden.
Wenn es ausgeschaltet ist, ist der ESP zusätzlich entlastet und ein Steuern über zenSDK ist nicht möglich.
Erfolgreiche Umsetzung nach Firmware-Analyse (erste öffentliche Dokumentation): Für die Aktivierung von 'localAPIenable' ist kein vorheriges Ein-/Ausschalten von HEMS in der App erforderlich; der Vorgang lässt sich alternativ via MQTT nicht nur Einschalten sondern nach Belieben ein- und ausschalten.localAPIEnable eingeschaltet:
localAPIEnable ausgeschaltet:
localAPIEnable wieder eingeschaltet:
Cloudless:
-
Zeitsynchronisation über MQTT möglich. Über NTP und zusätzliches Skript.
Entweder reales oder auch berechnetes, willkürliches Datum und Zeit.
Ist aber aufgrund von zURLTool nicht nötig, weil die Zertifikatsgültigkeit dann nicht geprüft wird. -
Inbetriebnahme eines neuen Geräts.
Es ist jederzeit möglich, mittels zURLTool ein Gerät sofort, lokal ohne Account und ohne App in Betrieb zu nehmen und zu steuern.
Sowohl über MQTT-Broker als auch per zenSDK. Für zenSDK muss die lokale API aktiviert sein / werden.
Reset:
Es ist möglich, ein Zendure-Gerät über MQTT oder BT auf den Auslieferungszustand zurückzusetzen.
Diese Option wird im Update von zURLtool 2.0 dch implementiert sein.
Achtung: Wenn ein Reset zum Verkauf des Geräts ausgeführt werden soll und/oder man es nicht mehr in der Cloud auf sich registriert haben möchte, muss das Gerät zusätzlich in der App entfernt werden!Das bisherige setzen des WIFI MODE wie in Version 1.0 ist nicht mehr nötig.
Das WiFi wird gescannt und bei Auswahl des WiFi wird beim übernehmen automatisch der richtige Mode gesetzt.Token:
Bisherige BT-Tools haben Fehler und verwend(et)en einen nicht richtigen Token.
Der erfundene Token wird nur bei einigen „älteren“ Geräten – ohne Probleme – akzeptiert.
Richtig und empfehlenswert ist er nicht.
Aus verständlichen Gründen kann und werde ich nicht weiter darauf eingehen.userId
wird bei Account-Erstellung von der Cloud erstellt und zugewiesen. Berechnet wird sie weder von der App noch durch die Firmware.
Sie wird einmalig gesetzt und danach nur ausgelesen und verwendet. Ebenso die consumerId, die nach "bisherigen" Analysen identisch mit der userId ist.Wird ein Gerät lokal oder mit Cloud-Verbindung in Betrieb genommen, ohne dass ein Account generiert wurde oder die ID fehlerhaft ist, dann wird eine Universal-ID als Fallback akzeptiert.
Für lokalen Betrieb ausreichend.
Bei vorhandenem Cloud- und App-Account mit Benutzername und Passwort und evtl. gleichzeitigem Betrieb mit Cloud ist es besser, die richtige, zugewiesene userId bei allen vorhandenen Geräten zu verwenden.Die userId kann nur über HTTP(S) gezielt, direkt und sofort abgerufen werden.
zURLtool nutzt beim Schreiben eine gültige Universal-Fallback-userId.
Das ist ausreichend. Aber m. M. n. sinnvoll und besser ist es, die explizit zugewiesene userId zu verwenden, um dem Original vollständig zu entsprechen.Dazu habe ich ein neues Tool geschrieben: zAppEmulationDeviceInfo
Dabei gibt man in der GUI von der App die Zugangsdaten ein oder in:
deviceInfoConfig.ini; zAppEmulationDeviceInfo ; example: ; ; [ACCOUNT] ; EMAIL = user123@gmail.com ; PASSWORD = tOpS3kRet17090811Bc74 ; [ACCOUNT] EMAIL = user123@gmail.com PASSWORD = tOpS3kRet17090811Bc74zAppEmulationDeviceInfo emuliert die App und führt einen Request aus.
Die Antwort steht dann im Textfeld und speichert die wichtigsten Daten in der Datei: Device-List.txtEs handelt sich hierbei NICHT um die Standard-Device-List. Es sind viel mehr Daten vorhanden, die für die App vorgesehen sind.
HINWEIS: zAppEmulationDeviceInfo verbindet sich über HTTP(S) mit der Cloud, wie die eigentliche App, und ruft nur einmalig die erforderlichen Daten ab.
Mehr nicht.
Es kann und soll gerne ein Virenscan erfolgen!
Wenn man dem Tool wegen der Zugangsdaten nicht vertraut, kann man auch temporär sein Account-Passwort dafür ändern.zAppEmulationDeviceInfo benötigt eine Seriennummer und einen Activationcode.
Wer bereits zURLtool verwendet, kann die Seriennummer und den Freischaltcode von zURLtool verwenden.
Bzw. zAppEmulationDeviceInfo kann direkt ausgeführt werden, wenn zURLtool schon verwendet wird.
Man kann User-E-Mail und Passwort händisch in der GUI eingeben oder vorbelegen in der Datei: deviceInfoConfig.ini; zAppEmulationDeviceInfo ; example: ; ; [ACCOUNT] ; EMAIL = userAccount@gmail.com ; PASSWORD = tOpS3kRet17090811Bc74 ; [ACCOUNT] EMAIL = userAccount@gmail.com PASSWORD = tOpS3kRet17090811Bc74Wenn die consumerId ausgelesen wurde und man seine Geräte auf seine originale, von der Cloud zugewiesene userID setzen möchte, dann kann die bisherige zURLtool-Version das bereits.
zURLtool wurde schon dafür vorbereitet.
In der Datei: config.ini; config.ini zURLtool (c) maxclaudi 2026 ; Für WiFi SSID und PASSWORD bitte keine Leerzeichen, Umlaute etc. verwenden ; Broker: Bitte nur reine IP oder DNS eingeben. Kein ":" und kein Port. ; Der Port ist in der Firmware fest hinterlegt. Entweder Port:1883 ohne TLS oder Port 8883 mit TLS. ; TLS-Verbindungen können nur mit gültigen Zertif. / Keys verwendet werden. ; ; MODE = WLAN-Sicherheitsmodus ; 3 = WPA2-PSK (Standard) ; 4 = WPA/WPA2-PSK ; 5 = WPA2-Enterprise ; 6 = WPA3-PSK ; 7 = WPA2/WPA3-PSK ; Gültige Werte: 3-7; bei fehlendem/ungültigem Wert wird automatisch 3 verwendet. ; MODE = 3 ; ; Zurück zur Cloud: ; BROKER = mq.zen-iot.com ; ; Beispiele: ; [WIFI] ; SSID = meinWLAN ; PASSWORD = tOpS3kRet17090811Bc74 ; MODE = 3 ; ; [MQTT] ; BROKER = 192.168.12.200 ; MODE = 3 ; [WIFI] SSID = meinWLAN PASSWORD = tOpS3kRet17090811Bc74 MODE = 3 EXTRA = <userID> [MQTT] BROKER = 192.168.12.200 ;BROKER = mq.zen-iot.comStatt "<userId>" die tatsächlich abgefragte userId einfügen.
Beispiel:EXTRA = 43521Wenn consumerId in EXTRA angeben wird, überträgt das zURLtool genau diese Nummer als lokale userId auf das Gerät.
Dadurch wird sichergestellt, dass die lokale Broker-Konfiguration exakt mit der Identität übereinstimmt, die von in der Cloud registrierten Geräten erwartet wird; auf diese Weise werden jegliche internen Diskrepanzen bei der Autorisierung auf Chip-Ebene vollständig beseitigt.
Wird das zURLtool ohne das Feld EXTRA verwendet, kommt eine gültige, generische Fallback-userId zum Einsatz.
Dies funktioniert wie vorgesehen, da sie als universelle userId akzeptiert wird.
Sie stimmt jedoch nicht mit der spezifischen userId überein, die von der Cloud für den jeweiligen Benutzer generiert wurde.Auch wenn die universelle Fallback-userId funktioniert, ist es meiner Meinung nach sinnvoller, die von der Cloud zugewiesene userId zu verwenden.
Die Cloud-basierte userId wird üblicherweise erst bei der Einrichtung eines Kontos erstellt.Der Fallback-Mechanismus ist für die Verbindung zur Cloud gedacht, wenn das Gerät vollständig offline betrieben wird oder die userId ungültig ist.
Da das zURLtool nur vorhandene, bekannte oder vordefinierte Werte setzen kann – und während der Einrichtung weder über eine HTTP(S)-Verbindung verfügt noch weiß, ob ein Konto existiert –, wird standardmäßig die universelle Fallback-userId verwendet, wenn das Feld EXTRA weggelassen wird oder einen ungültigen Wert enthält.
Download zAppEmulationDeviceInfo in 3 Teilen:
zAppEmulationDeviceInfo.zip
zAppEmulationDeviceInfo.z01
zAppEmulationDeviceInfo.z02Download zAppEmulationDeviceInfo in 3 Teilen.
Teil 2:Achtung: Falls die Datei nach dem Download einen anderen Namen als zAppEmulationDeviceInfo.z01 hat, benenne sie bitte entsprechend um.
-
zURLtool Zendure Smart Plug Pro
können auch mit zURLTool umgeschrieben und per MQTT gesteuert werden.
Persönlich mag ich die Smart Plug Pro nicht, u. a. wegen des schlechten WLAN-Empfangs und einiger Exemplare, die zu viele Fehlfunktionen haben.
Dazu kann man die Rezensionen und Kommentare auf Amazon und der Herstellerseite lesen.zURLtool TLS
Wird damit der DNS auf eine andere DNS oder IP umgeschrieben, funktioniert die Zertifikatskette mit Keys.
Aktuell ist es so, dass dann die Zertifikatsgültigkeiten (Beginn 2020 / Ende 2030) nicht geprüft werden.
Tatsächlich ist und wäre das auch schwer realisierbar.
Zumindest meine Geräte haben sich auch mit gesetztem Datum von 1999 und 2041 verbunden.
Das Gerät im Auslieferungszustand „kann“ eine Zeit von 1970 haben.
Die Zeit wird per Cloud bzw. Broker und/oder HTTPS synchronisiert.
Das kann und wird auch erst nach erfolgter MQTT(S)-Verbindung über TLS und Registrierung der Geräte vorgenommen.
Setzt man einen Broker als Bridge ein, dann werden auch Geräte, die kein TLS unterstützen, über TLS verbunden.
Wie z. B. Hub2000, ace1500.Garantie:
- Solange Variablen verändert werden, die im System für den Nutzer oder das System-Setup vorgesehen sind (z. B. Server-URLs, IDs, MQTT-Pfade), ist das rechtlich wie eine Konfiguration zu werten. Davon fängt kein Gerät an zu brennen!
- Rechtliche Nuance: Sollte ein Firmware-Mod jedoch Schutzmechanismen aushebeln (z. B. Ladeströme oder Temperaturlimits manipulieren), könnte im schlimmsten Fall die Betriebserlaubnis (CE-Konformität) erlöschen. Da es sich beim zURLtool aber ausschließlich um das Setzen von Serververbindungen (URLs/Broker) und IDs handelt, führt ein Ändern von dafür vorgesehenen Variablen zu keinem Brand – die Brandgefahr ist hier ein reines Schreckgespenst.
Beim Umschreiben von Variablen verliert man keine gesetzliche Gewährleistung. Alles, was über Gesetze hinausgeht, sind freiwillige Leistungen des Herstellers; diese können, müssen aber nicht gewährt werden.
Lokale API ein- und ausschaltbar
Mit Cloud-Ersatz-Broker (lokaler Broker statt Cloud) kann localAPIenable aus- und eingeschaltet werden.
Wenn es ausgeschaltet ist, ist der ESP zusätzlich entlastet und ein Steuern über zenSDK ist nicht möglich.
Erfolgreiche Umsetzung nach Firmware-Analyse (erste öffentliche Dokumentation): Für die Aktivierung von 'localAPIenable' ist kein vorheriges Ein-/Ausschalten von HEMS in der App erforderlich; der Vorgang lässt sich alternativ via MQTT nicht nur Einschalten sondern nach Belieben ein- und ausschalten.localAPIEnable eingeschaltet:
localAPIEnable ausgeschaltet:
localAPIEnable wieder eingeschaltet:
Cloudless:
-
Zeitsynchronisation über MQTT möglich. Über NTP und zusätzliches Skript.
Entweder reales oder auch berechnetes, willkürliches Datum und Zeit.
Ist aber aufgrund von zURLTool nicht nötig, weil die Zertifikatsgültigkeit dann nicht geprüft wird. -
Inbetriebnahme eines neuen Geräts.
Es ist jederzeit möglich, mittels zURLTool ein Gerät sofort, lokal ohne Account und ohne App in Betrieb zu nehmen und zu steuern.
Sowohl über MQTT-Broker als auch per zenSDK. Für zenSDK muss die lokale API aktiviert sein / werden.
Reset:
Es ist möglich, ein Zendure-Gerät über MQTT oder BT auf den Auslieferungszustand zurückzusetzen.
Diese Option wird im Update von zURLtool 2.0 dch implementiert sein.
Achtung: Wenn ein Reset zum Verkauf des Geräts ausgeführt werden soll und/oder man es nicht mehr in der Cloud auf sich registriert haben möchte, muss das Gerät zusätzlich in der App entfernt werden!Das bisherige setzen des WIFI MODE wie in Version 1.0 ist nicht mehr nötig.
Das WiFi wird gescannt und bei Auswahl des WiFi wird beim übernehmen automatisch der richtige Mode gesetzt.Token:
Bisherige BT-Tools haben Fehler und verwend(et)en einen nicht richtigen Token.
Der erfundene Token wird nur bei einigen „älteren“ Geräten – ohne Probleme – akzeptiert.
Richtig und empfehlenswert ist er nicht.
Aus verständlichen Gründen kann und werde ich nicht weiter darauf eingehen.userId
wird bei Account-Erstellung von der Cloud erstellt und zugewiesen. Berechnet wird sie weder von der App noch durch die Firmware.
Sie wird einmalig gesetzt und danach nur ausgelesen und verwendet. Ebenso die consumerId, die nach "bisherigen" Analysen identisch mit der userId ist.Wird ein Gerät lokal oder mit Cloud-Verbindung in Betrieb genommen, ohne dass ein Account generiert wurde oder die ID fehlerhaft ist, dann wird eine Universal-ID als Fallback akzeptiert.
Für lokalen Betrieb ausreichend.
Bei vorhandenem Cloud- und App-Account mit Benutzername und Passwort und evtl. gleichzeitigem Betrieb mit Cloud ist es besser, die richtige, zugewiesene userId bei allen vorhandenen Geräten zu verwenden.Die userId kann nur über HTTP(S) gezielt, direkt und sofort abgerufen werden.
zURLtool nutzt beim Schreiben eine gültige Universal-Fallback-userId.
Das ist ausreichend. Aber m. M. n. sinnvoll und besser ist es, die explizit zugewiesene userId zu verwenden, um dem Original vollständig zu entsprechen.Dazu habe ich ein neues Tool geschrieben: zAppEmulationDeviceInfo
Dabei gibt man in der GUI von der App die Zugangsdaten ein oder in:
deviceInfoConfig.ini; zAppEmulationDeviceInfo ; example: ; ; [ACCOUNT] ; EMAIL = user123@gmail.com ; PASSWORD = tOpS3kRet17090811Bc74 ; [ACCOUNT] EMAIL = user123@gmail.com PASSWORD = tOpS3kRet17090811Bc74zAppEmulationDeviceInfo emuliert die App und führt einen Request aus.
Die Antwort steht dann im Textfeld und speichert die wichtigsten Daten in der Datei: Device-List.txtEs handelt sich hierbei NICHT um die Standard-Device-List. Es sind viel mehr Daten vorhanden, die für die App vorgesehen sind.
HINWEIS: zAppEmulationDeviceInfo verbindet sich über HTTP(S) mit der Cloud, wie die eigentliche App, und ruft nur einmalig die erforderlichen Daten ab.
Mehr nicht.
Es kann und soll gerne ein Virenscan erfolgen!
Wenn man dem Tool wegen der Zugangsdaten nicht vertraut, kann man auch temporär sein Account-Passwort dafür ändern.zAppEmulationDeviceInfo benötigt eine Seriennummer und einen Activationcode.
Wer bereits zURLtool verwendet, kann die Seriennummer und den Freischaltcode von zURLtool verwenden.
Bzw. zAppEmulationDeviceInfo kann direkt ausgeführt werden, wenn zURLtool schon verwendet wird.
Man kann User-E-Mail und Passwort händisch in der GUI eingeben oder vorbelegen in der Datei: deviceInfoConfig.ini; zAppEmulationDeviceInfo ; example: ; ; [ACCOUNT] ; EMAIL = userAccount@gmail.com ; PASSWORD = tOpS3kRet17090811Bc74 ; [ACCOUNT] EMAIL = userAccount@gmail.com PASSWORD = tOpS3kRet17090811Bc74Wenn die consumerId ausgelesen wurde und man seine Geräte auf seine originale, von der Cloud zugewiesene userID setzen möchte, dann kann die bisherige zURLtool-Version das bereits.
zURLtool wurde schon dafür vorbereitet.
In der Datei: config.ini; config.ini zURLtool (c) maxclaudi 2026 ; Für WiFi SSID und PASSWORD bitte keine Leerzeichen, Umlaute etc. verwenden ; Broker: Bitte nur reine IP oder DNS eingeben. Kein ":" und kein Port. ; Der Port ist in der Firmware fest hinterlegt. Entweder Port:1883 ohne TLS oder Port 8883 mit TLS. ; TLS-Verbindungen können nur mit gültigen Zertif. / Keys verwendet werden. ; ; MODE = WLAN-Sicherheitsmodus ; 3 = WPA2-PSK (Standard) ; 4 = WPA/WPA2-PSK ; 5 = WPA2-Enterprise ; 6 = WPA3-PSK ; 7 = WPA2/WPA3-PSK ; Gültige Werte: 3-7; bei fehlendem/ungültigem Wert wird automatisch 3 verwendet. ; MODE = 3 ; ; Zurück zur Cloud: ; BROKER = mq.zen-iot.com ; ; Beispiele: ; [WIFI] ; SSID = meinWLAN ; PASSWORD = tOpS3kRet17090811Bc74 ; MODE = 3 ; ; [MQTT] ; BROKER = 192.168.12.200 ; MODE = 3 ; [WIFI] SSID = meinWLAN PASSWORD = tOpS3kRet17090811Bc74 MODE = 3 EXTRA = <userID> [MQTT] BROKER = 192.168.12.200 ;BROKER = mq.zen-iot.comStatt "<userId>" die tatsächlich abgefragte userId einfügen.
Beispiel:EXTRA = 43521Wenn consumerId in EXTRA angeben wird, überträgt das zURLtool genau diese Nummer als lokale userId auf das Gerät.
Dadurch wird sichergestellt, dass die lokale Broker-Konfiguration exakt mit der Identität übereinstimmt, die von in der Cloud registrierten Geräten erwartet wird; auf diese Weise werden jegliche internen Diskrepanzen bei der Autorisierung auf Chip-Ebene vollständig beseitigt.
Wird das zURLtool ohne das Feld EXTRA verwendet, kommt eine gültige, generische Fallback-userId zum Einsatz.
Dies funktioniert wie vorgesehen, da sie als universelle userId akzeptiert wird.
Sie stimmt jedoch nicht mit der spezifischen userId überein, die von der Cloud für den jeweiligen Benutzer generiert wurde.Auch wenn die universelle Fallback-userId funktioniert, ist es meiner Meinung nach sinnvoller, die von der Cloud zugewiesene userId zu verwenden.
Die Cloud-basierte userId wird üblicherweise erst bei der Einrichtung eines Kontos erstellt.Der Fallback-Mechanismus ist für die Verbindung zur Cloud gedacht, wenn das Gerät vollständig offline betrieben wird oder die userId ungültig ist.
Da das zURLtool nur vorhandene, bekannte oder vordefinierte Werte setzen kann – und während der Einrichtung weder über eine HTTP(S)-Verbindung verfügt noch weiß, ob ein Konto existiert –, wird standardmäßig die universelle Fallback-userId verwendet, wenn das Feld EXTRA weggelassen wird oder einen ungültigen Wert enthält.
Download zAppEmulationDeviceInfo in 3 Teilen:
zAppEmulationDeviceInfo.zip
zAppEmulationDeviceInfo.z01
zAppEmulationDeviceInfo.z02Download zAppEmulationDeviceInfo in 3 Teilen.
Teil 3:Achtung: Falls die Datei nach dem Download einen anderen Namen als zAppEmulationDeviceInfo.z02 hat, benenne sie bitte entsprechend um.
-
Allen einen wunderschönen, sonnigen guten Morgen,
@Rico-Sander sagte:
Vieles was hier diskutiert wird im Zusammenhang mit der Firmware- und HEMS-Aktualisierung trifft für mich nicht zu.habe auch kein Update durchgeführt. Weil ich kein HEMS nutze, ist es für mich nicht wichtig.
Von den letzten Updates war ich mehr enttäuscht.
Echte Verbesserungen gab es - für mich - nicht.
Für mich waren es mehr Reglementierungen.@Rico-Sander sagte:
Laden über AC-Anschluss, Entladen über AC-Anschluss - sonst nix.
Bypass-Funktion und Grid-Dose benötige ich nicht.Selbst wenn Du mehr benötigen würdest, wüsste ich nicht was aktuell unter API 2 dagegen spricht.
Die größten Veränderungen/Neuerungen durch das aktuelle Update sind bisher die Einführung von HEMS2 und Umstellung auf TLS.
Zendure schreibt zwar: X bekannte Probleme behoben, jedoch welche das sein sollen, wird nicht erwähnt.Bei meinem Gerät sollen es 2 Probleme sein.
Kann aber kein Problem feststellen und HEMS nutze ich nicht.@Rico-Sander sagte:
Daher: Kann ich gefahrlos bei Verwendung des HTTP-Scriptes die Updates fahren oder gibt es Probleme mit dem SSL- und Port-Problem?
Vermutlich nicht, da ich ja kein MQTT nutze - richtig?SSL mit Port:8883 ist nur für (nicht offizilles , Cloud-) MQTT
Das Script nutzt reines HTTP mit dem Webserver des Zendure-Geräts.
Zendure-Gerät und App nutzen zusätzlich "nicht offizielle" MQTT-Verbindung zur Cloud.Für das Script bedeutet das: Wenn Zendure durch die Firmware zenSDK nicht auch reglementiert oder grundlegend was verändert hat, dann funktioniert es wie zuvor.
Es gab mit dem Update ein paar Änderungen und ein zusätzlicher Key.
Bisher wurden mir keine Einschränkungen gemeldet.Hey, freut mich.
@Daniel-8 sagte:
...hat Zendure bei Hems 2 und den neuen Firmwares was geändert.
Ich habe noch kein Update gemacht. Bin etwas vorsichtig, da im Zendure Forum sehr viele Probleme haben.warte auch ab. Evtl. benötige ich keins.
Das ist nicht bekannt und noch nicht dokumentiert.
Habe eine Vermutung und kann es - ohne Update -nicht testen.socCompSwitch, bedeutet wahrscheinlich: State of Charge Compilation Switch.
Denke es wird sich um einen neuen Schalter handeln, der eine Kalibrierung manuell auslösen wird.
Damit man die automatische (wöchentliche oder monatliche) SoC-Kalibrierung zu nicht gewollten Zeiten
- beeinflussen,
- verhindern
- oder vorziehen kann?
Das ist nur meine Vermutung -reine Spekulation - !
Habe den Schalter mal hinzugefügt, falls jemand auf eigene Gefahr und eigenes Risiko selbst testen möchte, was der Schalter bewirkt.
Unter API 2 habe ich den Schalter schon gesetzt und getestet.
Befehl wird abgeschickt und Empfang bestätigt.
Auswirkungen hatte es bei mir überhaupt keine.
War zu erwarten, weil socCompSwitch in der API2-Firmware nicht implementiert ist.
Konnte den Schalter mehrmals - unter API 2 - gefahrlos bei meinem 1600AC+ setzen - ohne jede Veränderung.
Funktionieren oder was bewirken wird der Schalter (sehr wahrscheinlich nur) erst nach Firmware-Update auf zenSDK API Version: 3.Noch einmal: Alles zu socCompSwitch sind nur Vermutungen aufgrund von Tests und Beobachtungen.
edit:
Falls jemand set socComp nach Update mit zenSDK API Version: 3 testen sollte, wäre ich über Rückmeldungen sehr dankbar.Habe mich heute doch mal getraut mein Solarflow 800 Pro auf die Firmware 2.0.1 upzudaten.
Habe dann mal den setsocComp auf 1 und 2 geschrieben. Konnte aber keinerlei Veränderung feststellen
@Daniel-8 sagte:
Habe dann mal den setsocComp auf 1 und 2 geschrieben. Konnte aber keinerlei Veränderung feststellenBisherige Analyse von
socCompSwitchund Überraschung:Der HEMS-Code wurde dabei ausdrücklich nicht als Verbraucher des separat gesetzten
socCompSwitchgewertet!Für dieses konkrete Firmware-BIN aktiviert
socCompSwitchkeine im analysierten ESP32-Code nachweisbare Funktion.Damit gilt für die analysierte aktuelle module-MASTER/ESP32-Firmware: V2.0.59 (in der App ausgewiesen u. a. als V2.0.2):
SocCompSwitchunter properties ist in dieser Firmware bereits als schreibbare Option vorhanden und kann gesetzt werden.
0ist der Standardwert.Für `SocCompSwitch unter properties konnte im analysierten ESP32-BIN jedoch noch keine funktionale Auswertung und damit keine nachweisbare Wirkung gefunden werden.
Die Option ist somit in der aktuellen Firmware bereits vorbereitet, hat nach dem derzeitigen Analyseergebnis aber noch keine erkennbare Funktion.
Ob
SocCompSwitchin einer zukünftigen Firmware tatsächlich eine Funktion erhält, zunächst ohne Wirkung bleibt oder später wieder entfernt bzw. geändert wird, lässt sich aus der aktuellen Firmware nicht ableiten.
Edit 30.09.2026
Schade, der Edit musste leider sein.
Urheberrecht (Copyright) am Code und der Firmware liegt vollständig beim Hersteller. Um rechtliche Probleme für mich und das Forum zu vermeiden, kann ich keinen kleinen Code-Auszug posten. -
@maxclaudi
super Sache, Cloudfree ohne Neustart vom Hyper ist eine echte Verbesserung.
Sollte man den Hyper mit neuester Firmware Cloudfree betreiben wäre die ultimative Lösung mit so einer Software zurück auf unverschlüsseltem Datentransfer zum mqtt Server stellen zu können. 😁@maxclaudi
super Sache, Cloudfree ohne Neustart vom Hyper ist eine echte Verbesserung.
Sollte man den Hyper mit neuester Firmware Cloudfree betreiben wäre die ultimative Lösung mit so einer Software zurück auf unverschlüsseltem Datentransfer zum mqtt Server stellen zu können. 😁@Murphy-0 Technisch ist der Weg in der Firmware tatsächlich vorhanden. Die Variablen für eine unverschlüsselte Verbindung existieren im Code:
Edit
Schade, der Edit musste leider sein.
Urheberrecht (Copyright) am Code und der Firmware liegt vollständig beim Hersteller. Um rechtliche Probleme für mich und das Forum zu vermeiden, kann ich keinen kleinen Code-Auszug posten.Broker ohne TLS über 1883 unter bestimmten Bedingungen möglich, ohne in die Firmware einzugreifen.
Das Problem dabei:
Das Ganze sauber zu analysieren, ist extrem viel Arbeit. Ich schaue mir an, ob es einen offiziell vorgesehenen und einfachen Weg gibt, diese Parameter per Bluetooth oder über ein MQTT-Kommando zu steuern.
Sollte es diese integrierte Möglichkeit nicht geben, werde ich das nicht weiter verfolgen.
Ein Eingriff in die Firmware (wie das Patchen von Speicherbereichen oder Flashen modifizierter Partitionen) kommt für mich nicht in Frage.
Die Firmware wird von mir niemals verändert!Mein Fokus liegt nur rein auf dem Analysieren der vorhandenen und funktionierenden HTTP(s)-, MQTT- und Bluetooth-Konfigurationen, die vom Hersteller bereits eingebaut sind und genutzt werden können.
Update 30.09.2026 01:26h:
Inzwischen habe ich diesen Weg weiter verfolgt. Aktuell ist noch unklar und muss weiter analysiert werden, ob das reine Setzen eines einzelnen Flags ausreicht, damit die Firmware in den unverschlüsselten Modus (Port 1883 statt 8883 mit TLS) wechselt und dieser Zustand auch dauerhaft erhalten bleibt.
Für heute brauche ich nach stundenlanger Arbeit aber erst mal dringend eine Pause. -
@maxclaudi
super Sache, Cloudfree ohne Neustart vom Hyper ist eine echte Verbesserung.
Sollte man den Hyper mit neuester Firmware Cloudfree betreiben wäre die ultimative Lösung mit so einer Software zurück auf unverschlüsseltem Datentransfer zum mqtt Server stellen zu können. 😁@Murphy-0 Technisch ist der Weg in der Firmware tatsächlich vorhanden. Die Variablen für eine unverschlüsselte Verbindung existieren im Code:
Edit
Schade, der Edit musste leider sein.
Urheberrecht (Copyright) am Code und der Firmware liegt vollständig beim Hersteller. Um rechtliche Probleme für mich und das Forum zu vermeiden, kann ich keinen kleinen Code-Auszug posten.Broker ohne TLS über 1883 unter bestimmten Bedingungen möglich, ohne in die Firmware einzugreifen.
Das Problem dabei:
Das Ganze sauber zu analysieren, ist extrem viel Arbeit. Ich schaue mir an, ob es einen offiziell vorgesehenen und einfachen Weg gibt, diese Parameter per Bluetooth oder über ein MQTT-Kommando zu steuern.
Sollte es diese integrierte Möglichkeit nicht geben, werde ich das nicht weiter verfolgen.
Ein Eingriff in die Firmware (wie das Patchen von Speicherbereichen oder Flashen modifizierter Partitionen) kommt für mich nicht in Frage.
Die Firmware wird von mir niemals verändert!Mein Fokus liegt nur rein auf dem Analysieren der vorhandenen und funktionierenden HTTP(s)-, MQTT- und Bluetooth-Konfigurationen, die vom Hersteller bereits eingebaut sind und genutzt werden können.
Update 30.09.2026 01:26h:
Inzwischen habe ich diesen Weg weiter verfolgt. Aktuell ist noch unklar und muss weiter analysiert werden, ob das reine Setzen eines einzelnen Flags ausreicht, damit die Firmware in den unverschlüsselten Modus (Port 1883 statt 8883 mit TLS) wechselt und dieser Zustand auch dauerhaft erhalten bleibt.
Für heute brauche ich nach stundenlanger Arbeit aber erst mal dringend eine Pause.Guten Morgen allerseits,
mein SF800 Pro2 läuft jetzt seit gut 2 Monaten mit dem Blockly und wurde aufmerksam von mir beobachtet. Ein paar Dinge sind mir persönlich aufgefallen, zu denen ich Euch mal befragen wollte.
Außerdem habe ich dann mit erstaunen festgestellt, wie viel sich in der Zeit wieder in dem Blockly verändert hat. Beim umstellen der Vorlage auf meine Gerätschaften kam mir dann noch eine Idee, dazu aber gleich mehr.Im Juli und August war es bei meinem SF800 Pro2 mit 2 Akkus kein Problem, das Ding so ziemlich täglich auf 100% zu laden. Heißt also, es gab keine automatische Kalibrierung.
Jetzt im September wurde das mit den 100% aber schon schwieriger und ich hab in meinen Aufzeichnungen gesehen, dass immer mal wieder nachts um 1:00 Uhr (Standard-Kalibrierungszeit der App) das Laden mit voller Last begonnen und kurz darauf wieder beendet wurde. Also keine vollständige Kalibrierung, weil das Blockly sofort wieder die Steuerung übernimmt, wenn der Akku etwas aufgeladen ist und wieder auf Entladen wechselt. Das ganze kann ich tagsüber beliebig reproduzieren, wenn ich manuell auf Laden stelle (zB über die App). Da kommt mir die Frage: Wie realisiert Ihr das mit dem Kalibrieren, ohne dass die Steuerung dazwischen funkt?
Das aktuelle Blockly hat zwar Parameter für DPL an/aus, aber das wird hier offensichtlich nicht für eine Kalibrierung eingesetzt. Oder hab ich tatsächlich was übersehen?Eine weitere Sache: Beim Aufladen morgens schwenkt das System immer wieder zwischen Laden/Entladen hin und her. Ich würde dem System gerne verständlich machen, dass der Akku morgens erst bis zB 15% aufladen soll, bevor er überhaupt wieder entladen darf. Er soll aber trotzdem nachts bis zB 10% entladen dürfen (ist das verständlich ausgedrückt?) Ich hab das Gefühl, das aktuelle Blockly könnte das realisieren, aber da blick ich noch nicht ganz durch.
Und die dritte Sache: in dem Blockly sind ja wahnsinnig viele Objekt-IDs, die ich jetzt erstmal alle einzeln anpassen musste. Könnte man das evtl durch eine Variable ersetzen? Dann müsste man die Variable nur in den Settings zu Beginn des Blockly einmal anpassen und alle Objekt-IDs würden damit automatisch angepasst. Bin das Script jetzt 3x durch und hab jedes Mal irgendwo was vergessen anzupassen
So in dieser Art vielleicht:
Edit:
Und manchmal dauert es verhältnismäßig lang, bis der SF800 aus dem Bypass wieder ans Laden geht morgens/vormittags. Teilweise hab ich 15 oder 20min lang -150W auf dem Stromzähler stehen und es wird trotzdem nicht aufgeladen. Veränder ich den Wert dann in der App oder im ioBroker manuell springt die Regelung sofort wieder an.Besten Dank und weiterhin frohes Schaffen
Marian
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
292
Online33.1k
Benutzer84.2k
Themen1.4m
Beiträge