eos.pv_battery_charge_control_enabled in ha?

[bennobiber]

Hätte mal ne Frage bzgl. dc_charge signal:

In der Doku steht "eos.pv_battery_charge_control_enabled

Parameter eos.pv_battery_charge_control_enabled
Description Allows the optimizer to control PV-to-battery charging on a per-slot basis using the dc_charge signal."

Ist das dc_charge nur EOS-connect intern bzw wird nur in Verbindung mit fronius-invertern verwendet? Wäre es möglich, den Endpunkt auch in ha abzubilden? "Einfach" nur ein boolean? 😬

[ohAnd]

Hi @bennobiber ,

dc_charge sollte immer, entsprechend output optimizer response, per
web api:

{
"current_states": {
  "current_ac_charge_demand": 0,
  "current_ac_charge_power": 0,
  "current_dc_charge_demand": 0,
  "current_discharge_allowed": true,
...

und mqtt:

eos_connect/control/eos_dc_charge_demand

auch nach aussen gegeben werden.
siehe auch:

• https://ohand.github.io/EOS_connect/advanced/index.html#current-states
• https://ohand.github.io/EOS_connect/advanced/index.html#mqtt-published

Gerne mal hier drauf schauen, werde dahingehend auch nochmal die Tests checken...

---

Direkt "angebunden" zur Steuerung ist es aktuell beim Fronius Inverter, so dass hier aktiv das Laden der Batterie unterbunden werden kann und der PV Input direkt an die Load und/ oder Grid geht. (wenn Optimierer es entsprechend duchsteuert)

[bennobiber]

Ach schade. Hatte gehofft, dass das nichts mit dc charge demand zu tun hat. Denn das hatte ich schon mal ausprobiert und das hat dann folgendes Verhalten gezeigt:

Die Lade Blöcke sind also etwas "zerhackt". In der frühen Phase der Planung sah das alles eher kompakt aus und scheint dann, wenn das Laden konkret umgesetzt werden soll so zerhackt zu werden.

Jetzt hab ich leider nicht mehr das log... Aber wenn ich nun weiß, dass das tatsächlich dc charge demand ist, dann beobachte ich das mal weiter und melde mich wieder.

[ohAnd]

Ja bitte ...

An den Output als solches muss ich eh nochmal ran ... ;-) (stärkere Entkoppelung vom aktuellen Ergebnis, mehr planbasiert und wenn nötig Glättung)

Aktuell wird direkt aus dem aktuellem Ergebnis (aktueller Slot in der Planung) durchgesteuert - für AC_Charge ist da schon eine Umrechnung/ Glättung auf den aktuellen 15min slot drin, aber noch nicht final - dc_charge ist 1zu1 und discharge_allowed ebenso.

Je nach Refresh Time bekommst du dann die o.g. zerhakten Outputs ... vielleicht zum Testen mal auf 10 min hochsetzen, durch das scheduling wird dann versucht immer kurz vor dem 15 min slot ein neues Ergebnis zu bekommen - so würde dann auch ein dc_charge nur alle 15 min gesetzt.

[bennobiber]

Funktioniert ziemlich gut: