Monatsrückblick Juli / August 2026 ist online!

[maxclaudi]

@T-147 sagte:
Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

[Daniel 8]

@maxclaudi sagte:

@T-147 sagte:
Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

Vielen Dank. Wenn ich mal Zeit finde, werde ich es mir mal ansehen. Meine Steuerung läuft aktuell ganz gut für mich.
Bin grad in mehreren anderen Projekten beschäftigt.

[T-147]

@maxclaudi sagte:

@T-147 sagte:
Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

Mögen Dir beim Händewaschen niemals die Ärmel runter rutschen!

[maxclaudi]

Habe soeben noch einmal das Blockly hochgeladen.
War ein Datenpunkt nicht richtig.
Entweder selbst korrigieren oder noch einmal die korrigierte Version downloaden.

Korrektur:

oder die ganzen Blöcke zur Fehlerkorrektur entfernen.

@T-147:
Mögen Dir beim Händewaschen niemals die Ärmel runter rutschen!

:-)))

[Jockel_Bln]

@maxclaudi sagte:

Blockly für Dich, @jockel_bln, evtl @daniel-8 und Alle Einsteiger als Basis oder Vorlage zum testen ;-)

Da hast du ja ordentlich was zusammen geschraubt
Meine Regierung hat gerade Urlaub, da darf ich momentan nicht so viel spielen.
Aber jetzt schon vorab vielen Dank für deine Arbeit.

[maxclaudi]

Blockly – Einfache DPL-Regelung (Nulleinspeisung & AC-Laden) für Einsteiger in Verbindung mit dem Steuerungs-Script dieses Threads
Post

update 17.07.2026; 18:30h
verbesserte Version für kritische Verbraucher

• criticalOutputLimit ist Begrenzung: wie viel Watt max. output im criticalMode sein darf
  (auch max_outputLimit ist erlaubt).

• criticalGridPower definiert ab wie viel Watt ein Verbraucher als kritischer Verbraucher zählt.

Kommentare im Blockly bitte beachten.

Download -> HIER

[maxclaudi]

@T-147 sagte:
...zwischen Laden und Entladen gewechselt werden soll, um die Relais zu schonen....

Wer zusätzliche Sicherheit möchte:

Blockly – Einfache DPL-Regelung (Nulleinspeisung & AC-Laden) für Einsteiger in Verbindung mit dem Steuerungs-Script dieses Threads
Post

update 18.07.2026; 15:30h
Version wie zuvor inkl. kritische Verbraucher + Neu: intervalSec_change_acModeAllowed

• intervalSec_change_acModeAllowed:
  acMode-Wechsel nur alle x Sekunden erlaubt. Schont Relais und verhindert häufiges Umschalten zwischen Laden und Entladen.
  0 oder 10-60 sec.
  Auch > 60 möglich.
  Darf jede(r) für sich entscheiden.
  Je höher der Wert, desto später erfolgt der Wechsel zwischen Laden und Entladen.

Da das Blockly im Inneren wieder sehr ausführlich kommentiert ist, verzichte ich hier auf eine lange Erklärung.

Bitte die Hinweise direkt im Skript lesen.

---

Import-Anleitung:
Wie man ein Blockly importiert, ist in diesem Post hier beschrieben.

---

Das Skript ist standardmäßig für einen Zendure 1600AC+ vorkonfiguriert.

Bitte prüft vor dem ersten Start unbedingt die folgenden Variablen und passt sie an euer eigenes System an:

• max_outputLimit: 1600
• max_inputLimit: 1600
• criticalGridPower: 600
• criticalOutputLimit: 1600

---

Urheberrechtshinweis
Bitte respektiert die Arbeit, die in diesem Projekt steckt, und beachtet den Urheberhinweis direkt im Skript.
Wenn ihr auf Basis dieses Skripts (oder Teilen davon) eigene Modifikationen veröffentlicht, fügt bitte eine kurze Verlinkung zu diesem Thread und / oder die Nennung meines Namens maxclaudi hinzu.
Vielen Dank!

Datei: maxclaudi_dpl_acMode_kV.zip enthält nur maxclaudi_dpl_acMode_kV.xml

1. Datei herunterladen und Virenscan.
2. maxclaudi_dpl_acMode_kV.zip entpacken
3. in iobroker neues, leeres Blockly erstellen
4. maxclaudi_dpl_acMode_kV.xml
   importieren.

Download:
maxclaudi_dpl_acMode_kV.zip

Viel Spaß damit!

[maxclaudi]

@T-147 sagte:
Ich würde halt gern wissen, wieviel Energie ich per PV gewinne, bzw. einspeise, aber da muss ich ja auch die Energie per AC-Ladung wieder abrechnen. Ich hab mittlerweile nen Shelly dazwischen, der auch beide Richtungen kann (oder können soll), aber bisher blick ich bei den Messwerten von dem nicht durch. Der hat einen Wert für "ReturnedEnergy", was für mich dann die Einspeisung wäre.

richtig.

Und einen Wert "Energy", der aber der Gesamtwert in & out zu sein scheint. Passt für mich aber rechnerisch auch noch nicht ganz zusammen...

Das sollte nur der Wert für Bezug sein.

@T-147 sagte:

• Mir fehlt irgendwie eine Angabe, wieviel kWh ich geladen/eingespeist habe,...

in etwa?

[maxclaudi]

Erweitertes Energie-Logging für Zendure-Geräte

Ich arbeite aktuell an einem Script, das zusätzliche Datenpunkte für Energieauswertungen (kWh) erzeugt:

Zusätzlich können zwei CSV-Dateien erzeugt werden.

1. Tagesenergie-Datei

Beispiel:
zendure_energy_2026.csv

Diese Datei enthält Tageswerte über ein Kalenderjahr:
Datum;pvInput_kWh;gridChargeInput_kWh;gridhomeOutput_kWh;gridOffSocketPower_kWh

Vor Scriptstart kann einmalig festgelegt werden, ob pvInput_kWh integriert werden soll.
Diese Option ist für Zendure-Geräte ohne DC-PV-Module-Eingänge gedacht, da dieser Wert dort immer 0 wäre.

Bedeutung der Werte:

• pvInput_kWh
  Vom Zendure-System gemeldete PV-Energie der angeschlossenen DC-PV-Modul-Eingänge.

• gridChargeInput_kWh
  Energie, die das Zendure-Gerät per 230V AC aus dem Hausnetz aufgenommen hat (AC-Laden).

• gridhomeOutput_kWh
  Energie, die das Zendure-Gerät in das 230V AC Hausnetz abgegeben hat.

• gridOffSocketPower_kWh
  Energiefluss über die gridOff-Steckdose:
  positive Werte: Energiefluss von der Steckdose in das Zendure-Gerät (z.B. Microinverter)
  negative Werte: Energiefluss vom Zendure-Gerät zur Steckdose (z.B. Verbraucher)

Die Datei enthält integrierte Tagesenergien in kWh und eignet sich für Statistiken, Diagramme und Langzeitauswertungen.

Die Jahresdatei wird automatisch anhand des aktuellen Kalenderjahres erzeugt.
Beim Jahreswechsel wird automatisch eine neue Jahresdatei begonnen.

---

2. Live-Leistungsdatei

Beispiel:
zendure_liveEnergy.csv

Die Aufzeichnung erfolgt in einem einstellbaren Intervall (z.B. jede Minute).

Enthalten sind aktuelle Leistungswerte:
Zeit;pvInput_W;gridChargeInput_W;gridhomeOutput_W;gridOffSocketPower_W

Die Werte werden nicht integriert oder aufsummiert.
Jede Zeile stellt eine Momentaufnahme der aktuellen Leistung in Watt dar.

Bedeutung:

• pvInput_W
  Aktuelle PV-Eingangsleistung der PV-Module an den DC-PV-Eingängen.

• gridChargeInput_W
  Aktuelle 230V AC-Lade-Leistung aus dem Hausnetz zum Zendure-Gerät.

• gridhomeOutput_W
  Aktuelle AC-Leistung vom Zendure-Gerät ins 230V AC Hausnetz.

• gridOffSocketPower_W
  Aktuelle Leistungsrichtung der gridOff-Steckdose:
  positive Werte: Leistung von der Steckdose in das Zendure-Gerät
  negative Werte: Leistung vom Zendure-Gerät zur Steckdose

Die Datei eignet sich für Leistungsdiagramme (W) und Dashboards.

Archivierung Live-Datei:
Beim Tageswechsel bzw. beim nächsten Schreibvorgang nach einem Tageswechsel wird:
zendure_liveEnergy.csv

automatisch archiviert als z.B.:
zendure_liveEnergy_2026-07-20.csv

Danach wird wieder die aktuelle Datei:
zendure_liveEnergy.csv
weitergeführt.

Es werden maximal 30 Tagesarchive behalten. Ältere Dateien werden automatisch gelöscht.

Zusätzlich kann im Script eingestellt werden, ob CSV-Dateien erzeugt werden sollen oder nur die ioBroker-Datenpunkte.

Die Berechnung basiert ausschließlich auf den von Zendure gelieferten Leistungswerten.
Es werden keine geschätzten Wirkungsgrade oder pauschalen Umrechnungen (z.B. Faktor 0,96 wie teilweise bei anderen Scripts verwendet) eingesetzt.

Die gridOffSocketPower-Werte beschreiben ausschließlich den Energiefluss über die gridOff-Steckdose und stellen keine separate Netzeinspeisungsmessung dar.

Die Energiezähler werden über die von Zendure gelieferten Zeitstempel und Leistungswerte fortgeführt.
Bei Neustarts oder Unterbrechungen werden keine fehlenden Werte geschätzt oder nachberechnet.

Das Script arbeitet unabhängig von der Gerätesteuerung und greift ausschließlich lesend auf vorhandene Zendure-Datenpunkte zu.
Es verändert keine Geräteeinstellungen und kann daher parallel zu bestehenden Steuerungsscripten betrieben werden.

Mehr fällt mir dazu im Moment nicht ein; genug getippt :-)

Besteht Interesse an dieser Erweiterung bzw. an dem Script?

Über eine Rückmeldung, wer welches meiner Blockly-Scripte verwendet und ob diese problemlos laufen, würde ich mich ebenfalls freuen ;-)

[Daniel 8]

@maxclaudi sagte:

Allen einen wunderschönen, sonnigen guten Morgen,

@Rico-Sander sagte:
Vieles was hier diskutiert wird im Zusammenhang mit der Firmware- und HEMS-Aktualisierung trifft für mich nicht zu.

habe auch kein Update durchgeführt. Weil ich kein HEMS nutze, ist es für mich nicht wichtig.
Von den letzten Updates war ich mehr enttäuscht.
Echte Verbesserungen gab es - für mich - nicht.
Für mich waren es mehr Reglementierungen.

@Rico-Sander sagte:
Laden über AC-Anschluss, Entladen über AC-Anschluss - sonst nix.
Bypass-Funktion und Grid-Dose benötige ich nicht.

Selbst wenn Du mehr benötigen würdest, wüsste ich nicht was aktuell unter API 2 dagegen spricht.
Die größten Veränderungen/Neuerungen durch das aktuelle Update sind bisher die Einführung von HEMS2 und Umstellung auf TLS.
Zendure schreibt zwar: X bekannte Probleme behoben, jedoch welche das sein sollen, wird nicht erwähnt.

Bei meinem Gerät sollen es 2 Probleme sein.
Kann aber kein Problem feststellen und HEMS nutze ich nicht.

@Rico-Sander sagte:
Daher: Kann ich gefahrlos bei Verwendung des HTTP-Scriptes die Updates fahren oder gibt es Probleme mit dem SSL- und Port-Problem?
Vermutlich nicht, da ich ja kein MQTT nutze - richtig?

SSL mit Port:8883 ist nur für (nicht offizilles , Cloud-) MQTT
Das Script nutzt reines HTTP mit dem Webserver des Zendure-Geräts.
Zendure-Gerät und App nutzen zusätzlich "nicht offizielle" MQTT-Verbindung zur Cloud.

Für das Script bedeutet das: Wenn Zendure durch die Firmware zenSDK nicht auch reglementiert oder grundlegend was verändert hat, dann funktioniert es wie zuvor.
Es gab mit dem Update ein paar Änderungen und ein zusätzlicher Key.
Bisher wurden mir keine Einschränkungen gemeldet.

@Daniel-8 sagte:
Bei mir ist alles gut.

Hey, freut mich.

@Daniel-8 sagte:
...hat Zendure bei Hems 2 und den neuen Firmwares was geändert.
Ich habe noch kein Update gemacht. Bin etwas vorsichtig, da im Zendure Forum sehr viele Probleme haben.

warte auch ab. Evtl. benötige ich keins.

@Daniel-8 sagte:
Was ist eigentlich der socCompSwitch?

Das ist nicht bekannt und noch nicht dokumentiert.
Habe eine Vermutung und kann es - ohne Update -nicht testen.

socCompSwitch, bedeutet wahrscheinlich: State of Charge Compilation Switch.

Denke es wird sich um einen neuen Schalter handeln, der eine Kalibrierung manuell auslösen wird.

Damit man die automatische (wöchentliche oder monatliche) SoC-Kalibrierung zu nicht gewollten Zeiten

• beeinflussen,
• verhindern
• oder vorziehen kann?

Das ist nur meine Vermutung -reine Spekulation - !

---

Habe den Schalter mal hinzugefügt, falls jemand auf eigene Gefahr und eigenes Risiko selbst testen möchte, was der Schalter bewirkt.

Unter API 2 habe ich den Schalter schon gesetzt und getestet.
Befehl wird abgeschickt und Empfang bestätigt.
Auswirkungen hatte es bei mir überhaupt keine.
War zu erwarten, weil socCompSwitch in der API2-Firmware nicht implementiert ist.
Konnte den Schalter mehrmals - unter API 2 - gefahrlos bei meinem 1600AC+ setzen - ohne jede Veränderung.
Funktionieren oder was bewirken wird der Schalter (sehr wahrscheinlich nur) erst nach Firmware-Update auf zenSDK API Version: 3.

Noch einmal: Alles zu socCompSwitch sind nur Vermutungen aufgrund von Tests und Beobachtungen.

edit:
Falls jemand set socComp nach Update mit zenSDK API Version: 3 testen sollte, wäre ich über Rückmeldungen sehr dankbar.

Habe mich heute doch mal getraut mein Solarflow 800 Pro auf die Firmware 2.0.1 upzudaten.

Habe dann mal den setsocComp auf 1 und 2 geschrieben. Konnte aber keinerlei Veränderung feststellen

[maxclaudi]

Hallo zusammen,

@Daniel-8
Sorry, dass ich mich erst jetzt wieder melde.
Ich bin gerade intensiv mit dem Reverse Engineering beschäftigt und habe auch viel Zeit im source-code der Zendure-App verbracht – alles sehr zeitaufwendig.

Wenn du aktuell auf der Firmware 2.0.1 bist, könntest du in der App mal verschiedene Einstellungen bei der Kalibrierung vornehmen und die Daten mitloggen oder beobachten?
Mich würde interessieren, wann genau sich socCompSwitch und batCalTime ändern und welche Werte in diesem Moment gesetzt werden.

Anscheinend:
version:3 vs version:2
LCNstate wurde entfernt
socCompSwitch wurde hinzugefügt.

Kann nicht selbst testen, weil ich bewusst noch kein Update durchführe(n kann).

---

Zu meinem Beitrag bezüglich des unknown ca-Fehlers beim SolarFlow 1600 AC+:

maxclaudi sagte:

@nograx
Dankeschön

edit 12.07.2026 11.00h:
Ich habe das ebenfalls getestet. Leider wurde dieses – noch einfachere – Zertifikat von meinem 1600AC+ ebenfalls nicht akzeptiert.

Info:
Mit openssl s_client gegen mq.zen-iot.com:8883 erhält man folgende Informationen:

CONNECTED(00000004)
depth=1 C=CN, ST=hangzhou, O=EMQ, CN=RootCA
verify error:num=19:self-signed certificate in certificate chain
verify return:1
depth=1 C=CN, ST=hangzhou, O=EMQ, CN=RootCA
verify return:1
depth=0 C=CN, ST=hangzhou, O=EMQ, CN=Server
verify return:1
.....
---
Certificate chain
 0 s:C=CN, ST=hangzhou, O=EMQ, CN=Server
   i:C=CN, ST=hangzhou, O=EMQ, CN=RootCA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May  8 08:07:05 2020 GMT; NotAfter: May  6 08:07:05 2030 GMT
 ......  

 1 s:C=CN, ST=hangzhou, O=EMQ, CN=RootCA
   i:C=CN, ST=hangzhou, O=EMQ, CN=RootCA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: May  8 08:06:52 2020 GMT; NotAfter: May  6 08:06:52 2030 GMT
   
