Monatsrückblick Oktober 2026 ist online!

[Daniel 8]

@maxclaudi sagte:

@Daniel-8

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

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

[Daniel 8]

wann messt ihr den Zellendrift? Wie groß sollte der maximal sein?
Ich habe jetzt die Steuerung mal so aufgebaut, das er ab 3,45V bis 3,5V an jedem Akku mit 100 Watt lädt. Wenn er über 3,5V kommt, geht die ganze energie soweit es mir möglich ist mit meinen 800W ins Haus, so das ich dann auf 0W Ladung komme.
Bei 3,54V war der eine und bei 3,52V der andere auf 100% Soc.

[Murphy 0]

Ich habe den Zelldrift meiner Akkus in den Griff bekommen.
Ich lade bis 3,42 maxVolt. Das sind 99% SOC.
Ab 90 % SOC reduziere ich auf 900 Watt ab 95 % SOC reduziere ich auf 600 Watt. 2 Akkus AB2000s jetzt 1,5 Jahre alt.

[Daniel 8]

Also misst du den Zelldrift direkt nach dem voll laden. Problem ist ich kann das mit dem 800Pro nicht so 100% steuern, da ich ja über pv modul lade und wenn halt noch zuviel runter kommt also über 800 Watt ist der Rest halt die ladeleistung. Werde es jetzt mal so laufen lassen oder eventuell die reduzierte Ladung schon vorher einsetzen lassen. Aber das ich bei 99% stoppe geht nicht. Dann hoffe ich das der drift weniger wird

[maxclaudi]

Vorläufige Hinweise:

Auszüge aus der Firmware-Analyse (ESP32-Core) demaskieren einen eigenständigen, parallelen Hintergrund-Dienst.

Neben dem bekannten MQTT-Steuerungskanal existiert ein separater, unabhänger HTTP-Client (log-c-tiny_0.1.0), der fest in den Maschinencode einkompiliert ist.

Der technische Befund (siehe ASCII-Auszug des Speichers; die unleserlichen Rohdaten-Spalten wurden zur besseren Übersicht und aus Datenschutzgründen entfernt):

Die Firmware enthält einen dedizierten REST-API-Endpunkt für den Export von Telemetrie-, Fehler- und Systemdaten an das europäische Alibaba-Cloud-Rechenzentrum:

https://zendure-device-log-eu.eu-central-1.log.aliyuncs.com

Dieser Dienst läuft als eigenständige Task.
Das bedeutet:
Wer in den Filtereinstellungen seines Routers lediglich Standard-MQTT-Server

dev.zendure.tech 
zen-iot.com
mq.zen-iot.com
mqtteu.zen-iot.com
app.zendure.tech
app.zendure.tech/as

etc. sperrt, blockiert zwar die App-Steuerung und MQTT, verhindert jedoch nicht den zusätzlichen Datenabfluss über diesen expliziten HTTPS-Kanal.

Das Gerät streamt weiterhin Log-Pakete nach draußen.

Was ist zu tun, wenn man das nicht möchte?
Um den ungewollten Datenverkehr zu unterbinden, müssen in der Firewall des Routers (z. B. in den Filterregeln der Fritz!Box) für die IP-Adresse des Zendure-Geräts mindestens zusätzlich folgende Domains auf die Blacklist (Sperrliste) gesetzt werden:

• Zendure-Logstore:

zendure-device-log-eu.eu-central-1.log.aliyuncs.com

• Alibaba-Basis-Server:

eu-central-1.log.aliyuncs.com

---

IOTState
Der Datenpunkt bzw. Key verwendet folgende Werte:
0: Netzwerkverbindung getrennt
1: Netzwerk wird konfiguriert
2: Verbindung erfolgreich

Dies fand ich bisher nicht öffentlich und ist auch wieder für die Kopierer interessant. Der State wurde noch nirgendwo exakt beschrieben und auch fälschlicher Weise als boolean interpretiert.

