Monatsrückblick Juli / August 2026 ist online!

[maxclaudi]

@Daniel-8 sagte:
Verstehe ich das richtig? Wenn man auf lokalen Broker umstellt mit deinem Programm, läuft irgendwann die Zertifikatskette ab und es ist keine Steurung mehr möglich?

@Daniel-8 Im Standard-Fall ohne Skript-Hilfe:
Ja, absolut richtig verstanden und ist völlig normal bei TLS. Die Zertifikatsgültigkeit betrifft auch bei normalem Betrieb alle Geräte und die Cloud selbst.

Jedes TLS-Zertifikat hat ein hartes Ablaufdatum – sowohl auf dem Server (Broker) der Cloud als auch auf dem Client (Zendure-Gerät).
Die aktuellen Zertifikate laufen in diesem Fall im Mai 2030 ab.

Zuvor muss es von Zendure also irgendwann ein Firmware-Update geben, allein um neue Zertifikate und Keys auf die Hardware aufzuspielen.

Wenn das Zertifikatsende erreicht ist und die Zertifikate auf auch nur einer Seite (Broker oder Client) ungültig werden, kann keine gesicherte Verbindung mehr hergestellt werden.
Weil die Zertifikate fest in der Firmware des Zendure-Geräts implementiert sind, verweigert die Firmware dann krypto-technisch den Handshake und der TLS-Verbindungsaufbau bricht unweigerlich ab.

Genau dafür habe ich ein kleines ioBroker-Skript als "Schutzschild" :-)
Sobald das Gerät bei Erreichen des Datums seine gewöhnliche Anfrage an meinen lokalen Broker stellt, klinkt sich das Skript ein und prüft, ob es was zu tun gibt.

• Wenn innerhalb der Zertifikatsgültigkeit, wird die Standard-Antwort gesendet.
• Wenn außerhalb der Zertifikatsgültigkeit, dann generiert das Skript eine gültige Antwort und sendet sie dem Client.

Das bedeutet konkret:
Solange mein ioBroker-Skript im Hintergrund läuft und man keine neuen Firmware-Updates mit geänderten Keys erzwingt (wenn man isoliert lokal arbeitet, ist man ja sowieso offline), läuft die Steuerung auch nach 2030 völlig ungerührt und "unendlich" weiter. Man muss also keine Angst vor abgelaufenen Zertifikaten und einem plötzlichen Steuerungs-Ausfall haben. :-)

Der Aufwand dafür ist extrem gering:

• Im ioBroker reicht ein kleines, ressourcenschonendes Skript bzw. die paar Zeilen implementiere ich fest in mein Geräte-Steuerungs-Skript.
• Für den eigenen Mosquitto-Broker (als Cloud-Ersatz) ist lediglich eine einzige zusätzliche Zeile in der Konfiguration nötig:

require_certificate false

Das System ist dabei absolut fehlertolerant: Selbst wenn das Skript mal ausgeschaltet ist, für 2–3 Tage nicht läuft oder die Verbindung zwischendurch getrennt wird, passiert überhaupt nichts. Die Kommunikation läuft sofort wieder reibungslos an.

Edit / PS:
Für den absoluten Notfall – sollte das Gesamtsystem nach 2030 (z. B. nach einem harten Hardware-Reset oder Netzausfall) doch mal ins Stocken geraten – werde ich das zURLtool rechtzeitig überarbeiten.
Damit ist garantiert, dass sich das Gerät beim erneuten Beschreiben per Bluetooth auf jeden Fall sofort fehlerfrei mit dem lokalen Broker auch nach Zertifikatsende 2030 verbindet, sofern dieser richtig und mit der zusätzlichen Konfigurationszeile aufgesetzt ist und natürlich im Zendure-Gerät weiterhin die passende Firmware vorhanden ist.

---

Edit / PPS:
Rein technische Zusatzinfo:
Solange eine Verbindung stabil steht, werden die Zertifikate im laufenden Betrieb nicht permanent erneut überprüft.
Eine Überprüfung der Verbindungszertifikate und Keys erfolgt technisch immer nur bei einem frischen Verbindungsaufbau (Reconnect) – also wenn die Verbindung aus irgendeinem Grund (wie einem Netzwerkfehler, Router-Neustart etc.) neu hergestellt werden muss.
Das kann im Alltag, je nach Stabilität des lokalen WLANs, häufiger oder auch nur extrem selten der Fall sein.
Während des herkömmlichen Betriebs bei einer stehenden Verbindung findet keine laufende Zertifikatsprüfung statt.

[maxclaudi]

@paul53 sagte:
Der SF ist schon seit Wochen vom Internet getrennt.

Ist das Gerät in der App Offline gelistet?
Hast Du nur der Ip des Geräts den Zugang verwehrt oder auch zusätzliche DNS blockiert?

Driftet TimeUpdate bzw. timestamp schon etwas von der iobroker Systemzeit?

[paul53]

@maxclaudi sagte: Driftet TimeUpdate bzw. timestamp schon etwas von der iobroker Systemzeit?

"TimeUpdate (timestamp)" geht etwa 30 s nach.

@maxclaudi sagte:

Hast Du nur der Ip des Geräts den Zugang verwehrt oder auch zusätzliche DNS blockiert?

Ich habe die Internet-Sperre in der Fritz!Box genutzt. Keine Ahnung, ob die auch DNS blockiert.

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