Monatsrückblick Juli / August 2026 ist online!

[maxclaudi]

@paul53
Samrtphone BT ausschalten. Nur Zendure App öffnen und schauen ob Gerät offline-Status hat, mehr nicht.
Wenn ja und mit der Zeit der Drift von timestamp deutlich größer wird, dann ist das Zendure-Gerät wirklich offline.

[paul53]

@maxclaudi sagte: Samrtphone BT ausschalten. Nur Zendure App öffnen und schauen ob Gerät offline-Status hat

In der App werden die Werte des SF angezeigt, aber in der App kann ich nichts steuern.

EDIT: Die Werte werden in der App nicht aktualisiert.

[maxclaudi]

Hallo zusammen,

es ist für mich speziell bei der "Zendure"-Open-Source-Szene immer wieder erstaunlich, erschreckend und zugleich beschämend zu sehen, wie viele Halbwahrheiten und Halbwissen im Umlauf sind.
Da wird im Nebel gestochert, während die dort mühsam aufgebauten Schein-Argumente am Ende wie Seifenblasen zerplatzen, sobald die echten Protokolle auf dem Tisch liegen.

Möchte eure und meine Nerven künftig schonen, mich nicht weiter an Spekulationen – und für mich dann sinnfreien Diskussionen – beteiligen, bei denen mir nur mit Annahmen oder Suggestivfragen geantwortet wird.

Ich habe es bereits hier im Forum angekündigt:
Für Zendure wird von mir kein Quellcode mehr öffentlich zur Verfügung gestellt - wenn nicht einmal ein winziger, respektvoller Hinweis erfolgt, dass meine Analysen und Entdeckungen als direkte Vorlage oder Idee genutzt und umgeschrieben wurden. Auf ein solches "Unix/Linux-Spielchen" ohne Anstand und Danke habe ich keine Lust mehr.

Künftig wird es von mir daher eher fertig kompilierte, geschlossene Hilfsmittel (als fertige App) oder gezielte Code-Beispiele und Hinweise geben.

Ich weise ausdrücklich und unmissverständlich darauf hin:
Nichts an meiner Arbeit verwendet Code aus der Home-Assistant-Integration oder dem ioBroker-Adapter!

Alles basiert auf reinem Reverse Engineering, offiziellen Dokumentationen, SDK, API, Hinweisen von Mitarbeitern des entsprechenden Supports, Freunden und meiner Fantasie :-)

Sollten jemals externe Bibliotheken eingebunden werden und / oder jemand mitgewirkt haben, wird jedes ehrliche Helferlein unter seinem Pseudonym oder echten Namen dankend erwähnt – es sei denn, man möchte es explizit nicht.

Da dieses Projekt hier jedoch von vielen als grundlegende Orientierung geschätzt wird, werde ich es im Hintergrund auf meine Weise weiter supporten.

---

Um auf einen aktuellen Beitrag kurz wertfrei und sachlich einzugehen:

@Bernd1967 sagte:
.... Ich habe einfach "inverterMaxLimit" auf 1200 gesetzt und dann fing der Hyper an einzuspeisen.
Ich wußte gar nicht das der Hyper diesen Parameter kennt :-)
Alpha.2 läuft auch.

Protokoll-Fakt: Ein solcher Key existiert in der Firmware der Geräte nicht.
Es handelt sich dabei um: inverseMaxPower

---

Ich bin inzwischen an einem Punkt angelangt, an dem ich zwei erweiterte Modul-Firmwares gesichert, die originale App im entpackten Zustand vollständig analysiert und mehr als ausreichend unzensiertes Logmaterial gesammelt habe.

Nach weit über 300 Stunden harter Arbeit ist das ein – für mich selbst erstaunlich – großes, gesammeltes Wissen.

Inzwischen macht jedes Gerät für meine Bekannten und mich (bis zum SF 2400AC PRO) lokal fast alles, was wir/ich möchte(n).

Dank speziellen, sukzessiven Commands ist scheinbar auch ein dauerhafter Bluetooth-Betrieb möglich. Vielleicht entwickle ich daraus irgendwann ein autarkes, lokales BT-MQTT-Gateway.

Aber im Moment ist der Forscherdrang und das Zendure-Entdecker-Fieber bei mir einfach nicht zu bändigen.

Anbei Screenshots einer meiner trivialen, selbst geschriebenen Bluetooth-Entwicklungshilfen und ein Ergebnis im ioBroker, wie man den Zeitstempel eines Zendure-Gerätes völlig frei hin- und hersetzen kann, wie man lustig ist. Das Gerät nimmt das Command ohne Wenn und Aber an und hört auf den Master.

Allen noch einen schönen 01.09.2026, viel Sonne und maximalen PV-Ertrag!

Viele Grüße,

maxclaudi