Es wurde mir auch Original bestätigt:
1: 配网中 2:连接成功 0: 网络断开

---

Getestet wurden die alte Firmware Version: V1.0.2 mit API2 und die neue Firmwareversion: V2.0.x bzw. V2.0.2 mit API3

Analysen werden fortgesetzt.

Aus den bisherigen Erkenntnissen kann ich das Update zumindest bei den Geräten:

• Hyper 2000 (außer man möchte kein TLS!)
• 1600 AC Plus
• 2400 AC Pro

nur empfehlen.
Speziell bei den 2 letzteren, neuen Geräten kann ich nur dazu raten.

---

edit/PS: 15:07h
Internes SmartMeter-Abfrageintervall der Regelschleife (LCN-srv).

Ein tieferer Blick in den Maschinencode der lokalen Steuerungstask LCN-srv (Local Control Network Service) legt die exakte Taktung offen, mit der der SolarFlow angebundene SmartMeter abfragt.

<edit 27.10.2026 Datenschutz; entfernt.>

technische Fakt:
Sobald ein SmartMeter (z. B. Shelly 3EM, Zendure Satellite etc.) offiziell im System registriert ist, schaltet die Firmware auf ein einkompiliertes Standard-Intervall von exakt 2,059 Sekunden (2059 Millisekunden).

Dieses Intervall ist hardcodiert und kann über die Zendure-App von außen nicht beeinflusst oder verändert werden.
Das ist technisch auch absolut sinnvoll, da direkt danach im Code die Berechnung des gleitenden Durchschnitts des Hausverbrauchs erfolgt:

<edit 27.10.2026 Datenschutz; entfernt.>

Praxis-Tipp für Entwickler lokaler Tools (z.B. ioBroker / Skripte):

Da die interne Hauptschleife der Firmware ohnehin in diesem starren ~2-Sekunden-Takt operiert, bringt es absolut keinen Vorteil, das Gerät lokal im kleinsten Sekundentakt mit Abfragen zu bombardieren.
Ein lokales Abfrage- oder Sende-Intervall von 2 Sekunden läuft absolut synchron zur internen Hardware-Regelung des SolarFlow und schont die Ressourcen des ESP32-Controllers.

Zuzüglich weiterer hardwarebedingter und Netzwerk-Latenzen macht es meiner Meinung nach keinen Sinn, im kleinsten Sekundenbereich jedem einzelnen Watt hinterherzujagen.

---

edit 15:21h zURLtool und Zendure Smartmeter 3CT
Es wird in einiger Zeit ein Update von zURLtool mit erweiterten, geprüften Funktionsumfang geben.

Mit der bisherigen Version ist es jetzt schon möglich das
Zendure Smartmeter 3CT umzuschreiben.

Dazu bekam ich schon feedbacks:

...also tried zURLtool on zendure smart meter 3CT and it worked.

[Daniel 8]

@maxclaudi sagte:

Getestet wurden die alte Firmware Version: V1.0.2 mit API2 und die neue Firmwareversion: V2.0.x bzw. V2.0.2 mit API3

Analysen werden fortgesetzt.

Aus den bisherigen Erkenntnissen kann ich das Update zumindest bei den Geräten:

Hyper 2000 (außer man möchte kein TLS!)
1600 AC Plus
2400 AC Pro
nur empfehlen.
Speziell bei den 2 letzteren, neuen Geräten kann ich nur dazu raten.

Kannst du die 2.0.2 auch für den 800 Pro empfehlen?
Im Moment läuft bei mir noch 2.0.1

[maxclaudi]

@Daniel-8
Ja.
Bzw. obwohl zum Teil unterschiedliche Firmware-Versionen bei diversen Geräten wie z.B. V2.0.2 in der App gemeldet wurden, ist die eigentliche

module-ESP32-Firmware: 
V2.0.59

