Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[Murphy 0]

Mein cloudfree Hyper steht im Haus mit 2x 12 cm Lüfter temperaturgesteuert.
Ich kann keinerlei Leistungsreduzierung bei mir feststellen.

[MP_Trixi]

Ja, Temperatur kanns fast nicht sein. Die WR meiner beiden großen Anlagen arbeiten bei bedeutend höheren Temperaturen. Auch bei anderen Geräten sind jetzt 40° nicht übermäßig viel. Außerdem war es schon viel heißer im Juni und Juli. Ich hatte es die ganze Nacht durch, alle 30min bei tiefsten hyperTmp von 27°.

Die schlaue KI meint, dass „das exakte 30-Minuten-Intervall bei Zendure auf ein tiefgreifenderes Cloud-Sync- bzw. Watchdog-Problem hindeutet: Der Server verliert die Verbindung zum Gerät oder verwendet ein beschädigtes Nutzerprofil und setzt den Speicher nach dem Timeout auf Sicherheits-Standards zurück.“
Nun ja. Ich hab mal die App neu installiert, ab-/angemeldet, das Gerät ins HEMS und wieder raus, das Gerät aus der App entfernt und neu zum Konto hinzugefügt, in der Hoffnung dass sich da irgendwas resettet, ein Cache sich leert, die Cloud sich berappelt, was auch immer. Ohne Erfolg. Ich bin versucht, nun doch das FW Update zu machen (vorher brauche auch gar nicht den Support kontaktieren).

Wenn ich es richtig verstanden habe laufen da draußen Geräte mit der 2.x FW und dem Script ohne Probleme, richtig?

[maxclaudi]

@Murphy-0 sagte:
Mein cloudfree Hyper steht im Haus mit 2x 12 cm Lüfter temperaturgesteuert.
Ich kann keinerlei Leistungsreduzierung bei mir feststellen.

Die Hyper sind dennoch anfällig für hohe Temperaturen - Wärmestau / Thermal Trap.

M. M. n. durch übertriebenes Potting nur um IP 65 zu erreichen.
Wasserschutz IP65: Hält Spritzwasser und Regen sowie leichtem Strahlwasser z. B. aus einem Gartenschlauch stand.
Dadurch wurden sie automatisch zu einem Anti-Reparatur-Design und vergossenen Wegwerf-Baugruppen.

Wird vermutlich bei den neueren outdoor Geräten nicht anders sein.
Versuche nichts mehr zu öffnen.

Zusätzliche Lüfter sind nur zu empfehlen und essentiell

[petman]

@maxclaudi sagte:

scheene schütza :-)

He, das Gen fehlt mir, ich stamme aus DD ;-)

@maxclaudi sagte:

was wurde bzw. musste für SF800Pro 2 angepasst werden und warum ?
Ist nicht alles vollständig?

Ich hatte noch kein Firmwareupdate gemacht und da fehlte offensichtlich "set soc state" , kam jedenfalls immer als Fehler beim Start des Javascript.
Heute alles umgebaut und Firmware aktuallisiert.
Jetzt ist "soc state" auch da.
Bin aber noch etwas irritiert, welche Scripe ich für die Nulleinspeisung benötige.
Der SF1200+AB1000 läuft jetzt über den iob Zendure Solarflow Adapter und wird zusammen mit dem Hoyml WR über DTUonBat gesteuert.
Der SF800Pro2+2xAB2000 sollte mit dem Blockly aus diesem Thred "DPL-Nulleinspeisung via zenSDK" vom 30.6.26 ergänzt durch minVolt Batterieschutz gesteuert werden.
Welches deiner Javascripte brauche ich dazu?
Aktuell laufen "Zendure zenSDK Adapter-Ersatz für ein Zendure-Gerät" vom 22.06.26 20:00h und "JavaScript: Zendure SolarFlow 800 Pro (SF2400AC) via zenSDK HTTP" vom 2026.01.13_16.05h .
In der DTUonBat hab ich die Aktuallisierung auf 5 s gestellt damit er nur bei Bedarf über dem vom SF800Pro2 anspringt.

Peter

[maxclaudi]

freedom

[maxclaudi]

@petman sagte:
...... Bin aber noch etwas irritiert, welche Scripe ich für die Nulleinspeisung benötige....
Der SF800Pro2+2xAB2000 sollte mit dem Blockly aus diesem Thred "DPL-Nulleinspeisung via zenSDK" vom 30.6.26 ergänzt durch minVolt Batterieschutz gesteuert werden.
Welches deiner Javascripte brauche ich dazu?

Nur das eigentliche zenSDK zenSDK Script

in Verbindung mit z.B. dieser Basis-Vorlage: Blockly

[maxclaudi]

@MP_Trixi sagte:

Ja, Temperatur kanns fast nicht sein....

Firmware übrigens auch nicht, das weiß ich mittlerweile absolut sicher.

Wenn ich es richtig verstanden habe laufen da draußen Geräte mit der 2.x FW und dem Script ohne Probleme, richtig?

Nein, das hat(te) mit der Firmware-Version überhaupt nichts zu tun.

Es war und ist hier eindeutig die Cloud.

So viel zum Thema „zenSDK und lokale Steuerung“.

Konnte den AC1600plus nun endlich komplett offline nehmen.
Habe die Cloud-URL umgeschrieben, sodass der AC1600+ jetzt keinerlei Verbindung mehr zum Internet hat – und siehe da:
Plötzlich werden rasend schnell und absolut konstant die Daten gesendet.
Alle Probleme sind schlagartig verschwunden.
Die SoC-Anzeige stimmt sofort und der AC1600+ arbeitet mit der Firmware komplett einwandfrei.

Sobald man den Cloud-Zwang nimmt, läuft das System genau so, wie es von Anfang an hätte laufen sollen.

Das Ganze umzusetzen war alles andere als einfach, und ich muss an der Software definitiv noch weiterarbeiten... aber das wird schon

[petman]

@maxclaudi sagte:

Nur das eigentliche zenSDK zenSDK Script

in Verbindung mit z.B. dieser Basis-Vorlage: Blockly

dankeschön, habe jetzt alles wie es soll und es läuft.

Warte nun auf den "Cloudtrenner" ;-))

Peter

[Daniel 8]

@maxclaudi sagte:

@MP_Trixi sagte:

Ja, Temperatur kanns fast nicht sein....

Firmware übrigens auch nicht, das weiß ich mittlerweile absolut sicher.

Wenn ich es richtig verstanden habe laufen da draußen Geräte mit der 2.x FW und dem Script ohne Probleme, richtig?

Nein, das hat(te) mit der Firmware-Version überhaupt nichts zu tun.

Es war und ist hier eindeutig die Cloud.

So viel zum Thema „zenSDK und lokale Steuerung“.

Konnte den AC1600plus nun endlich komplett offline nehmen.
Habe die Cloud-URL umgeschrieben, sodass der AC1600+ jetzt keinerlei Verbindung mehr zum Internet hat – und siehe da:
Plötzlich werden rasend schnell und absolut konstant die Daten gesendet.

Also noch schneller per ZenSDk wenn er von der cloud getrennt ist?

Alle Probleme sind schlagartig verschwunden.
Die SoC-Anzeige stimmt sofort und der AC1600+ arbeitet mit der Firmware komplett einwandfrei.

Was meinst du mit sofort? Das heißt wenn er noch mit der cloud verbunden ist, rechnet er den soc falsch?

Sobald man den Cloud-Zwang nimmt, läuft das System genau so, wie es von Anfang an hätte laufen sollen.

Das Ganze umzusetzen war alles andere als einfach, und ich muss an der Software definitiv noch weiterarbeiten... aber das wird schon

Was meinst du denn mit weiterarbeiten an der Software? Wo hackt es noch?

[maxclaudi]

Seriennummer direkt auf dem Zendure-Gerät sichtbar?

Hallo zusammen,
könnt Ihr mir bitte kurz bestätigen, ob auf wirklich jedem Zendure-Gerät ein Typenschild oder ein Aufkleber mit der Seriennummer angebracht ist?

Beispiele:

• HAB5MCADH280002
• FED3MCDHA320002

Mir geht es nicht um Eure konkreten Seriennummern, sondern rein um die Info, ob diese bei allen Modellen direkt am Gehäuse für Euch sichtlich zu finden ist.

Dass sie auf der Originalverpackung steht, weiß ich.

Danke für Eure Rückmeldungen!

[maxclaudi]

@Daniel-8 sagte:
Also noch schneller per ZenSDk wenn er von der cloud getrennt ist?

Ja, man kann aussuchen, ob man zenSDK verwendet oder reines MQTT. Wobei MQTT zu bevorzugen wäre, weil die Daten sofort und nur wenn nötig automatisch vom Gerät published werden.

Was meinst du mit sofort? Das heißt wenn er noch mit der cloud verbunden ist, rechnet er den soc falsch?

Sofort bedeutet sofort ;-)

Sobald das Gerät den lokalen Broker als Cloud-Broker akzeptiert, gibt es keinen Zendure-Cloud-Broker-Client mehr, der dazwischenfunkt.
So werden (und können) keine Befehle an das Zendure-Gerät gesendet werden, die man nicht möchte.

Falsch berechnet wird von der Firmware nichts. Aber die Cloud hat die Werte in der Vergangenheit fehlerhaft korrigiert und auch diverse Einstellungen einfach überschrieben.
Lokal entscheidet man das eigenverantwortlich.
Die Firmware selbst ist m. M. n. gut genug und reagiert selbstständig auf z. B. kritische Wärme.

Sobald man den Cloud-Zwang nimmt, läuft das System genau so, wie es von Anfang an hätte laufen sollen.

Das Ganze umzusetzen war alles andere als einfach, und ich muss an der Software definitiv noch weiterarbeiten... aber das wird schon

Was meinst du denn mit weiterarbeiten an der Software? Wo hackt es noch?

Es hakt nicht. Zu viel zum Schreiben. Ich arbeite z. Z. jeden Tag mehr als 12 Stunden an der Protokoll-Analyse und an weiterem Code.

[MP_Trixi]

@maxclaudi
Hi, ja mein SF800Pro2 hat einen Aufkleber mit QR Code und SN

Verstehe ich das richtig? Du hast nun im Gerät das MQTT-Cloudziel auf einen lokalen Broker umgebogen, der auf deinem ioBroker läuft. Damit hast aktuell die richtigen Daten per Push in Echtzeit und machst „nur noch“ die reaktive Steuerung über dein hier thematisiertes Script?

[maxclaudi]

@MP_Trixi sagte:

@maxclaudi
Hi, ja mein SF800Pro2 hat einen Aufkleber mit QR Code und SN

Dankeschön!

Bitte noch mehr Leute – gerne auch von anderen Geräten – kurz bestätigen: Es geht mir rein darum, ob die Seriennummer gut ersichtlich physisch am Gehäuse vorhanden ist.

Verstehe ich das richtig? Du hast nun im Gerät das MQTT-Cloudziel auf einen lokalen Broker umgebogen, der auf deinem ioBroker läuft. Damit hast aktuell die richtigen Daten per Push in Echtzeit....

fast Richtig.
Die Cloud-URL wird im Gerät dauerhaft auf eine lokale IP oder DNS umgeschrieben, damit sich das Zendure-Gerät ausschließlich über diese Zieladresse mit dem eigenen Broker verbindet.
Allerdings nur mit Mosquitto als Broker getestet.
iob MQTT-Adapter ist als MQTT-Client mit dem mosquitto-broker verbunden.

und machst „nur noch“ die reaktive Steuerung über dein hier thematisiertes Script?

Entwickle eine Software, die zuerst einmal nur dazu dient, die Cloud-DNS auf eine beliebige URL umschreiben zu können.
Wenn du mit "hier thematisiertes Script" das zenSDK-Steuerungs-Skript dieses Threads meinst:
Die Steuerung über HTTP läuft darüber wie gewohnt weiter.

Für die spätere MQTT-Nutzung muss das zenSDK-Skript dann entsprechend angepasst werden

[paul53]

@maxclaudi [sagte]: Die Cloud-URL wird im Gerät dauerhaft auf eine lokale IP oder DNS umgeschrieben

Du greifst in die Firmware ein?

[maxclaudi]

@paul53 sagte:

@maxclaudi [sagte]: Die Cloud-URL wird im Gerät dauerhaft auf eine lokale IP oder DNS umgeschrieben

Du greifst in die Firmware ein?

Nein, ich greife nicht in die Firmware ein.

Es wird nichts modifiziert. Die originale Firmware von Zendure bleibt zu 100 % unangetastet.

Ich nutze lediglich die standardmäßigen Bluetooth-Befehle, die die Firmware von Haus aus bereitstellt.

Das Skript verhält sich für das Gerät genau so wie die originale App, greift auf die Konfigurations-Variablen im Speicher zu und überschreibt dort schlicht den Eintrag für die Cloud-URL mit der IP eines eigenen lokalen Brokers.

Es funktioniert quasi wie eine zusätzliche Länderauswahl, bei der man sich einfach mit einem anderen Server verbindet. Das muss die App/Firmware von Haus aus anbieten, sonst wären die Geräte dauerhaft fest an ganz bestimmte AWS-Server gebunden ;-)

[maxclaudi]

PS @paul53: ...könntest du mir bei der Gelegenheit kurz bestätigen, ob bei deinem Modell die Seriennummer physisch auf dem Gehäuse/Typenschild ablesbar ist? Wie gesagt, ich will die Nummer nicht wissen, nur ob sie bei dir draufklebt. Danke!

Beispiele:

• HAB5MCADH280002
• FED3MCDHA320002

[paul53]

@maxclaudi [sagte]: Seriennummer physisch auf dem Gehäuse/Typenschild ablesbar ist?

Ja. Wozu ist das wichtig?

[maxclaudi]

@paul53 sagte:
Ja.

Dankeschön.

Wozu ist das wichtig?

Für meine Software.

Wenn jemand mehrere Geräte im Haus hat, muss man beim Starten des Tools natürlich das richtige Gerät auswählen können.

Zwar wird beim Bluetooth-Scan die BT-MAC-Adresse und der Bluetooth-Name des Geräts angezeigt – als Entwickler weiß man damit schnell, was zu wählen ist.
Für den normalen Anwender ist das aber oft kryptisch.

Die Software soll eine sichere, einfache und für jeden verständliche Möglichkeit bieten, das gewünschte Gerät anhand der Seriennummer eindeutig zu identifizieren, bevor man es umschreibt.

[paul53]

@maxclaudi sagte: Falsch berechnet wird von der Firmware nichts.

Das kann ich nicht bestätigen.
Ich betreibe den SF 800 Pro 2 ohne PV als reine Notstromlösung. In diesem Fall ist die Berechnung des SoC "völlig daneben".
Folgende Werte des BMS sind ab ca. 16 Stunden nach 100-%-Kalibrierung etwa 3 Tage lang konstant:

Danach sinkt die Spannung langsam, aber der SoC bleibt weiterhin auf 100 %. Die Batterie wird mit etwa 0,2 A entladen (Selbstentladung / BMS?). Die folgenden DP-Werte passen nicht:

• state: Müsste 2 oder 0 sein, da die Batterie nicht geladen, sondern entladen wird, wie man an der Spannung sieht.
• batcur: Das Vorzeichen müsste negativ sein

"socLevel" wird anscheinend mittels "batCur" berechnet, was erklärt, dass nach Beendigung der Ladung mit "socSet" = 85 % der SoC weiter um jeweils 1 % alle 2 Stunden steigt anstatt mit dieser Rate zu sinken.

Anmerkung: Ich habe den SF per Router vom Internet abgekoppelt.

[maxclaudi]

@paul53
Bin bei SoC kein Erbsenzähler ;-)
Der SoC (State of Charge) ist letztlich immer ein Schätzwert und funktioniert bei keinem PV-System perfekt.

Zudem muss man die Zellen regelmäßig vollpacken "grillen" – also auf 100 % laden –, damit das BMS die Zellen balancieren kann.

Selbst in diesem Bereich schützt einen Zendure recht gut, da die angezeigten 100 % in der Realität nicht die absoluten Belastungsgrenzen der Zellen sind.

Das lässt sich recht gut an der Spannung (Voltage) ablesen – vorausgesetzt, die Messwerte stimmen.
Jedenfalls sind reale Messwerte immer noch genauer als reine SoC-Schätzungen.

Um die Anzeige wirklich zu kalibrieren, müsste man das System eigentlich regelmäßig so tief wie möglich entladen und wieder komplett vollmachen.

Nur so passen die SoC-Werte "halbwegs".

Soweit ich gelesen habe und meine mich erinnern zu können, betreibst du deine Batterie(n) ja sehr schonend im entspannten Wohlfühlbereich zwischen 20 % und 85 %.
Das ist für die Lebensdauer der Zellen absolut top!
Allerdings bedeutet das im Umkehrschluss leider auch, dass du den angezeigten SoC-Werten in diesem Korridor noch weniger vertrauen kannst.

PS:
Dass die Werte konstant bleiben und viel schief geht liegt vermutlich daran, dass keine Inet-Verbindung besteht - dann steigt zenSDK nach und nach aus.
Es wird am Ende zu alle xx sek versucht den Broker zu erreichen. Gibt es keinen...