Server certificate
subject=C=CN, ST=hangzhou, O=EMQ, CN=Server
issuer=C=CN, ST=hangzhou, O=EMQ, CN=RootCA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2205 bytes and written 402 bytes
Verification error: self-signed certificate in certificate chain
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
This TLS version forbids renegotiation.
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self-signed certificate in certificate chain)

Nach meiner Interpretation bedeutet das:

• Zendure verwendet kein einzelnes selbstsigniertes Serverzertifikat, sondern eine Zertifikatskette aus einer selbstsignierten Root-CA (RootCA) und einem von dieser Root-CA signierten Serverzertifikat (Server).
• Die Root-CA ist selbstsigniert und wird vom OpenSSL-Client deshalb erwartungsgemäß nicht als vertrauenswürdig eingestuft (Verify return code: 19).
• Das Serverzertifikat verwendet RSA-2048 und ist bis 2030 gültig. Interessant ist das Ausstellungsdatum von bereits 2020.

Bei meinem SolarFlow 1600 AC+ wird ein einfaches selbstsigniertes Serverzertifikat bisher mit unknown ca abgelehnt, obwohl RSA-2048, TLS 1.2, passende Cipher und SAN verwendet werden.

Nach den bisherigen Erkenntnissen scheint sich die TLS-Implementierung der Hyper-Geräte von der der neueren AC-Serie zu unterscheiden. Ob dies tatsächlich an einer strengeren Zertifikatsprüfung liegt oder eine andere Ursache hat, ist mir derzeit noch unklar.

Als nächsten Schritt werde ich versuchen, statt eines einzelnen selbstsignierten Serverzertifikats ebenfalls eine Zertifikatskette (Root-CA - > Serverzertifikat) nachzubilden.
Ob das vom 1600 AC+ akzeptiert wird, halte ich allerdings für eher fraglich.

Meine Vermutung hat sich inzwischen bestätigt und ich habe eine erfolgversprechende Lösung für die Zertifikatskette gefunden.

Da ich momentan nicht vor Ort bin, steht der finale Praxistest direkt mit dem 1600 AC+ noch aus.
Sobald ich wieder Zugriff habe, wird sich zeigen, ob der Cloud-Server damit komplett durch einen lokalen Broker ersetzt werden kann.
Ziel ist ein vollständig lokales Setup mit eigenem MQTT-Broker, zusätzlichen Keys und schnellem, direktem MQTT.

Läuft der Test erfolgreich, hätte man bis zum Ablauf des Original-Zertifikats am 6. Mai 2030 um 10:07:05 Uhr (MESZ) erst einmal Ruhe – also für gut 3,5 Jahre ein schnelles, stabiles, lokales MQTT-System.

Ich bin parallel auch gerade dabei, eine Windows-Konsolen-Anwendung zu schreiben.

Bitte habt etwas Verständnis und Geduld, wenn ich nicht immer sofort antworte.

Danke und viele Grüße!

---

edit 27.07.2026
Heureka :-)

[Daniel 8]

@maxclaudi ich führe ja keine Kalibrierung über die app durch. Ich mache automatisch alle 25 Tage eine über iobroker.

Habe grad durch das Update Probleme das er mir über Nacht den Akku leer zieht.

Bin aber grad noch am austesten. Der ging nicht mehr in standby wenn es dunkel war und socmin erreicht. Er hat durchgehend mit ca. 9 bis 14 Watt entladen.

Habe ihn jetzt per mqtt ein und ausschalten quasi aus der Ferne zu einem Neustart gezwungen. Danach war er sofort im Standby. Mal sehen was morgen verbraucht wurde und ob er morgen abend abschaltet.

[maxclaudi]

Guten Morgen @Daniel-8

@Daniel-8 sagte:
@maxclaudi ich führe ja keine Kalibrierung über die app durch....