Aber auch die master-, AC- und BMS- Firmware ist im Update enthalten.
Sollte jetzt ein Update möglich sein und Du schon auf 2.x bist, würde ich alle Updates machen.
Wie es nach einiger Zeit bei neuen Updates in der Zukunft aussieht, kann man nicht vorhersagen.
Zum aktuellen Zeitpunkt sehe ich im Vergleich nur Positives.
Aber die Analysen sind umfangreich und nicht beendet.

[maxclaudi]

zURLtool Zendure Smart Plug Pro
können auch mit zURLTool umgeschrieben und per MQTT gesteuert werden.
Persönlich mag ich die Smart Plug Pro nicht, u. a. wegen des schlechten WLAN-Empfangs und einiger Exemplare, die zu viele Fehlfunktionen haben.
Dazu kann man die Rezensionen und Kommentare auf Amazon und der Herstellerseite lesen.

zURLtool TLS
Wird damit der DNS auf eine andere DNS oder IP umgeschrieben, funktioniert die Zertifikatskette mit Keys.
Aktuell ist es so, dass dann die Zertifikatsgültigkeiten (Beginn 2020 / Ende 2030) nicht geprüft werden.
Tatsächlich ist und wäre das auch schwer realisierbar.
Zumindest meine Geräte haben sich auch mit gesetztem Datum von 1999 und 2041 verbunden.
Das Gerät im Auslieferungszustand „kann“ eine Zeit von 1970 haben.
Die Zeit wird per Cloud bzw. Broker und/oder HTTPS synchronisiert.
Das kann und wird auch erst nach erfolgter MQTT(S)-Verbindung über TLS und Registrierung der Geräte vorgenommen.
Setzt man einen Broker als Bridge ein, dann werden auch Geräte, die kein TLS unterstützen, über TLS verbunden.
Wie z. B. Hub2000, ace1500.

Garantie:

• Solange Variablen verändert werden, die im System für den Nutzer oder das System-Setup vorgesehen sind (z. B. Server-URLs, IDs, MQTT-Pfade), ist das rechtlich wie eine Konfiguration zu werten. Davon fängt kein Gerät an zu brennen!
• Rechtliche Nuance: Sollte ein Firmware-Mod jedoch Schutzmechanismen aushebeln (z. B. Ladeströme oder Temperaturlimits manipulieren), könnte im schlimmsten Fall die Betriebserlaubnis (CE-Konformität) erlöschen. Da es sich beim zURLtool aber ausschließlich um das Setzen von Serververbindungen (URLs/Broker) und IDs handelt, führt ein Ändern von dafür vorgesehenen Variablen zu keinem Brand – die Brandgefahr ist hier ein reines Schreckgespenst.
  Beim Umschreiben von Variablen verliert man keine gesetzliche Gewährleistung. Alles, was über Gesetze hinausgeht, sind freiwillige Leistungen des Herstellers; diese können, müssen aber nicht gewährt werden.

Lokale API ein- und ausschaltbar
Mit Cloud-Ersatz-Broker (lokaler Broker statt Cloud) kann localAPIenable aus- und eingeschaltet werden.
Wenn es ausgeschaltet ist, ist der ESP zusätzlich entlastet und ein Steuern über zenSDK ist nicht möglich.
Erfolgreiche Umsetzung nach Firmware-Analyse (erste öffentliche Dokumentation): Für die Aktivierung von 'localAPIenable' ist kein vorheriges Ein-/Ausschalten von HEMS in der App erforderlich; der Vorgang lässt sich alternativ via MQTT nicht nur Einschalten sondern nach Belieben ein- und ausschalten.

localAPIEnable eingeschaltet:

localAPIEnable ausgeschaltet:

localAPIEnable wieder eingeschaltet:

---

Cloudless:

• Zeitsynchronisation über MQTT möglich. Über NTP und zusätzliches Skript.
  Entweder reales oder auch berechnetes, willkürliches Datum und Zeit.
  Ist aber aufgrund von zURLTool nicht nötig, weil die Zertifikatsgültigkeit dann nicht geprüft wird.

