wichtiges UPDATE für controller 7.2.2 im stable

[maxclaudi]

@paul53 sagte:

@maxclaudi [sagte]: Welchen Wert meldet socLimit, sobald die Notstromdose wegen Erreichen des Entladelimits (minSoC) abgeschaltet hat?

Wert 18.

update ist schon raus :-)

Edit/PS: Herzlichen Dank für deine aktive Mitarbeit hier im Forum. Ohne deine schnellen Rückmeldungen würde das Ganze immer viel länger dauern.

@daniel-8 vermisse ich auch – hoffentlich ist bei ihm alles gut.

[Rico Sander]

@maxclaudi
Sorry, falls ich nerve.
Vieles was hier diskutiert wird im Zusammenhang mit der Firmware- und HEMS-Aktualisierung trifft für mich nicht zu.
Laden über AC-Anschluss, Entladen über AC-Anschluss - sonst nix.
Bypass-Funktion und Grid-Dose benötige ich nicht.

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?

Danke für Aufklärung ...

[Daniel 8]

@maxclaudi
Bei mir ist alles gut. Hab nur grad ein bisschen den Faden hier verloren. Wenn ich das aber richtig gesehen habe, 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.

Was ist eigentlich der socCompSwitch?

[maxclaudi]

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.

[Daniel 8]

@maxclaudi

Vielen Dank für die Erklärung.

Es gibt ja in der App eine Funktion wo man zumindest die Kalibrierungszeit einstellen kann. Habe es noch nie getestet. Somit ist mir auch nicht klar, ob dann mit dc (Pv Leistung) oder mit netzstrom kalibriert wird.

[maxclaudi]

@Daniel-8 sagte:
Es gibt ja in der App eine Funktion wo man zumindest die Kalibrierungszeit einstellen kann.

Diese Einstellung gibt es in meiner App-Version nicht.

Habe es noch nie getestet. Somit ist mir auch nicht klar, ob dann mit dc (Pv Leistung) oder mit netzstrom kalibriert wird.

Ich vermute, dass die PV-Leistung berücksichtigt wird, weiß es aber nicht sicher.
Zusätzlich stellt sich die Frage wie die Kalibrierung implementiert ist.
Ob die Batterien zuerst komplett entladen und danach voll aufgeladen werden, oder es umgekehrt abläuft?
Einmaliger oder mehrmaliger Prozess?

Welche API Version wird bei Dir im Datenpunkt "version" angezeigt?

[Daniel 8]

[Rico Sander]

@Daniel-8 sagte:

@maxclaudi

Vielen Dank für die Erklärung.

Es gibt ja in der App eine Funktion wo man zumindest die Kalibrierungszeit einstellen kann. Habe es noch nie getestet. Somit ist mir auch nicht klar, ob dann mit dc (Pv Leistung) oder mit netzstrom kalibriert wird.

Moin,

das wird die Funktion sein, die Anfang Juni vom Support in einer Mail angekündigt wurde.
Zitat Support:

Gute Neuigkeiten: Unsere automatische Kalibrierungsfunktion steht kurz vor der Veröffentlichung. Sie können dann für Ihre Batterie Start- und Endzeit sowie die Lade-/Entladeleistung festlegen, und das System führt die Kalibrierung innerhalb des gewählten Zeitraums automatisch durch. Das wird den bisherigen Aufwand erheblich reduzieren.

@maxclaudi

Danke für Rückmeldung, dann werde auch ich vorerst auf das Update verzichten.
Einen schönen Tag Euch da draußen...

[maxclaudi]

@Daniel-8 sagte:
Es gibt ja in der App eine Funktion wo man zumindest die Kalibrierungszeit einstellen kann.

Bei Dir ist Api Version:2; dann verwendest Du vermutlich eine neuere App-Version ohne Firmware-Update.

@Rico-Sander sagte:
das wird die Funktion sein, die Anfang Juni vom Support in einer Mail angekündigt wurde.

An alle:
Wenn Firmware aktualisiert wurde auf API 3 und man die App für die Kalibrierung nutzt, dann wäre es interessant was für Werte in der App eingestellt wurden und was die Datenpunkte für Werte liefern:

• properties.batCalTime
• properties.socCompSwitch
• properties.socStatus

evtl. noch
properties.pass beobachten.

[Daniel 8]

@maxclaudi sagte:

@Daniel-8 sagte:
Es gibt ja in der App eine Funktion wo man zumindest die Kalibrierungszeit einstellen kann.

Bei Dir ist Api Version:2; dann verwendest Du vermutlich eine neuere App-Version ohne Firmware-Update.

Ja die App ist aktuell ohne Firmwareupdate. Aber ich meine das es in der vorherigen Version der App auch schon drin war. Kann mich aber auch täuschen

@Rico-Sander sagte:
das wird die Funktion sein, die Anfang Juni vom Support in einer Mail angekündigt wurde.

An alle:
Wenn Firmware aktualisiert wurde auf API 3 und man die App für die Kalibrierung nutzt, dann wäre es interessant was für Werte in der App eingestellt wurden und was die Datenpunkte für Werte liefern:

• properties.batCalTime
• properties.socCompSwitch
• properties.socStatus

evtl. noch
properties.pass beobachten.

Ich bin ja noch auf Api 2 und nutze eine Manuelle Kalibrierung über Iobroker. Da wird spätestens nach 27 Tage über PV Strom auf 100% geladen.

[maxclaudi]

@Jockel_Bln sagte:
@All Eventuell kann da mal jemand drüber gucken, ob ich da sehr grobe Schnitzer drin habe...
EDIT: Beim Nachladen ab 95% muss es natürlch < 95 heißen.