Ja, ich bat Dich nur darum :-)
Sonst wissen wir nicht wann sich was mit welchen Werten ändert.
Darf gerne auch jemand anders testen und helfen.

Habe grad durch das Update Probleme das er mir über Nacht den Akku leer zieht.

Bin aber grad noch am austesten. Der ging nicht mehr in standby wenn es dunkel war und socmin erreicht. Er hat durchgehend mit ca. 9 bis 14 Watt entladen.

Ein Grund mehr sich nicht allein auf SoC oder minSoc zu verlassen.
Würde ein Batterieschutz aufgrund von minVol verwenden.
Blockly-Beispiel dazu habe ich schon gepostet.

Habe ihn jetzt per mqtt ein und ausschalten quasi aus der Ferne zu einem Neustart gezwungen. Danach war er sofort im Standby. Mal sehen was morgen verbraucht wurde und ob er morgen abend abschaltet.

per ein- und ausschalten zu einem Neustart gezwungen?

[Daniel 8]

@maxclaudi sagte:

Guten Morgen @Daniel-8

@Daniel-8 sagte:
@maxclaudi ich führe ja keine Kalibrierung über die app durch....

Ja, ich bat Dich nur darum :-)
Sonst wissen wir nicht wann sich was mit welchen Werten ändert.
Darf gerne auch jemand anders testen und helfen.

Ich lass ihn ja nicht kalibrieren, da er ja dann strom aus dem Netz zieht. Komme im moment grad auch nicht dazu, da ich gerade andere sachen habe. Wenn ich zeit finde denke ich darüber nach.

Habe grad durch das Update Probleme das er mir über Nacht den Akku leer zieht.

Bin aber grad noch am austesten. Der ging nicht mehr in standby wenn es dunkel war und socmin erreicht. Er hat durchgehend mit ca. 9 bis 14 Watt entladen.

Ein Grund mehr sich nicht allein auf SoC oder minSoc zu verlassen.
Würde ein Batterieschutz aufgrund von minVol verwenden.
Blockly-Beispiel dazu habe ich schon gepostet.

Das hätte wahrscheinlich auch nichts gebracht, da er nicht abgeschaltet hat.

Habe ihn jetzt per mqtt ein und ausschalten quasi aus der Ferne zu einem Neustart gezwungen. Danach war er sofort im Standby. Mal sehen was morgen verbraucht wurde und ob er morgen abend abschaltet.

per ein- und ausschalten zu einem Neustart gezwungen?

Ja wenn man mqtt in der App einschaltet startet er angeblich neu. Und da ich es nicht brauche, habe ich es wieder ausgeschaltet.

Heute wird er wahrscheinlich nicht leer.

[maxclaudi]

@Daniel-8 sagte:

@maxclaudi sagte:
Ein Grund mehr sich nicht allein auf SoC oder minSoc zu verlassen.
Würde ein Batterieschutz aufgrund von minVol verwenden.
Blockly-Beispiel dazu habe ich schon gepostet.

Das hätte wahrscheinlich auch nichts gebracht, da er nicht abgeschaltet hat.

bei mir funktioniert das Abschalten über minVol immer zuverlässig – allerdings nur, wenn der Batterie-Entladeschutz (minVol) auch deutlich über der minSoc-Grenze liegt.

[Daniel 8]

@maxclaudi sagte:

@Daniel-8 sagte:

@maxclaudi sagte:
Ein Grund mehr sich nicht allein auf SoC oder minSoc zu verlassen.
Würde ein Batterieschutz aufgrund von minVol verwenden.
Blockly-Beispiel dazu habe ich schon gepostet.

Das hätte wahrscheinlich auch nichts gebracht, da er nicht abgeschaltet hat.

bei mir funktioniert das Abschalten über minVol immer zuverlässig – allerdings nur, wenn der Batterie-Entladeschutz (minVol) auch deutlich über der minSoc-Grenze liegt.

Du meinst das er nicht mehr einspeist oder das er in standby geht? Einspeisen hat er bei mir auch aufgehört. Nur ging er nicht in standby sondern hat sich quasi mit seinen eigenverbrauch selbst leergesaugt

[maxclaudi]

Hallo zusammen,