Spoiler

---

---

---

Zeitreise ins Jahr 2021

---

und wieder zurück 2026:

[Daniel 8]

@maxclaudi

Es ist sehr beeindruckend wieviel Zeit und Engagement du hier in dieses Projekt steckst. Es wäre sehr schade wenn wir dich verlieren würden und du nichts mehr für die Community machst.

Ich bin dir auf jedenfalls sehr dankbar für all das was du gemacht hast auch wenn ich noch nicht alles umgesetzt habe aber daran arbeite.

[maxclaudi]

@petman
gerne helfe ich Dir weiter :-)

1. Erstellt eine leere Passwortdatei am exakten Ort (falls noch nicht geschehen):

sudo touch /etc/mosquitto/passwd

2. Erstellt die Logdatei und übergibt die Besitzrechte an den Mosquitto-Dienst:

sudo touch /var/log/mosquitto/mosquitto.log
sudo chown mosquitto:mosquitto /var/log/mosquitto/mosquitto.log

---

Passwort-Datei:
muss natürlich auch zwingend befüllt werden.
Exakt mit deiner deviceId (als Username) und dem berechneten Passwort.

Befehl bei dir im Terminal:

sudo mosquitto_passwd -b /etc/mosquitto/passwd <DEVICE_ID <BERECHNETES_PASSWORT>

aus der Datei: mqtt_creds.txt

Bitte darauf achten, dass du den Befehl im exakten Linux-Pfad ausführst, den du oben in der default.conf als 'password_file' angegeben hast.
Wenn die Datei leer ist oder der Abgleich nicht stimmt, verweigert der Broker beim Starten die Verbindung.

---

@petman
die Warnungen oben mit den Rechten sind erst einmal reine Hinweise für die Zukunft, das ignoriert Mosquitto im Moment noch. Dein eigentliches Problem, warum der Broker abbricht, steht in der allerletzten Zeile:

Error: Address already in use

Das bedeutet: Der offizielle Mosquitto-Hintergrunddienst von Linux läuft bereits im System und blockiert den Port 1883!
Du kannst Mosquitto nicht manuell ein zweites Mal im selben Port starten.
Führe bitte einfach diese drei Befehle nacheinander in deinem Terminal aus, um die Rechte zu reparieren, den alten Dienst einmal komplett frisch durchzuschütteln und neu zu starten

1. Bringt die Linux-Besitzrechte der Passwortdatei auf Mosquitto:

sudo chown mosquitto:mosquitto /etc/mosquitto/passwd
sudo chmod 0600 /etc/mosquitto/passwd

2. Startet den bereits laufenden Hintergrunddienst mitsamt deiner neuen Konfiguration neu:

sudo systemctl restart mosquitto

3. Prüft ob Broker jetzt im Hintergrund läuft:

sudo systemctl status mosquitto

---

@petman

sudo chown mosquitto:mosquitto /etc/mosquitto/passwd

Der Doppelpunkt zwischen den beiden Wörtern mosquitto:mosquitto ist das Linux-Zeichen.
Das erste Wort setzt den User auf mosquitto, das zweite Wort setzt zeitgleich die Gruppe auf mosquitto.
Danach sollten alle roten Linux-Rechte-Warnungen in deinem Log Geschichte sein.

Bitte um feedback. Danke.

[maxclaudi]

@Daniel-8
Dankeschön. Helfe gerne.

@Daniel-8 sagte:
Ich bin dir auf jedenfalls sehr dankbar für all das was du gemacht hast auch wenn ich noch nicht alles umgesetzt habe aber daran arbeite.

Das weiß ich doch :-)
Ein großes Dankeschön an Dich für das viele Testen, als ich noch gar kein zenSDK-Gerät hatte.

[maxclaudi]

HINWEIS:

Die offizielle Beschreibung des solarflow-Adapters auf github:

Zitat:

Modes

• Local MQTT It's also possible to use the local only mode. Currently there is no known way for the new Solarflow devices to set the MQTT server directly on the device, so for these you have to use a DNS relay.

ist nicht wahr.

Mein Projekt zURLtool beweist jeden Tag das absolute Gegenteil.
Die lokalen Server-Pfade lassen sich sehr wohl direkt und sicher auf dem Gerät konfigurieren.

[Daniel 8]

@maxclaudi sagte:

@Daniel-8
Dankeschön. Helfe gerne.

@Daniel-8 sagte:
Ich bin dir auf jedenfalls sehr dankbar für all das was du gemacht hast auch wenn ich noch nicht alles umgesetzt habe aber daran arbeite.

Das weiß ich doch :-)
Ein großes Dankeschön an Dich für das viele Testen, als ich noch gar kein zenSDK-Gerät hatte.

Gerne.

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

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

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

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

4. 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:

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

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