Hi @Jockel_Bln,

das mit „< 96“ hast Du ja selbst schon korrigiert.
Deine einfache Steuerung sollte so als Grundgerüst für den Anfang funktionieren.

Ein paar Vorschläge:

Abfrage vor dem Senden:
Prüfe vor jedem erneuten Setzen des output oder input Limits, ob der neue Wert überhaupt vom aktuellen Datenpunktwert abweicht.

Variablen statt Festwerte:
feste Zahlen (10, 20, 100, 95) können durch dynamische Datenpunkte wie setSoc (z. B. 90% oder 100%), minSoc oder Vergleiche wie minSoc + 5 ersetzt werden.

Messwerte nutzen: Du kannst statt der vom BMS geschätzten SoC-Werte auch echte, verlässliche Messwerte wie MinVol und MaxVol für Vergleiche heranziehen.

Mehrere Batterien einplanen:
Bei Freigabe_Laden: falsch, wenn socLevel... kannst Du direkt alle Batterien berücksichtigen oder das Skript zukunftssicher umbauen.
Dafür kann man den übergreifenden Datenpunkt properties.electricLevel nutzen.

Ladegrenzen beachten:
Sobald das eingestellte socSet erreicht ist, stoppt das Laden ohnehin automatisch.
Man kann zusätzlich den Datenpunkt: properties.socLimit (0: normal, 1: Charge limit reached, 2: Discharge limit reached) nutzen, um den Status direkt abzufragen.

Mindestdauer & Hysterese:
Man könnte eine Mindestdauer für geänderte Limits einsetzen, um schnelles Hin- und Herschalten zu vermeiden.
Dein Trigger ist zwar alle 10 sec, aber ein setzen von einem neuen Limit bis es ordentlich und ruhig anfängt zu wirken, benötigt allein schon diese Zeit.
Eine kleine Hysterese hilft ebenfalls:
outputLimit erst ändern, wenn der neue Wert um mindestens X Watt (z. B. deine 10W oder 20W) vom aktuellen Wert abweicht.

Ist-Werte in Skripten vergleichen:
bitte nicht nur die reinen Sollwerte (z. B. Falls inputLimit === 100) vergleichen.
Es ist idealer wenn stattdessen die tatsächlich wichtigeren Ist-Werte mit eingebunden werden
(z. B. Falls inputLimit === 100 && properties.gridInputPower === 100).
Noch schöner ist es, wenn Du prüfst, ob das inputLimit bei 100 liegt und die gridInputPower innerhalb eines Toleranzbereichs von +/- X Watt oder X % des Limits liegt.

Da sind zwar noch ein paar kleine Ungereimtheiten drin, habe es nur grob überflogen, aber fürs erste hoffe ich, hilft dir das weiter.

Viel Erfolg!

[maxclaudi]

@Daniel-8 sagte:
Ich bin ja noch auf Api 2 und nutze eine Manuelle Kalibrierung über Iobroker.

Das machst Du auch gut so ;-)

Mein Post war an alle mit Firmware-Update API 3 gedacht, um evtl. das Script zu verbessern.

[maxclaudi]

@Jockel_Bln
hätte 2 Fragen, weil Du den 2400AC+ verwendest.

1. Welche Version verwendest Du?
   siehe Bild, Beispiel für version: 2

2. in früheren Firmware-Versionen unterscheiden sich die Geräte 24XX zu den anderen Solarflow 8xx
   in den Datenpunkten für den Lüfter:
   AC24XX hatten (haben noch?):
   properties.fanSwitch: 1
   properties.fanSpeed": 0

Bei den anderen Geräten SF8XX und 1600AC werden die Keys anders benannt:

properties.Fanmode: 1
properties.Fanspeed: 0

siehe Bild:

---

@Jockel_Bln und Alle die ein Zendure 24XX oder höher verwenden:

Sind die Unterschiede noch vorhanden, oder wurden die keys bei den Geräten 24XX AC oder >2XXX nun angepasst und liefern auch:
properties.Fanmode: 1
properties.Fanspeed: 0
?

Danke für jede Rückmeldung.

[Jockel_Bln]

Hallo @maxclaudi

@Jockel_Bln
hätte 2 Fragen, weil Du den 2400AC+ verwendest.

1. Welche Version verwendest Du?

Da mich die App gleich nach der Installation zum Update genötigt hat, habe ich die Version 3 drauf.

Sind die Unterschiede noch vorhanden, oder wurden die keys bei den Geräten 24XX AC oder >2XXX nun angepasst und liefern auch:
properties.Fanmode: 1
properties.Fanspeed: 0

Ich bekomme auch
properties.Fanmode: 1
properties.Fanspeed: 0

[maxclaudi]

@Jockel_Bln
Danke für die schnelle Rückmeldung.

[paul53]

@maxclaudi [sagte]: Die Werte sind nicht direkt „gelogen“

Stimmt. Ich messe jetzt mittels einer FRITZ!DECT 200 die Netzleistung des SF. Sie stimmt nahezu mit der "gridOffPower" überein (ca. 17 W), wenn "acMode" = 1 (Netzladen) und der SoC >= "socSet" ist.
Trotzdem steigt oberhalb von "socSet" der SoC um 1 % alle 2 Stunden, was einer Ladeleistung von 9 W entspricht, die auch im DP "Battery pack power" angezeigt wird. Woher kommt diese zusätzliche Leistung? Gibt es eine Zusatzbatterie?

[maxclaudi]

@paul53

Sorry, dazu kann ich mich nur wiederholen

maxclaudi sagte:
Wie das genau von Zendure gelöst ist kann ich nicht beurteilen.