NEWS
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 (iob / 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):
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
276
Online33.1k
Benutzende83.7k
Themen1.3m
Beiträge