• Inbetriebnahme eines neuen Geräts.
  Es ist jederzeit möglich, mittels zURLTool ein Gerät sofort, lokal ohne Account und ohne App in Betrieb zu nehmen und zu steuern.
  Sowohl über MQTT-Broker als auch per zenSDK. Für zenSDK muss die lokale API aktiviert sein / werden.

Reset:
Es ist möglich, ein Zendure-Gerät über MQTT oder BT auf den Auslieferungszustand zurückzusetzen.
Diese Option wird im Update von zURLtool 2.0 dch implementiert sein.
Achtung: Wenn ein Reset zum Verkauf des Geräts ausgeführt werden soll und/oder man es nicht mehr in der Cloud auf sich registriert haben möchte, muss das Gerät zusätzlich in der App entfernt werden!

Das bisherige setzen des WIFI MODE wie in Version 1.0 ist nicht mehr nötig.
Das WiFi wird gescannt und bei Auswahl des WiFi wird beim übernehmen automatisch der richtige Mode gesetzt.

Token:
Bisherige BT-Tools haben Fehler und verwend(et)en einen nicht richtigen Token.
Der erfundene Token wird nur bei einigen „älteren“ Geräten – ohne Probleme – akzeptiert.
Richtig und empfehlenswert ist er nicht.
Aus verständlichen Gründen kann und werde ich nicht weiter darauf eingehen.

userId
wird bei Account-Erstellung von der Cloud erstellt und zugewiesen. Berechnet wird sie weder von der App noch durch die Firmware.
Sie wird einmalig gesetzt und danach nur ausgelesen und verwendet. Ebenso die consumerId, die nach "bisherigen" Analysen identisch mit der userId ist.

Wird ein Gerät lokal oder mit Cloud-Verbindung in Betrieb genommen, ohne dass ein Account generiert wurde oder die ID fehlerhaft ist, dann wird eine Universal-ID als Fallback akzeptiert.
Für lokalen Betrieb ausreichend.
Bei vorhandenem Cloud- und App-Account mit Benutzername und Passwort und evtl. gleichzeitigem Betrieb mit Cloud ist es besser, die richtige, zugewiesene userId bei allen vorhandenen Geräten zu verwenden.

Die userId kann nur über HTTP(S) gezielt, direkt und sofort abgerufen werden.
zURLtool nutzt beim Schreiben eine gültige Universal-Fallback-userId.
Das ist ausreichend. Aber m. M. n. sinnvoll und besser ist es, die explizit zugewiesene userId zu verwenden, um dem Original vollständig zu entsprechen.

Dazu habe ich ein neues Tool geschrieben: zAppEmulationDeviceInfo
Dabei gibt man in der GUI von der App die Zugangsdaten ein oder in:
deviceInfoConfig.ini

; zAppEmulationDeviceInfo
; example:
; 
; [ACCOUNT]
; EMAIL = user123@gmail.com
; PASSWORD = tOpS3kRet17090811Bc74
;
[ACCOUNT]
EMAIL = user123@gmail.com
PASSWORD = tOpS3kRet17090811Bc74

zAppEmulationDeviceInfo emuliert die App und führt einen Request aus.
Die Antwort steht dann im Textfeld und speichert die wichtigsten Daten in der Datei: Device-List.txt

Es handelt sich hierbei NICHT um die Standard-Device-List. Es sind viel mehr Daten vorhanden, die für die App vorgesehen sind.

HINWEIS: zAppEmulationDeviceInfo verbindet sich über HTTP(S) mit der Cloud, wie die eigentliche App, und ruft nur einmalig die erforderlichen Daten ab.
Mehr nicht.
Es kann und soll gerne ein Virenscan erfolgen!
Wenn man dem Tool wegen der Zugangsdaten nicht vertraut, kann man auch temporär sein Account-Passwort dafür ändern.

