Monatsrückblick Juli / August 2026 ist online!

[Daniel 8]

@Murphy-0 sagte:

Der Kopplungsmodus benutzt Bluetooth.

Danke für die Info. Ich habe leider kein Bt am PC. Muss ich dann über externen Stick machen

[MP_Trixi]

@maxclaudi
Hi, ich nutze ja seit Juni auch Dein tolles Script anstatt den Adapter (in der damaligen Version) für meinen 800 Pro 2. Mir ist heute aufgefallen, dass das Gerät bei 70% Akkustand und ohne "Betrieb" steht. Laut Datenlogger ist das seit 03.08 ca. 11 Uhr so. Als ich in die App schaute sah ich gleiches Verhalten wie bei Dir: "Behördlich begrenzte Ausgansleistung" bei 0W, soll ist 800W (DP InverseMaxPower ist dann bei 200W). "Akkueinstellung" 10-70%, soll ist 10-100% (entspricht den DPs minSoc und socSet). "Überschüssige Energie exportieren" ist auf "verbieten", soll ist "Zulassen" (DP gridReverse - 0 bzw. 1). Setzt man in der App die "Behördlich begrenzte Ausgansleistung" wieder auf 800W geht der DP InverseMaxPower auch auf 800W (sollte es da nicht zwei unterschiedliche geben, was das Gerät max. kann (InverseMaxPower) und was das Gerät in D max. darf?).

FW ist V1.0.2 (habe noch kein Update auf 2.x gemacht).

Ich habe heute auch ein Blockly gemacht, das darauf reagiert. Keine Ahnung wo das herkommt, ich kann es zumindest noch nicht nachvollziehen. Seit der Trigger läuft trat es:
14:53
15:23
15:53
16:53
auf. Also eigentlich genau alle 30min (zwischen 16/17 hab ich nochmals Änderungen gemacht, wahrscheinlich fehlt mir das Logging von 16:23). Konntest Du das mittlerweile beheben? Brauchst noch Daten von mir? hyperTmp war ca. 34°C (aktuell bei 37°C) - das lasse ich jetzt mal im Log mit ausgeben.

[petman]

Hallo,
ich habe gestern das JS für meinen SF800Pro2 angepasst und heute das DPL-Blockly dazu.
Seit 12:30 läuft nun der SF800P2 mit erstmal 2 Panels und Akku parallel zu dem bisherigen BKW
SF1200 mit AB1000 und AB2000+Hoyml800+DTUonBat und 4x480Wp.
Die Reglung funktioniert zufreidenstellend.
Verbindungsproblem hatte ich heute 16:23 auch.
Ich hoffe auf eine vollständig lokale Lösung für den SF800P2 wie sie beim SF1200 mit dem Clouddiskonector.exe gemacht wurde.
Dann bekommt der SF800P2 den zweiten AB2000 und der SF1200 bekommt zwei ältere Module 400Wp, die derzeit ungnutzt rumstehen.

Danke für eure Arbeit und die Bereitschaft zu Teilen.

Peter aus BC

[petman]

Hier mal meine Übersicht, war kurz mal bewölkt.

Ich habe übrigens wie beim SF1200 auch im SF800P2 den Bypass auf auf dauerhaft aus gestellt.

Peter

[maxclaudi]

@MP_Trixi
sorry keine Zeit deshalb kurz:

• workaround mit blockly funktioniert.
• socSet auf 70% denn die Werte stimmen selbst nach Kalibrieren nicht mehr.
• Batterien sind mit angeblich 70% bei 3.33 bis 3.34V. Kann nicht stimmen das entspricht eher 85-90%. Mir momentan nicht wichtig weil was dazwischen funkt.
• Kühle deine Batterien mit einem starken Ventilator.
  siehe mein Post wegen Temperaturen-Schutz. Das betrifft auch die beisherige Firmware

1600AC+ läuft so.
Sollte socSet <70% eingestellt werden wird es automatisch wieder auf 70% gesetzt. Laut Voltage sind das fast volle Batterien.
Bild sagt mehr als Worte:

Die Batterien werden schon durch einen 200mm starken Ventilator gekühlt.

hoffentlich bin ich bald wieder vor Ort am Gerät. Immer nur per Wireguard.

PS: inverseMaxPower ist die maximale Einstellung für den Inverter. Also genau das was Du in der App einstellen kannst.
Mein Script überwacht inverseMaxPower, gridReverse, gridOffMode und chargeMaxLimit.
Bei Änderung wird automatisch zurück gestellt.
Dazu benötigt man nicht die App.
Irgendwas stimmt nicht. Cyberangriff? :-)))

[MP_Trixi]

@maxclaudi
Hey, danke für Deine schnelle Antwort trotz Zeitmangels. Gerne etwas ausführlicher wenn mehr Zeit ist. Das 30min Intervall bestätigt sich. Wenn ich es richtig verstehe vermutest Du einen Temp-Schutzmechansimus? Dafür ist die Temp doch eigentlich nicht hoch genug. Bei den Batterien ist diese unter 30°. Die Spannung ist bei mir auch bei 3,3xV

Zum Zeitpunkt des Screenshots zeigt er einen SoC von 85% an

[maxclaudi]

@petman sagte:
ich habe gestern das JS für meinen SF800Pro2 angepasst und heute das DPL-Blockly dazu.

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

Peter aus BC

scheene schütza :-)

@petman sagte:
Ich habe übrigens ...auch im SF800P2 den Bypass auf auf dauerhaft aus gestellt.

?
Soweit ich weiß, ist der Bypass beim SF800P2 gar nicht umschaltbar. Das regelt die Firmware komplett automatisch.

[maxclaudi]

@MP_Trixi

@MP_Trixi sagte:
...hyperTmp war ca. 34°C (aktuell bei 37°C) - das lasse ich jetzt mal im Log mit ausgeben.

maxclaudi sagte:

zendure-forum - Zendure Admin sagte:

Szenario B: Leistungsreduzierung (Derating) durch erhöhte Umgebungstemperatur

—— Bei hohen Umgebungstemperaturen (z. B. über 32 °C) reduziert das Gerät aktiv die Ausgangsleistung, um die internen Leistungshalbleiter zu schützen. Dies ist ein regulärer Thermoschutzmechanismus. Es wird empfohlen, das Gerät an einem kühlen, gut belüfteten Ort aufzustellen oder einen externen Lüfter zur Unterstützung der Wärmeabfuhr zu installieren.

maxclaudi sagte:
wenn es denn nur so wäre. War nicht nur eine Leistungsreduzierung. Gerät selbst hatte 35°C und wurde bereits mit Lüfter und Ventilator gekühlt.
Umgebungstemperatur war nicht so hoch.

HUB2000, ACE1500 und ein paar Hoymiles haben auch alle ohne Probleme funktioniert.

Vielleicht weil sie wirklich lokal sind.

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