ich habe ein kleines Windows-Konsolenprogramm geschrieben, das einen sicheren Request an die offizielle Zendure-API sendet.
Es liefert umfangreiche und detaillierte Informationen zu allen registrierten Geräten sowie DeviceId, Passwörter und MQTT-Zugangsdaten.

Das Programm läuft komplett eigenständig. Es muss nichts weiter installiert werden (keine Bibliotheken etc.).

So funktioniert es:

1. Öffnet die Datei config.ini in einem Texteditor.
2. Kopiert euren langen AppKey aus der Zendure-App und fügt ihn dort ein.

3. Speichert die Datei ab.
4. Startet die zendureInfo.exe einfach per Doppelklick.
5. Das Tool fragt die Daten ab, zeigt sie sofort auf dem Bildschirm an und speichert sie gleichzeitig in der Datei info_maxclaudi.txt im selben Ordner ab.

Download & Wichtiger Hinweis zum Entpacken:
Die fertige .exe ist knapp 8 MB groß und überschreitet das Foren-Limit von 5 MB.
Deshalb musste ich das Archiv in zwei Teile aufteilen.
Den ersten Teil findet ihr unten im Anhang, den zweiten Teil direkt im folgenden Beitrag.

1. Ladet beide Dateien (zendure_Info.zip und zendure_Info.z01) in den exakt selben Ordner auf eurem PC herunter.
2. Macht zur eigenen Sicherheit vor dem Start gerne einen Virenscan!
3. Entpackt ausschließlich die Hauptdatei zendure_Info.zip.

Hinweis:
Verwendet dazu bitte ein kostenloses Programm wie 7-Zip oder WinRAR (der Windows-eigene Entpacker scheitert leider an mehrteiligen Archiven).
Das Programm zieht sich den anderen Teil beim Entpacken automatisch dazu.

Viel Spaß beim Auslesen der Daten!

download part 1v2:
zendure_Info.zip

[maxclaudi]

Hier ist der zweite Teil des Archivs zum Download.

Bitte denkt daran, diese Datei (zendure_Info.z01) zusammen mit der Hauptdatei aus dem ersten Beitrag in denselben Ordner zu legen, bevor ihr den Entpackvorgang startet.

download part 2v2:
zendure_Info.z01

[maxclaudi]

@Daniel-8
Bei mir war es nun umgekehrt.
Mein Batterieschutz schaltete zuverlässig über minVol-Grenze ab und der AC1600+ ging nach kurzer Zeit in Standby.

Aber bis 14:00Uhr - bei viel Sonne - blieb er einfach weiter im Standby.
Auch per PV (über gridOff-Steckdose angeschlossen) hat er nicht geladen. Meldete 0W.

Außerdem hat sich mein socSet automatisch (über Cloud?) auf 70% und minSoc auf 15% verändert.

Die Änderungen habe ich nicht gemacht.
Nutze keine App und mein Script ändert keine SoC-Werte.
Musste die Werte wieder setzen und auch - wie Du - mqtt ein und ausschalten, damit der 1600AC+ neu startete.
Bin ja auch nicht vor Ort.

Nur zur Info: mit der bisherigen Firmware. Ein update wurde noch nicht gemacht.

Ich habe ein Windows-Konsolen-Programm im beta-status fertig .
Damit kann man IP/DNS - Ziel der neuen Geräte direkt umschreiben.
Test-Zert/key hat ein Hyper-Testgerät mit aktueller Firmware und TLS schon bestanden.
Wenn ich wieder vor Ort bin werde ich es mit dem 1600AC+ testen.

Nachtrag: Vor 3 min hat sich socSet wieder von unbekannter Quelle auf 70% gesetzt. Gerät hat eine Temperatur von 32°C und Batterien auch.
Hat wieder nicht geladen und inverseMaxPower wurde auf 200 gesetzt.
Kann ja nur von der Cloud kommen obwohl nur zenSDK ohne HEMS genutzt wird.

[Daniel 8]

@maxclaudi

Das ist ja ganz schön merkwürdig. Wir sind halt leider immer noch ein wenig von der Cloud abhängig.

Was meinst du mit IP umschreiben? Das er nicht mehr auf die Cloud zugreift?

Bei mir gab es keine socSet veränderungen.