Add active battery control deye-hybrid-3p.yaml

[deadrabbit87]

Da sollte auf jeden Fall nochmal drüber geschaut werden.

Nach ersten Tests funktioniert hold und normal
fix #12333

[andig]

Dito

[deadrabbit87]

Ja, deswegen auch draft.

Wie charge umzusetzten wäre, müsste auch noch eruiert werden. Es scheint mir, als müssen da wieder mal Leistungswerte gesetzt werden, was ATM nicht gemacht wird.

[deadrabbit87]

Kannst du mir einen Tipp geben, wie ich auf den Parameter soc zugreifen kann und diesen dann auf Register 166 setzen kann?

Hier wird es ja so gemacht, aber ich werde da nicht schlau daraus.

[deadrabbit87]

Ja, deswegen auch draft.

Wie charge umzusetzten wäre, müsste auch noch eruiert werden. Es scheint mir, als müssen da wieder mal Leistungswerte gesetzt werden, was ATM nicht gemacht wird.

Laden der Batterie nach Ziel soc würde über Register 172 funktionieren. Das wäre auch aus dem time of use Zeitslot 1 und muss dazu auf 1 gesetzt werden.

Allerdings muss hierzu zuerst in den Einstellungen das Laden der Batterie aus dem Netz global aktiviert werden. Das wäre Register 130.

Damit sich dieses aber aktivieren lässt, muss zuerst der Strom für das Netzladen und ein soc konfiguriert werden. (Register 127 und 128) werden. Siehe auch hier in der Anleitung:

Mein Vorschlag wäre, dass evcc nur Register 172 setzt und die anderen beiden Register von Benutzer manuell gesetzt werden müssen.

Eine andere Möglichkeit hätte ich jetzt für den Deye nicht rausgefunden.

[deadrabbit87]

Sorry, ich komme hier nicht wirklich weiter.

So wie es aktuell ist, würde es funktionieren, wenn batterymodeund limitsoc ausgeführt werden.

Das ist aber anscheinend nicht vorgesehen, bzw es wird nur der Teil mit limitsocausgeführt.

Ich verstehe halt den grundlegenden Mechanismus noch nicht, wie die Templates genau funktionieren.

[andig]

Es gibt 2 unterschiedliche Ansätze- entweder über limitsoc implizit oder über batterymode. Die sind nciht zu kombinieren.

[deadrabbit87]

Es gibt 2 unterschiedliche Ansätze- entweder über limitsoc implizit oder über batterymode. Die sind nciht zu kombinieren.

Ja, das habe ich auch festgestellt. Daher wäre es das beste, über batterymode zu gehen.

Ich verstehe hier nur nicht, wie ich auf de Variable des socs zugreifen kann um die Batterie in hold zu versetzen.

Einfach auf 100% setzen würde zwar auch passen, aber halt nicht schön....

Kannst du mir da einen Tipp geben?

[andig]

Das geht aktuell nicht :/

[deadrabbit87]

Dann muss es so sein, wie es zu Beginn war. Also bei hold der soc fest codiert auf 100.

Bei charge und normal werden die Variablen verwendet.

Es wäre jetzt nicht jedes mal notwendig die tou Zeiten neu zu schreiben.

Warum der UI check fehlschlägt kann ich mir nicht erklären.

Ist mein erster ernsthafter PR, ich hoffe daher, dass ich nicht allzuviel falsch gemacht habe....

[andig]

Den letzten musst Du bitte selbst ändern:

• {{- end }}
  \ No newline at end of file

Du hast den Zeilenumbruch geklaut...

[Blowfly69]

Hallo,

muss den PR nochmal öffnen: Das Template funktioniert in meinem Setup (Deye Sun-12K-SG04LP3) zwar prinzipiell, hat aber sehr unschöne bis kritische Nebeneffekte:

• Die von mir voll genutzte "Time of Use" Tabelle wird unbrauchbar, weil nach Aktivieren von hold die Zeiten in den ersten beiden Zeilen überschrieben werden. Danach sind nur noch diese beiden Zeilen aktiv (0:00-23:55, 23:55-0:00)
• Als SoC steht nach Übergang zu hold und ab dann permanent in der zweiten Zeile eine 0 (im Display des WR), im Home Assistant wird das Feld sogar mit einem Fehler als "nicht-numerisch" angezeigt.

Gerade der letzte Punkt bereitet mir Bauchschmerzen, ein Ziel SoC von 0 (oder irgendwas undefiniertes) ist in keinem Fall wünschenswert. Vielleicht ist das auch das was in #12963 festgestellt wurde.

Prinzipiell sollte evcc mMn bei Rückkehr zu normal den ursprünglichen Zustand im Setup des WR wiederherstellen, in dem Fall also alle Zeiten und SoC Werte. Wenn man die Tabellenwerte vor dem Übergang nach hold abfragen und zwischenspeichern könnte, und sie nach Ende wieder zurückspielt, wäre das der sauberste Weg (keine Ahnung ob das geht).

Ich hätte noch einen alternativen Vorschlag:
Anstelle der im Template benutzten Modbus Register für die ToU Tabelle könnte einfach das Register für den maximalen Entladestrom der Batterie (109 - Maximum Battery Discharge Current) verwendet werden. Im Template den Maximalwert maxdischargecurrent vom User abfragen, für hold auf 0 setzen und danach wieder zurück auf maxdischargecurrent.

Für charge bin ich allerdings im Moment auch noch am Überlegen, ob und wie man das anders machen könnte.

[andig]

Die von mir voll genutzte "Time of Use" Tabelle wird unbrauchbar, weil nach Aktivieren von hold die Zeiten in den ersten beiden Zeilen überschrieben werden. Danach sind nur noch diese beiden Zeilen aktiv (0:00-23:55, 23:55-0:00)

Blöd aber akzeptabel wenn wir das im Template dokumentieren. Wer ToU braucht kann das dann eben nicht verwenden.

Als SoC steht nach Übergang zu hold und ab dann permanent in der zweiten Zeile eine 0 (im Display des WR), im Home Assistant wird das Feld sogar mit einem Fehler als "nicht-numerisch" angezeigt.

In anderen Templates die über limitsoc gesteuert werden haben wir dafür einen minsoc Parameter. Der könnte auch hier verwendet werden.

Prinzipiell sollte evcc mMn bei Rückkehr zu normal den ursprünglichen Zustand im Setup des WR wiederherstellen

Das geht mit Templates nicht...

[deadrabbit87]

• Die von mir voll genutzte "Time of Use" Tabelle wird unbrauchbar, weil nach Aktivieren von hold die Zeiten in den ersten beiden Zeilen überschrieben werden. Danach sind nur noch diese beiden Zeilen aktiv (0:00-23:55, 23:55-0:00)

Das scheint mir, wie @andig schon geschrieben hat, eine Eigenheit des WR zu sein. Geschrieben wird nur TOU1. Warum er dann die anderen auch mit ändert. liegt nicht in dem Einflussbereich von evcc.

• Als SoC steht nach Übergang zu hold und ab dann permanent in der zweiten Zeile eine 0 (im Display des WR), im Home Assistant wird das Feld sogar mit einem Fehler als "nicht-numerisch" angezeigt.

Wann genau passiert das? Wenn evcc von normal auf hold wechselt?

Der minsoc und maxsoc-Parameter wird hier schon verwendet. Hast du die auch gesetzt?

Ich hätte noch einen alternativen Vorschlag:
Anstelle der im Template benutzten Modbus Register für die ToU Tabelle könnte einfach das Register für den maximalen Entladestrom der Batterie (109 - Maximum Battery Discharge Current) verwendet werden. Im Template den Maximalwert maxdischargecurrent vom User abfragen, für hold auf 0 setzen und danach wieder zurück auf maxdischargecurrent.

Nach meinen Kenntnissen ist es so, dass das Kernteam mal vor einiger Zeit beschlossen hat, dass evcc aus Sicherheitsgründen keine Leistungswerte schreibt und dies dem WR überlassen werden soll. Daher die etwas umständliche Lösung über die TOU.

[andig]

/cc @premultiply

[Blowfly69]

Das scheint mir, wie @andig schon geschrieben hat, eine Eigenheit des WR zu sein. Geschrieben wird nur TOU1. Warum er dann die anderen auch mit ändert. liegt nicht in dem Einflussbereich von evcc.

Ja, das ist wohl so, wenn du Endzeit von TOU1 setzt, ist das ja gleichzeitig die Anfangszeit von TOU2. Und wenn die dann zeitlich nach der bisher definierten Endzeit von TOU2 (= Anfangszeit TOU3) liegt, setzt der WR TOU3 wohl automatisch auf 0:00.

• Als SoC steht nach Übergang zu hold und ab dann permanent in der zweiten Zeile eine 0 (im Display des WR), im Home Assistant wird das Feld sogar mit einem Fehler als "nicht-numerisch" angezeigt.

Wann genau passiert das? Wenn evcc von normal auf hold wechselt?

Ja, genau dann, gerade wieder so passiert:

Der minsoc und maxsoc-Parameter wird hier schon verwendet. Hast du die auch gesetzt?

Habe ich, hier Auszug aus meiner evcc.yaml.

  template: deye-hybrid-3p
  id: 1
  device: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB0NKKQN-if00-port0
  baudrate: 9600
  comset: 8N1
  usage: battery
  modbus: rs485serial
  capacity: 14.4
  minsoc: 20
  maxsoc: 100
  name: battery1

Ich hätte noch einen alternativen Vorschlag:
Anstelle der im Template benutzten Modbus Register für die ToU Tabelle könnte einfach das Register für den maximalen Entladestrom der Batterie (109 - Maximum Battery Discharge Current) verwendet werden. Im Template den Maximalwert maxdischargecurrent vom User abfragen, für hold auf 0 setzen und danach wieder zurück auf maxdischargecurrent.

Nach meinen Kenntnissen ist es so, dass das Kernteam mal vor einiger Zeit beschlossen hat, dass evcc aus Sicherheitsgründen keine Leistungswerte schreibt und dies dem WR überlassen werden soll. Daher die etwas umständliche Lösung über die TOU.

Ok, das ist verständlich, wenn da beim Schreiben ein Fehler passiert, wäre das schon sehr "suboptimal".

Noch eine andere Idee:
Anstelle die Zeiten zu schreiben, einfach alle TOU1-6 SoC Werte mit minsoc bzw. maxsoc überschreiben. Damit bleiben die Tabellen benutzbar. Wenn man hier etwas einstellt, dann ja überwiegend bei den Zeiten und Max-Leistungen (zumindest mein use case, damit mir in den Stunden ohne PV die WP nicht so schnell die Batterie leernuckelt. Die SoC Werte sind alle gleich.)

[Blowfly69]

Ich habe meine Idee mal getestet und das template entsprechend erweitert, setze also alle SoC-Werte bzw. grid charge Bits der TOU Tabelle bzgl. der Erfordernisse des aktuellen Modus, lasse aber alle Zeitänderungen weg.

Erfolgreich getestet in allen Modi normal, hold und charge, d.h. die Tabelle bleibt (weitgehend) erhalten. Nur falls ein User gezielt verschiedene SoC oder Haken bei grid charge in der Tabelle gesetzt hat, werden diese überschrieben. Aber ich glaube da gibt es nur sehr wenige "Betroffene".

Da damit das ursprüngliche Konzept erhalten bleibt, keine ungewünschten "0" Einträge vom WR erzeugt werden und auch die Sicherheitsvorgaben eingehalten werden (kein Schreiben von Leistungen/Strömen), würde ich vorschlagen, dazu einen neuen PR zu starten.

@deadrabbit87 , @andig einverstanden?

[andig]

Gerne 👍🏻

[deadrabbit87]

Ich hab kein Problem damit.

@premultiply @andig Was aber noch zu klären wäre, ob jetzt definitiv keine Leistungswerte geschrieben werden dürfen oder nicht.

Ich hatte hier auch schon mal gefragt, aber keine Antwort erhalten.

M.E. würde das bei vielen WR einiges erleichtern.

[premultiply]

Man kann Leistungsgrenzwerte schreiben wenn diese sich zwischen einem definierten Default-Wert und 0 bewegen.
Meistens scheitert es schon an der dürftigen oder unklaren Doku zu derartigen Parametern.

Was wir keinesfalls tun werden ist mit evcc ständig irgendwelche Batterieleistungen nach- bzw. ausregeln.

Wie immer lassen wir die Batteriesteuerung dann lieber ganz weg bevor es hier Probleme gibt.

Das scheint hier möglicherweise auch nötig zu sein?

[deadrabbit87]

Danke - im Fall vom Deye würde ich das trotzdem über die TOU machen.

Ich kenn nur Register 109 - max A discharge. Ich denke allerdings, dass hier häufig spezfische Werte die zur Batterie passen gesetzt sind und es daher schnell problematisch werden könnte, wenn da was falsches geschrieben wird.

[Blowfly69]

Ja, direkt die Ströme reinschreiben wäre einfacher, aber ich kann die Bedenken nachvollziehen. Nachdem hier keine leistungsbezogenen Größen geschrieben werden, sollte die Verwendung der TOU so passen. Ich schicke gleich den PR raus, @deadrabbit87 , vielleicht kannst du das ja auch mal bei dir testen.