Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2
-
Noch eine wichtige Ergänzung, weil hier offenbar einige durch Aussagen zu Garantie und Versicherung verunsichert wurden:
Die Aussage
„Mit Änderung des MQTT-Servers verliert man sämtliche Garantie“
ist so pauschal nicht belegt.
Bei der von mir beschriebenen Vorgehensweise wird keine Firmware verändert, kein BMS gepatcht und keine Schutzfunktion des Gerätes verändert.
Es wird lediglich über den vorhandenen BLE-Konfigurationsmechanismus die MQTT-Serveradresse geändert, die das Gerät für seine Kommunikation verwendet.
Das sind technisch zwei völlig unterschiedliche Dinge.
Auch die Aussage, dass ein lokaler MQTT-Broker zwangsläufig bedeutet, dass Zendure keinerlei Diagnoseinformationen mehr erhält, ist so nicht richtig. Wie in meinem vorherigen Beitrag beschrieben, kann der lokale Broker über eine MQTT-Bridge weiterhin mit der Zendure-Cloud kommunizieren. Damit können die Daten weiterhin zur Cloud weitergereicht werden.
Noch einmal ausdrücklich:
Lokaler MQTT-Betrieb bedeutet nicht automatisch „Cloud abschalten“.
Man kann beispielsweise weiterhin alle Reports und Diagnosedaten zur Cloud weiterleiten und gleichzeitig lokal sämtliche MQTT-Kommunikation beobachten und kontrollieren.
Auch die häufig daraus abgeleitete Aussage
„Dann zahlt im schlimmsten Fall die Versicherung bei einem Brand nicht“
ist keine technische Schlussfolgerung.
Ein Versicherungsfall wird nicht dadurch entschieden, dass irgendwann einmal die Adresse eines MQTT-Brokers geändert wurde. Entscheidend wären vielmehr der konkrete Versicherungsvertrag, die konkrete Schadenursache und gegebenenfalls die Frage, ob eine Änderung überhaupt ursächlich für den Schaden war.
Wer beispielsweise die Ladeelektronik, das BMS oder Schutzmechanismen manipuliert, befindet sich selbstverständlich in einer völlig anderen Situation.
Das ist aber nicht das, was ich hier beschreibe.
Bei meinem Ansatz wird ausschließlich die Kommunikationsroute geändert.
Das lässt sich auch sehr einfach nachvollziehen:
Original:
Gerät → Zendure-MQTT → Zendure-Cloud
Lokal:
Gerät → eigener MQTT-Broker
Lokal + Cloud-Relay:
Gerät → eigener MQTT-Broker → Zendure-Cloud
Die Hardware, Firmware, BMS-Regelung und elektrischen Schutzmechanismen bleiben dabei unverändert.
Auch das angeführte Beispiel eines Brandes eines AIO2400 Anfang 2025 ändert daran nichts. Ohne eine nachgewiesene Brandursache gibt es keinen technischen Zusammenhang zwischen einem Brand und der Änderung eines MQTT-Ziels.
Ich möchte damit niemanden dazu auffordern, sein Gerät zwingend lokal zu betreiben. Jeder muss selbst entscheiden, welche Lösung er verwenden möchte.
Mir ist nur wichtig, dass diese Entscheidung auf technischen Fakten und nicht auf unbelegten Horrorszenarien basiert.
Wer die Cloud verwenden möchte, kann sie verwenden.
Wer lokal arbeiten möchte, kann lokal arbeiten.
Und wer beides möchte, kann über ein Relay sogar lokalen Betrieb, vollständige MQTT-Transparenz und Cloud-Anbindung miteinander kombinieren.
Viele Grüße
maxclaudi@maxclaudi
Hi. Was mir gerade in der App bei meinem 800Pro2 aufgefallen ist (glaube diese Option hat es früher wohl schon mal gegeben und ist scheinbar nun in einer der letzten App Versionen wieder reingekommen). Was die genau tut und ob das im entferntesten Deiner Lösung gleich oder nahe kommt kann ich nicht sagen:
-
@paul53 sagte:
EDIT: Übrigens habe ich noch folgende Werte unter "properties", die nicht der Beschreibung entsprechen:- "pass": 3
- "socLimit": 17
Kurios.
Die Beschreibung des Datenpunktes pass (Bypass-Modus) stimmt zumindest laut der aktuellen App-Logik nicht mit der veralteten Online-Dokumentation überein.
Eine tiefergehende Analyse der App-Strukturen liefert im Kernel ausschließlich folgende Definitionen:public static final int PASS_MODE_AUTO = 0; public static final int PASS_MODE_OFF = 1; public static final int PASS_MODE_ON = 2;Einen Wert 3 gibt es in dieser State-Machine für den Bypass-Modus nicht.
Warum anscheinend "3" im JSON-Telegramm übermittelt wurde erschließt sich mir nicht.
Die Beschreibung im aktuellen zenSDK-Script ist zumindest laut App richtig.
Genau deshalb ist eine saubere, lokale Analyse der Kommunikationswege so wichtig, um diese Abweichungen zu verstehen.@maxclaudi [sagte]: Kurios.
"pass" zeigt jetzt 0, "socLimit" ist 16.
-
@maxclaudi
Hi. Was mir gerade in der App bei meinem 800Pro2 aufgefallen ist (glaube diese Option hat es früher wohl schon mal gegeben und ist scheinbar nun in einer der letzten App Versionen wieder reingekommen). Was die genau tut und ob das im entferntesten Deiner Lösung gleich oder nahe kommt kann ich nicht sagen:
@maxclaudi
Hi. Was mir gerade in der App bei meinem 800Pro2 aufgefallen ist (glaube diese Option hat es früher wohl schon mal gegeben und ist scheinbar nun in einer der letzten App Versionen wieder reingekommen). Was die genau tut und ob das im entferntesten Deiner Lösung gleich oder nahe kommt kann ich nicht sagen:
Hallo @MP_Trixi,vielen Dank für Deinen Screenshot und den Hinweis.
Das ist eine hervorragende Beobachtung, die genau zu der technischen Analyse passt.Was Du dort in der App siehst, ist die grafische Oberfläche für genau die offiziellen zenSDK-Befehle (HA.Mqtt.SetConfig), die ich in meinem vorherigen Beitrag an paul53 aufgeführt habe.
Über diese Option lässt sich das herstellerseitig integrierte, „offizielle“ lokale MQTT direkt ein- oder ausschalten.Aus technischer Sicht und für eine performante Steuerung ist diese Option jedoch leider eine erhebliche Bremse und nicht empfehlenswert
Warum?
-
Die Cloud-URL bleibt identisch: Das Gerät tunnelt die Daten weiterhin unverändert im Hintergrund nach China. Es findet keine echte lokale Isolation statt.
-
Künstliche Drosselung: Dieser offizielle lokale MQTT-Pfad ist von Zendure stark reglementiert und in der Übertragungsgeschwindigkeit (Intervalle) künstlich gedrosselt.
Eine echtzeitnahe, ereignisbasierte 0-Einspeisung oder schnellere Steuerung via MQTT ist darüber m. M. n. nicht zufriedenstellend möglich. -
Die CPU-Überlastung (Das ESP32-Problem):
Wenn man diese Option aktiviert, passiert auf der Hardware-Ebene des kleinen Steuerchips (ESP32) etwas Kritisches:
Der Prozessor muss nun zeitgleich die verschlüsselte Cloud-MQTT-Verbindung, das zusätzliche reglementierte lokale MQTT-Protokoll UND die zenSDK-API über HTTP auf Port 80 verarbeiten.
Das ist für die schmale Rechenleistung der Hardware m. M. n. schlicht zu viel. -
Für die Nutzung und das Funktionieren von zenSDK ist die Aktivierung von diesem lokalen MQTT nicht notwendig.
Wer über ein echtes, freies MQTT-System oder die uneingeschränkte, schnelle zenSDK-API ohne künstliche Latenzen arbeiten möchte, hat durch diesen App-Schalter - meiner Meinung nach - leider keinen Mehrwert.
PS / Edit:
Der Schalter in der App lässt sich aber hervorragend zweckentfremden, falls das System mal einen Schluckauf oder Hänger hat. Wenn man den Schalter einschaltet, mindestens 15 Sekunden abwartet und ihn dann wieder ausschaltet, erzwingt man softwareseitig einen Neustart des internen Kommunikations-Stacks auf dem ESP32-Chip. Einen „offiziellen“ Neustart- oder Reboot-Button bietet die App schließlich nicht an.Liebe Grüße
maxclaudi
-
-
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
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.
Wie kann man feststellen ob sich das geändert hat? Ich habe die 2.0.1 auf dem solarflow800 Pro und im Moment den InternetZugang über die fritzbox gesperrt.
Solarflow 800 Pro mit 1,3 Kwp / Iobroker / Homematic / Shellys / Mediola / Intertechno
-
-
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.
Wie kann man feststellen ob sich das geändert hat? Ich habe die 2.0.1 auf dem solarflow800 Pro und im Moment den InternetZugang über die fritzbox gesperrt.
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. -
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.
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
384
Online33.1k
Benutzer84.2k
Themen1.4m
Beiträge