zAppEmulationDeviceInfo benötigt eine Seriennummer und einen Activationcode.
Wer bereits zURLtool verwendet, kann die Seriennummer und den Freischaltcode von zURLtool verwenden.
Bzw. zAppEmulationDeviceInfo kann direkt ausgeführt werden, wenn zURLtool schon verwendet wird.
Man kann User-E-Mail und Passwort händisch in der GUI eingeben oder vorbelegen in der Datei: deviceInfoConfig.ini

; zAppEmulationDeviceInfo
; example:
; 
; [ACCOUNT]
; EMAIL = userAccount@gmail.com
; PASSWORD = tOpS3kRet17090811Bc74
;
[ACCOUNT]
EMAIL = userAccount@gmail.com
PASSWORD = tOpS3kRet17090811Bc74

Wenn die consumerId ausgelesen wurde und man seine Geräte auf seine originale, von der Cloud zugewiesene userID setzen möchte, dann kann die bisherige zURLtool-Version das bereits.
zURLtool wurde schon dafür vorbereitet.
In der Datei: config.ini

; config.ini zURLtool (c) maxclaudi 2026
; Für WiFi SSID und PASSWORD bitte keine Leerzeichen, Umlaute etc. verwenden
; Broker: Bitte nur reine IP oder DNS eingeben. Kein ":" und kein Port.
; Der Port ist in der Firmware fest hinterlegt. Entweder Port:1883 ohne TLS oder Port 8883 mit TLS.
; TLS-Verbindungen können nur mit gültigen Zertif. / Keys verwendet werden.
; 
; MODE = WLAN-Sicherheitsmodus
; 3 = WPA2-PSK (Standard)
; 4 = WPA/WPA2-PSK
; 5 = WPA2-Enterprise
; 6 = WPA3-PSK
; 7 = WPA2/WPA3-PSK
; Gültige Werte: 3-7; bei fehlendem/ungültigem Wert wird automatisch 3 verwendet.
; MODE = 3
;
; Zurück zur Cloud:
; BROKER = mq.zen-iot.com
;
; Beispiele: 
; [WIFI]
; SSID = meinWLAN
; PASSWORD = tOpS3kRet17090811Bc74
; MODE = 3
; 
; [MQTT]
; BROKER = 192.168.12.200
; MODE = 3
;
[WIFI]
SSID = meinWLAN
PASSWORD = tOpS3kRet17090811Bc74
MODE = 3
EXTRA = <userID>

[MQTT]
BROKER = 192.168.12.200
;BROKER = mq.zen-iot.com

Statt "<userId>" die tatsächlich abgefragte userId einfügen.
Beispiel:

EXTRA = 43521

Wenn consumerId in EXTRA angeben wird, überträgt das zURLtool genau diese Nummer als lokale userId auf das Gerät.
Dadurch wird sichergestellt, dass die lokale Broker-Konfiguration exakt mit der Identität übereinstimmt, die von in der Cloud registrierten Geräten erwartet wird; auf diese Weise werden jegliche internen Diskrepanzen bei der Autorisierung auf Chip-Ebene vollständig beseitigt.
Wird das zURLtool ohne das Feld EXTRA verwendet, kommt eine gültige, generische Fallback-userId zum Einsatz.
Dies funktioniert wie vorgesehen, da sie als universelle userId akzeptiert wird.
Sie stimmt jedoch nicht mit der spezifischen userId überein, die von der Cloud für den jeweiligen Benutzer generiert wurde.

Auch wenn die universelle Fallback-userId funktioniert, ist es meiner Meinung nach sinnvoller, die von der Cloud zugewiesene userId zu verwenden.
Die Cloud-basierte userId wird üblicherweise erst bei der Einrichtung eines Kontos erstellt.

