Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2
-
@Daniel-8 sagte:
Das ist ja ganz schön merkwürdig. Wir sind halt leider immer noch ein wenig von der Cloud abhängig....
Bei mir gab es keine socSet veränderungen.Bei mir gerade wieder und hat sich dann durch Blockly gleich wieder geändert.
Temperaturen:
1600AC+ 35°C
Bat 1: 33°C
Bat 2: 32°CSoC: 72%
socSet: 85%Nachdem ich ihn per Script zwinge, schaltet er jetzt einfach auf pass:2
und gibt die Leistung ins Hausnetz durch, statt zu laden.und jetzt, beim schreiben des Textes schaltet er nun doch auf pass:0 und ladet.
Unglaublich.
33°C mag jetzt nicht ideal sein aber dennoch... Gerät wird gekühlt.
Außerdem verstehe ich nicht warum inverseMaxPower 2x auf 200 gesetzt wurde - ohne Script etc.edit/PS 19.00h:
Wechselt immer wieder zwischen pass:0 und pass:2
Zwar nicht schnell aber mit SoCset 85% ist er mit SoC 72% und mit aktuell ca. 70W PV-Leistung (19Uhr) noch weit weg von 85% und garantiert nicht überfordert.edit/PPS: 19.04h:
schon wieder wurde inverseMaxPower auf 200 geändert und durch mein script zurück auf 1600 gesetzt.edit/PPPS: 19.07h:
Wenn es nicht von der Cloud kommt dann muss es die Firmware sein. Es gibt nur die 2 Kandidaten.
Vermute dass bei ca. +33°C irgend ein Batterieschutz greift.
Was aber nicht die inverseMaxPower erklärt. Denn das Gerät sollte mit 35°C entspannt sein.update 19.40h:
Bat 1 minVol: 3.34V
Bat 1 maxVol: 3.34V
Bat 2 minVol: 3.34V
Bat 2 maxVol: 3.34VSoC: 72%
das kann nicht sein. Also stimmt der SoC-Wert nicht und das erklärt auch warum die Batterien nicht oder nur sehr schwach geladen wurden (BMS).
mit 3.34V sind sie bereits >= 85%
Eine Kalibrierung wird oder wurde nicht eingeleitet durch Firmware/Cloud.update 19.48h
socLimit steht unbeeindruckt auf 0.
Also keine Ladegrenze erreicht.
Das ist ein Worst Case.
Werde den Batterie-Entladeschutz wohl um einen Batterie-Ladeschutz erweitern müssen.update 19.55h
Setzte nun socSet auf 70%.
Damit wurde auch gleich socLimit:1 gemeldet und pass:2Man sieht hier wieder ganz deutlich, dass man sich nicht auf minSoc und socSet verlassen sollte!
Die Firmware oder Cloud hat zwar irgendwie darauf reagiert aber nicht gut.
Statt eine Kalibrierung anzuwerfen oder etwas Nachvollziehbares wurden (für mich) wichtige Werte geändert.
Ok, eine Erfahrung mehr.
Muss dann auch in meinem Script abgefangen werden.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.
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
lokalsind. -
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.
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
lokalsind. -
Datenverkehr geloggt:
App <> Gerät
Cloud <> GerätWichtige Zeitpunkte gefiltert, entschlüsselt und analysiert.
Windows-Konsolen-Programm ist fertig:
zendureURLtool.exeDas Tool ist stabiler und schneller als die App :-)
Credits für die genutzte Bluetooth-Bibliothek gehen an Henrik Blidh:
https://github.com/hbldh/bleakMan füllt in der config.ini nur 3 Felder aus, speichert ab und los geht's mit Doppelklick auf "zendureURLtool.exe"...
entweder zu lokalem Broker wechseln:
oder zurück zur Cloud:
geht alles sehr schnell.
Selbst bei einem Hyper "ohne" stromlos machen.
Nicht mal Trennung von BT am Rechner war nötig.
Nur APP muss vollständig beendet sein.
Am besten in der Zeit zusätzlich BT am Smartphone ausgeschaltet lassen.
Bei einem Hyper habe ich für 3x IP wechseln nur ca. 2 min benötigt. Er war jedesmal sofort verbunden.
Am längsten dauerte das Aufstehen, den Button zu drücken und zu warten, dass er im Kopplungsmodus ist.
Es haben sich beim Analysieren noch mehr Wege geöffnet.
Allerdings sind die für mich aktuell unnötig und stehen – wenn überhaupt – ganz hinten an. -
@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. 😁 -
Datenverkehr geloggt:
App <> Gerät
Cloud <> GerätWichtige Zeitpunkte gefiltert, entschlüsselt und analysiert.
Windows-Konsolen-Programm ist fertig:
zendureURLtool.exeDas Tool ist stabiler und schneller als die App :-)
Credits für die genutzte Bluetooth-Bibliothek gehen an Henrik Blidh:
https://github.com/hbldh/bleakMan füllt in der config.ini nur 3 Felder aus, speichert ab und los geht's mit Doppelklick auf "zendureURLtool.exe"...
entweder zu lokalem Broker wechseln:
oder zurück zur Cloud:
geht alles sehr schnell.
Selbst bei einem Hyper "ohne" stromlos machen.
Nicht mal Trennung von BT am Rechner war nötig.
Nur APP muss vollständig beendet sein.
Am besten in der Zeit zusätzlich BT am Smartphone ausgeschaltet lassen.Bei einem Hyper habe ich für 3x IP wechseln nur ca. 2 min benötigt. Er war jedesmal sofort verbunden.
Am längsten dauerte das Aufstehen, den Button zu drücken und zu warten, dass er im Kopplungsmodus ist.
Es haben sich beim Analysieren noch mehr Wege geöffnet.
Allerdings sind die für mich aktuell unnötig und stehen – wenn überhaupt – ganz hinten an.da hast du ja wieder was mega tolles auf die Beine gestellt.
Man ist dann komplett lokal und es gibt auch keine Firmwareupdates mehr. Sehe ich das richtig?
Braucht man zum einrichten Bt oder reicht das Wlan?
-
@Daniel-8 sagte:
Das ist ja ganz schön merkwürdig. Wir sind halt leider immer noch ein wenig von der Cloud abhängig....
Bei mir gab es keine socSet veränderungen.Bei mir gerade wieder und hat sich dann durch Blockly gleich wieder geändert.
Temperaturen:
1600AC+ 35°C
Bat 1: 33°C
Bat 2: 32°CSoC: 72%
socSet: 85%Nachdem ich ihn per Script zwinge, schaltet er jetzt einfach auf pass:2
und gibt die Leistung ins Hausnetz durch, statt zu laden.und jetzt, beim schreiben des Textes schaltet er nun doch auf pass:0 und ladet.
Unglaublich.
33°C mag jetzt nicht ideal sein aber dennoch... Gerät wird gekühlt.
Außerdem verstehe ich nicht warum inverseMaxPower 2x auf 200 gesetzt wurde - ohne Script etc.edit/PS 19.00h:
Wechselt immer wieder zwischen pass:0 und pass:2
Zwar nicht schnell aber mit SoCset 85% ist er mit SoC 72% und mit aktuell ca. 70W PV-Leistung (19Uhr) noch weit weg von 85% und garantiert nicht überfordert.edit/PPS: 19.04h:
schon wieder wurde inverseMaxPower auf 200 geändert und durch mein script zurück auf 1600 gesetzt.edit/PPPS: 19.07h:
Wenn es nicht von der Cloud kommt dann muss es die Firmware sein. Es gibt nur die 2 Kandidaten.
Vermute dass bei ca. +33°C irgend ein Batterieschutz greift.
Was aber nicht die inverseMaxPower erklärt. Denn das Gerät sollte mit 35°C entspannt sein.update 19.40h:
Bat 1 minVol: 3.34V
Bat 1 maxVol: 3.34V
Bat 2 minVol: 3.34V
Bat 2 maxVol: 3.34VSoC: 72%
das kann nicht sein. Also stimmt der SoC-Wert nicht und das erklärt auch warum die Batterien nicht oder nur sehr schwach geladen wurden (BMS).
mit 3.34V sind sie bereits >= 85%
Eine Kalibrierung wird oder wurde nicht eingeleitet durch Firmware/Cloud.update 19.48h
socLimit steht unbeeindruckt auf 0.
Also keine Ladegrenze erreicht.
Das ist ein Worst Case.
Werde den Batterie-Entladeschutz wohl um einen Batterie-Ladeschutz erweitern müssen.update 19.55h
Setzte nun socSet auf 70%.
Damit wurde auch gleich socLimit:1 gemeldet und pass:2Man sieht hier wieder ganz deutlich, dass man sich nicht auf minSoc und socSet verlassen sollte!
Die Firmware oder Cloud hat zwar irgendwie darauf reagiert aber nicht gut.
Statt eine Kalibrierung anzuwerfen oder etwas Nachvollziehbares wurden (für mich) wichtige Werte geändert.
Ok, eine Erfahrung mehr.
Muss dann auch in meinem Script abgefangen werden.@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. -
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
-
@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.@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
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? :-)))@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
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
450
Online33.0k
Benutzer83.5k
Themen1.3m
Beiträge