Test Adapter Zendure Solarflow

[nograx]

@diet99 Da sollte (hoffentlich) nichts zurückgesetzt werden...

[diet99]

@nograx Ich meinte damit die aktuellen calculations. Bleiben die auch erhalten beim Update?

[nograx]

@diet99 Ja da dürfte nichts passieren, außer das er die paar Sekunden des Update nicht berechnet.

[diet99]

@nograx Super - scheint geklappt zu haben - danke!

Sehe ich das richtig, daß man den Bypass-Status jetzt auch aus dem Adapter her steuern kann? Das ist natürlich ne super Sache, weil der bei mir immer wieder regelmäßig auf "Auto" gegangen ist, was ich eigentlich nicht will. Er soll auf "Always off" sein.

[nograx]

@diet99 Ja das funktioniert. Bei mir springt der auch immer wieder auf "Auto". Lasse mir jetzt über ioBroker eine Benachrichtigung schicken wenn der sich ändert.

[diet99]

@nograx Sehr gute Idee!
In welcher Form müssen die Steuerwerte in der control-Section angegeben werden für autoRecover, buzzerSwitch und passMode?

[nograx]

@diet99 autoRecover, buzzerSwitch sind boolean, passMode eine Ganzzahl / Integer. Hinter passMode sollte aber eine Dropdown mit "Auto", "always off" und "always on" hinterlegt sein.

[diet99]

@nograx Ah - richtig. Paßt!
Und wenn man es aus einem Script ansteuern möchte, gibt man das vermutlich genauso an. Muß das bei Gelegenheit mal ausprobieren.

Klasse!

[diet99]

Was mich gerade noch etwas irritiert, ist das hier:

Der aktuelle Ladezustand ist hier korrekt angezeigt:

[nograx]

@diet99 sehe gerade das der Wert für energyWh und energyWhMax bei dir absolut nicht passen können. Ich habe bei github ein issue der das selbe Thema hat. Kann mir nicht erklären wie das zustande kommt.

[nograx]

@nograx sagte in Test Adapter Zendure Solarflow:

@diet99 autoRecover, buzzerSwitch sind boolean, passMode eine Ganzzahl / Integer. Hinter passMode sollte aber eine Dropdown mit "Auto", "always off" und "always on" hinterlegt sein.

Ich befürchte in einem Script musst du den Integer Wert nehmen?

Wäre dann so:
0: "Automatic",
1: "Always off",
2: "Always on",

[diet99]

@nograx Muß ich ausprobieren. Kann aber noch ein paar Tage dauern, bis ich dazukomme, da was zu basteln.

Ich muß erstmal mein Einspeise-Start-Script überarbeiten, weil das noch nicht 100%ig so läuft, wie ich mir das vorstelle.

Das hatte ich ja schonmal gepostet gehabt. Ich möchte erst ab 30% Akkufüllstand anfangen einzuspeisen und dann auch nur, wenn mindestens 150W Solarleistung anliegen. Damit soll der Einspeise-Ping-Pong bei niedrigem Akkustand und geringer Einspeiseleistung vermieden werden.
Die Werte sind als beispielhaft zu betrachten.

Abends/nachts schalte ich dann wieder auf Null, wenn der Akku leer ist:

Es kommt aber trotzdem immer wieder vor, daß die Einspeisung bereits unter den 30% startet, sobald mehr als das eingestellte Minimum im Akku ist.
Irgendwas übersehe ich da noch.

[nograx]

@diet99 Darf ich fragen warum du 600Watt ins Haus scheibst? Oder drosselst du da noch mit dem Wechselrichter?

[diet99]

@nograx Exakt: ich habe OpenDTU-onBattery im Einsatz hinter dem PVHub. Dort ist die Regelung meines Hoymiles HM-800 auf 600W gedeckelt. Daher gebe ich 600W aus dem PVHub frei.
Die Regelung über OpenDTU funktioniert wesentlich besser und schwingungsärmer (ohne heftige Spitzen bei der Regelung), als wenn ich z.B. den PVHub über Shelly und den Smart CT Mode regeln lasse.

[nograx]

@diet99 Absolut nachvollziehbar. Ich habe noch 2 Module direkt am Hoymiles (1500). Daher kann ich nicht über die (Ahoy)-DTU drosseln, da ich dann die Module auch mit runterregle...

[diet99]

@nograx Hmmm ... was ist da los?

Hatte ich mit der 1.2.5 nie.

[nograx]

@diet99 gibt es Logs?

[The_Stig]

@nograx Danke dir erstmal für deine Arbeit. Ich habe gerade die Versandmitteilung für den Hub2000 bekommen. Ist das zwischenzeitlich mit in deiner Steuerung drin?

[diet99]

@nograx Wenn ich wüßte, wie ich Logs vom Vortag einsehen kann. Da muß ich mal suchen.

[diet99]

Wie kommen eigentlich die beiden obersten Werte zustande?
Und meine beiden Akkus haben derzeit 71%, d.h. die 100% SOC sind irgendwie unsinnig.

Danke!