Der Fallback-Mechanismus ist für die Verbindung zur Cloud gedacht, wenn das Gerät vollständig offline betrieben wird oder die userId ungültig ist.
Da das zURLtool nur vorhandene, bekannte oder vordefinierte Werte setzen kann – und während der Einrichtung weder über eine HTTP(S)-Verbindung verfügt noch weiß, ob ein Konto existiert –, wird standardmäßig die universelle Fallback-userId verwendet, wenn das Feld EXTRA weggelassen wird oder einen ungültigen Wert enthält.

---

Download zAppEmulationDeviceInfo in 3 Teilen:
zAppEmulationDeviceInfo.zip
zAppEmulationDeviceInfo.z01
zAppEmulationDeviceInfo.z02

[maxclaudi]

Download zAppEmulationDeviceInfo in 3 Teilen.
Teil 1:

zAppEmulationDeviceInfo.zip

Achtung: Falls die Datei nach dem Download einen anderen Namen als zAppEmulationDeviceInfo.zip hat, benenne sie bitte entsprechend um.

[maxclaudi]

Download zAppEmulationDeviceInfo in 3 Teilen.
Teil 2:

zAppEmulationDeviceInfo.z01

Achtung: Falls die Datei nach dem Download einen anderen Namen als zAppEmulationDeviceInfo.z01 hat, benenne sie bitte entsprechend um.

[maxclaudi]

Download zAppEmulationDeviceInfo in 3 Teilen.
Teil 3:

zAppEmulationDeviceInfo.z02

Achtung: Falls die Datei nach dem Download einen anderen Namen als zAppEmulationDeviceInfo.z02 hat, benenne sie bitte entsprechend um.

[maxclaudi]

@Daniel-8 sagte:
Habe dann mal den setsocComp auf 1 und 2 geschrieben. Konnte aber keinerlei Veränderung feststellen

Bisherige Analyse von socCompSwitch und Überraschung:

Der HEMS-Code wurde dabei ausdrücklich nicht als Verbraucher des separat gesetzten socCompSwitch gewertet!

Für dieses konkrete Firmware-BIN aktiviert socCompSwitch keine im analysierten ESP32-Code nachweisbare Funktion.

Damit gilt für die analysierte aktuelle module-MASTER/ESP32-Firmware: V2.0.59 (in der App ausgewiesen u. a. als V2.0.2):

SocCompSwitch unter properties ist in dieser Firmware bereits als schreibbare Option vorhanden und kann gesetzt werden.
0 ist der Standardwert.

Für `SocCompSwitch unter properties konnte im analysierten ESP32-BIN jedoch noch keine funktionale Auswertung und damit keine nachweisbare Wirkung gefunden werden.

Die Option ist somit in der aktuellen Firmware bereits vorbereitet, hat nach dem derzeitigen Analyseergebnis aber noch keine erkennbare Funktion.

Ob SocCompSwitch in einer zukünftigen Firmware tatsächlich eine Funktion erhält, zunächst ohne Wirkung bleibt oder später wieder entfernt bzw. geändert wird, lässt sich aus der aktuellen Firmware nicht ableiten.

---

Edit 30.09.2026
Schade, der Edit musste leider sein.
Urheberrecht (Copyright) am Code und der Firmware liegt vollständig beim Hersteller. Um rechtliche Probleme für mich und das Forum zu vermeiden, kann ich keinen kleinen Code-Auszug posten.

[maxclaudi]

@Murphy-0 sagte:

@maxclaudi
super Sache, Cloudfree ohne Neustart vom Hyper ist eine echte Verbesserung.
Sollte man den Hyper mit neuester Firmware Cloudfree betreiben wäre die ultimative Lösung mit so einer Software zurück auf unverschlüsseltem Datentransfer zum mqtt Server stellen zu können. 😁

@Murphy-0 Technisch ist der Weg in der Firmware tatsächlich vorhanden. Die Variablen für eine unverschlüsselte Verbindung existieren im Code:

Edit
Schade, der Edit musste leider sein.
Urheberrecht (Copyright) am Code und der Firmware liegt vollständig beim Hersteller. Um rechtliche Probleme für mich und das Forum zu vermeiden, kann ich keinen kleinen Code-Auszug posten.

Broker ohne TLS über 1883 unter bestimmten Bedingungen möglich, ohne in die Firmware einzugreifen.

Das Problem dabei:
Das Ganze sauber zu analysieren, ist extrem viel Arbeit. Ich schaue mir an, ob es einen offiziell vorgesehenen und einfachen Weg gibt, diese Parameter per Bluetooth oder über ein MQTT-Kommando zu steuern.
Sollte es diese integrierte Möglichkeit nicht geben, werde ich das nicht weiter verfolgen.
Ein Eingriff in die Firmware (wie das Patchen von Speicherbereichen oder Flashen modifizierter Partitionen) kommt für mich nicht in Frage.
Die Firmware wird von mir niemals verändert!

Mein Fokus liegt nur rein auf dem Analysieren der vorhandenen und funktionierenden HTTP(s)-, MQTT- und Bluetooth-Konfigurationen, die vom Hersteller bereits eingebaut sind und genutzt werden können.

---

Update 30.09.2026 01:26h:
Inzwischen habe ich diesen Weg weiter verfolgt. Aktuell ist noch unklar und muss weiter analysiert werden, ob das reine Setzen eines einzelnen Flags ausreicht, damit die Firmware in den unverschlüsselten Modus (Port 1883 statt 8883 mit TLS) wechselt und dieser Zustand auch dauerhaft erhalten bleibt.
Für heute brauche ich nach stundenlanger Arbeit aber erst mal dringend eine Pause.

[T-147]

Guten Morgen allerseits,

mein SF800 Pro2 läuft jetzt seit gut 2 Monaten mit dem Blockly und wurde aufmerksam von mir beobachtet. Ein paar Dinge sind mir persönlich aufgefallen, zu denen ich Euch mal befragen wollte.
Außerdem habe ich dann mit erstaunen festgestellt, wie viel sich in der Zeit wieder in dem Blockly verändert hat. Beim umstellen der Vorlage auf meine Gerätschaften kam mir dann noch eine Idee, dazu aber gleich mehr.

Im Juli und August war es bei meinem SF800 Pro2 mit 2 Akkus kein Problem, das Ding so ziemlich täglich auf 100% zu laden. Heißt also, es gab keine automatische Kalibrierung.
Jetzt im September wurde das mit den 100% aber schon schwieriger und ich hab in meinen Aufzeichnungen gesehen, dass immer mal wieder nachts um 1:00 Uhr (Standard-Kalibrierungszeit der App) das Laden mit voller Last begonnen und kurz darauf wieder beendet wurde. Also keine vollständige Kalibrierung, weil das Blockly sofort wieder die Steuerung übernimmt, wenn der Akku etwas aufgeladen ist und wieder auf Entladen wechselt. Das ganze kann ich tagsüber beliebig reproduzieren, wenn ich manuell auf Laden stelle (zB über die App). Da kommt mir die Frage: Wie realisiert Ihr das mit dem Kalibrieren, ohne dass die Steuerung dazwischen funkt?
Das aktuelle Blockly hat zwar Parameter für DPL an/aus, aber das wird hier offensichtlich nicht für eine Kalibrierung eingesetzt. Oder hab ich tatsächlich was übersehen?

Eine weitere Sache: Beim Aufladen morgens schwenkt das System immer wieder zwischen Laden/Entladen hin und her. Ich würde dem System gerne verständlich machen, dass der Akku morgens erst bis zB 15% aufladen soll, bevor er überhaupt wieder entladen darf. Er soll aber trotzdem nachts bis zB 10% entladen dürfen (ist das verständlich ausgedrückt?) Ich hab das Gefühl, das aktuelle Blockly könnte das realisieren, aber da blick ich noch nicht ganz durch.

Und die dritte Sache: in dem Blockly sind ja wahnsinnig viele Objekt-IDs, die ich jetzt erstmal alle einzeln anpassen musste. Könnte man das evtl durch eine Variable ersetzen? Dann müsste man die Variable nur in den Settings zu Beginn des Blockly einmal anpassen und alle Objekt-IDs würden damit automatisch angepasst. Bin das Script jetzt 3x durch und hab jedes Mal irgendwo was vergessen anzupassen

So in dieser Art vielleicht:

Edit:
Und manchmal dauert es verhältnismäßig lang, bis der SF800 aus dem Bypass wieder ans Laden geht morgens/vormittags. Teilweise hab ich 15 oder 20min lang -150W auf dem Stromzähler stehen und es wird trotzdem nicht aufgeladen. Veränder ich den Wert dann in der App oder im ioBroker manuell springt die Regelung sofort wieder an.

Besten Dank und weiterhin frohes Schaffen
Marian

[maxclaudi]

Bin momentan zu beschäftigt. Deshalb nur kurz zu deinem 'Edit':

@T-147 sagte:
Edit:
Und manchmal dauert es verhältnismäßig lang, bis der SF800 aus dem Bypass wieder ans Laden geht morgens/vormittags. Teilweise hab ich 15 oder 20min lang -150W auf dem Stromzähler stehen und es wird trotzdem nicht aufgeladen.

Eine Leistung von 150 Watt über 20 Minuten entspricht einem Verbrauch von 0,05 kWh (Kilowattstunden). Bei einem durchschnittlichen Strompreis von rund 37 Cent pro kWh sind das ca. 1,85 Cent.
So schlimm ist das m. M. n. nicht. Die Hardware wird es Dir danken.

[T-147]

@maxclaudi
Kein Ding, ist ja auch kein Weltuntergang. Läuft ja sonst alles echt super.

Geht mir auch überhaupt nicht um die paar Watt, die ins Netz gehen. Vor dem SF800 und deinem Script ging aufs Jahr gesehen 50% von meinem PV-Ertrag ins Netz, jetzt sind es weniger als 10%!
Mir gehts vielmehr um das reine Verständnis der Funktionsweise des SF800 und des Scripts/Blockly, also was genau wann wofür zuständig ist.

Ich switche am Wochenende mal auf das aktuellere Blockly und schaue einfach mal, inwieweit sich das Verhalten ändert, ist ja doch einiges dazugekommen.

Und gerne nochmal: Vielen Dank für deine Arbeit und den Einsatz!

[petman]

@T-147 sagte:

Edit:
Und manchmal dauert es verhältnismäßig lang, bis der SF800 aus dem Bypass wieder ans Laden geht morgens/vormittags. Teilweise hab ich 15 oder 20min lang -150W auf dem Stromzähler stehen und es wird trotzdem nicht aufgeladen. Veränder ich den Wert dann in der App oder im ioBroker manuell springt die Regelung sofort wieder an.

Besten Dank und weiterhin frohes Schaffen

Hallo ich habe die gleichen Probleme bei meinem SF800pro2 am Morgen. Scheint ein Problem der Firmware zu sein.
Letzte Woche hatten wir einen Stromausfall einer Phase im Netz. Als der Strom wieder ok war, hat der SF800pro2 mit maximaler Leistung aus dem Netz geladen obwohl nur max 50W eingestellt ist.

peter

[T-147]

@petman

Ich fahre aktuell noch auf Firmware 2.0.0. Wie sieht's bei dir aus?

[maxclaudi]

• Datenschutz, entfernt

[maxclaudi]

@T-147 sagte:

@petman

Ich fahre aktuell noch auf Firmware 2.0.0. Wie sieht's bei dir aus?

Falls V2.0.2 angeboten wird: kann man m. M. n. bedenkenlos verwenden.

Bei > V2.0.2
z.B. V2.0.4 kann ich nicht bewerten.