Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

nograx

@maxclaudi Kannte diesen Thread und das Tool bisher nicht. Daher war die Readme bisher auch korrekt. Ich habe den Text jetzt angepasst Ich werde aber nicht auf Closed Source Projekte verweisen wo man nicht nachvollziehen kann was das Tool wirklich tut. Muss jeder selbst entscheiden was er auf seinem Rechner installiert und ausführt.

Und auch wenn du mehrfach beschwörst du hättest bei den anderen Open Source Projekten nichts "kopiert" wirst du nicht leugnen können das du davon zumindest einiges an Wissen aneignen konntest. Wenn man deine Kommentare oben so liest hat das schon ein Geschmäckle.

Es ist ab der 800/2400 Serie von Zendure sinnfrei den MQTT Server zu ändern, denn es gibt extra dafür das zenSDK. Mit Änderung des MQTT Servers verliert man sämtliche Garantie auf das Gerät und es werden im Standard dann keine Diagnose Daten mehr an Zendure geschickt. Deshalb gibts ja auch im Adapter die Relay Funktion. Das kann im schlimmsten Fall (siehe bei den Brand eines AIO2400 Anfang 2025) echt negative Folgen haben wenn dann z.B. die Versicherung nicht mehr zahlt.

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.

maxclaudi

@nograx sagte:

@maxclaudi Kannte diesen Thread und das Tool bisher nicht. Daher war die Readme bisher auch korrekt. Ich habe den Text jetzt angepasst Ich werde aber nicht auf Closed Source Projekte verweisen wo man nicht nachvollziehen kann was das Tool wirklich tut. Muss jeder selbst entscheiden was er auf seinem Rechner installiert und ausführt.

Und auch wenn du mehrfach beschwörst du hättest bei den anderen Open Source Projekten nichts "kopiert" wirst du nicht leugnen können das du davon zumindest einiges an Wissen aneignen konntest. Wenn man deine Kommentare oben so liest hat das schon ein Geschmäckle.

Es ist ab der 800/2400 Serie von Zendure sinnfrei den MQTT Server zu ändern, denn es gibt extra dafür das zenSDK. Mit Änderung des MQTT Servers verliert man sämtliche Garantie auf das Gerät und es werden im Standard dann keine Diagnose Daten mehr an Zendure geschickt. Deshalb gibts ja auch im Adapter die Relay Funktion. Das kann im schlimmsten Fall (siehe bei den Brand eines AIO2400 Anfang 2025) echt negative Folgen haben wenn dann z.B. die Versicherung nicht mehr zahlt.

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.

Historisch gesichert. Dein hier dokumentiertes Eigentor.

Bevor du hier im Thread versuchst, Nebelkerzen zu werfen, empfehle ich dir dringend, deine eigene Chronologie und meine Dokumentation hier im Forum der letzten Monate zu durchforsten.

Zum Thema, ich hätte hilfreiches Wissen aus Open-Source-Quellen:
Ja, ich habe mir diese Quellen sehr genau angesehen.
Viele davon sind jedoch unvollständig, unzureichend und schlicht fehlerbehaftet.
Genau aus diesem Grund ging und gehe ich konsequent den harten Weg des eigenen, unbestechlichen Reverse Engineerings direkt am lebenden Silizium.

Und zum Thema „Geschmäckle“ und Closed Source:
Genau das Verhalten, das du hier und in der Vergangenheit mir gegenüber an den Tag gelegt hast, ist der Hauptgrund für meine Entscheidung, meine harte Arbeit und meine Tools künftig restlos als Closed Source vor Dir zu schützen.

Darüber diskutiere ich auch nicht im Ansatz mit dir.
Für mich ist dieses Thema mit dir an dieser Stelle endgültig beendet.

maxclaudi

Guten Morgen zusammen :-)

Ein lokaler Betrieb ohne Cloud ist auch für z.B. Gartenhäuser, Camping etc. für diverse Zendure-Geräte vorgesehen.

Wer sein Gerät auf einen lokalen Broker als Cloud-Ersatz umstellt, muss keineswegs komplett auf die Cloud verzichten.

Es ist technisch absolut möglich, ein paralleles Cloud-Relais zu betreiben.
Dabei stehen zwei flexible Wege offen:

Weg A:
Die reine Einbahnstraßen-Bridge (Maximaler Schutz).
Das lokale System sendet weiterhin alle Diagnose- und Reportdaten brav an die Zendure-Cloud. Der Hersteller sieht alles, die Diagnosen laufen weiter, und (z. B. thermische) Auswertungen bleiben lückenlos erhalten. Gleichzeitig herrscht durch die lokale Weiche jedoch eine absolute Einbahnstraße bezüglich jeglicher eingehender Schreibbefehle von außen. Die Cloud kann zu keinem Zeitpunkt mehr ungefragt Parameter verändern.
Weg B:
Die offene bidirektionale Bridge (Lokaler Broker UND Cloud)
Ist die Bridge auf beiden Seiten geöffnet, verhält sich das System für das Gerät so, als würde es den lokalen Mosquitto überhaupt nicht geben. Die originale Zendure-App kann uneingeschränkt weiterverwendet werden, und alles funktioniert herkömmlich wie gewohnt.

Einzige Voraussetzung: Der lokale Mosquitto-Broker muss natürlich nonstop im Einsatz sein, wie das Zendure-Gerät.

Der unbezahlbare Vorteil dieser offenen Weiche:
Sie macht die herstellerseitige „Blackbox“ komplett transparent.

Im normalen Cloud-Betrieb hat man keine Chance zu sehen, was im Hintergrund passiert.

Über die Mosquitto-Brücke kann man nun – z. B. live über den MQTT-Explorer – unzensiert ganz genau nachvollziehen, ob, was und wann die Cloud am System geändert hat.

Genau diese digitale Transparenz und Kontrollmöglichkeit spricht massiv für eine zeitgemäße Umsetzung im Sinne europäischer Standards, statt sich einer geschlossenen Cloud auszuliefern.

Zusätzlich kann man das Gerät auch (nur für bestimmte Zeit oder immer) komplett lokal isoliert betreiben.

Das Umschalten zwischen den Möglichkeiten beschränkt sich auf Sekunden.

Auch wenn ich mal bei einer Person las, dass das ein erheblicher Aufwand sein soll.
Dabei müssen nur einzelne Zeilen in der config ein- oder auskommentiert werden und der mosquitto-Broker neu gestartet werden.

Vorteil bei allen Wegen:
Alles, wirklich alles wird transparent.
MQTT wird nicht reglementiert und nicht künstlich gedrosselt.
Alle Commands und Meldungen werden ereignisbasiert sofort published. Es muss nicht mit zusätzlichen Latenzen das HTTP-Netzwerk belastet werden und vor allem nicht mühselig und oft unnötig gepollt, gefiltert und ausgewertet werden.

Eigene Erfahrung: Seit ich meine Geräte lokal über diese Struktur betreibe, gab es bei mir keinerlei unvollständige Werte-Sprünge mehr, wie ich sie im Juli 2026 hier im Thread ab Post 424 ff. noch dokumentieren musste, als Parameter wie socSet oder inverseMaxPower unbemerkt im Hintergrund überschrieben wurden.

Es steht jedem frei, wie und was er einsetzt.
Zu guter Letzt hängt es natürlich auch von dem Verständnis und den eigenen Fähigkeiten ab, eine Bridge einzurichten und das JSON zu verstehen.
Mein Post dient nur als technische Information.

Viele Grüße, einen wunderschönen Morgen, strahlender Sonnenschein und maximaler PV-Ertrag!

maxclaudi

maxclaudi

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

paul53

@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?

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

@paul53 sagte:

@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.GetStatus

oder Get MQTT configuration

GET /rpc?method=HA.Mqtt.GetConfig

Allerdings 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

@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.

MP_Trixi

@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

@maxclaudi [sagte]: Kurios.

"pass" zeigt jetzt 0, "socLimit" ist 16.

maxclaudi

@MP_Trixi sagte:

@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

Daniel 8

@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.

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.

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

paul53

@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

@paul53 sagte:

@maxclaudi [sa
gte]: (Zeitstempel) im JSON mangels Internet-Zeitsynchronisation immer weiter zur Realität abdriftet

Bei 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

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

Daniel 8

@maxclaudi sagte:

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

Daniel 8

@maxclaudi sagte:

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?

maxclaudi

@Daniel-8

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.

Daniel 8

@maxclaudi sagte:

@Daniel-8

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.

Community Forum

NEWS

Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2

HINWEIS:

Support us

278

33.1k

83.7k

1.3m