RCT Power Batterie Steuerung

[hrncvk]

Is your feature request related to a problem? Please describe.
Wenn ich mein Auto schnell laden möchte würde ich gerne Nachts nichts aus dee Batterie ziehen wollen.

Describe the solution you'd like
Eine Toggle wo man anwählen kann, ob die Batterie herangezogen werden soll oder nicht.

Describe alternatives you've considered
Wenn es nicht per Modi bestimmt werden kann, dann grundsätzlich anbieten können, die Batterie abzukoppeln.

[andig]

Gibts dafür ein Api? ohne können wir nix tun…

[hrncvk]

https://github.com/svalouch/python-rctclient

Darüber wurde es realisiert... Könnt ihr was davon benutzen? 😥

[andig]

Sicher nicht:

The CLI does not include support for changing values. This will not change in the foreseeable future. TL;DR: It's just too dangerous.

Wer das bei sich ausprobieren und dann einen PR erstellen will ist herzlich willkommen. Wir werden hier kein Risiko für Kundengeräte eingehen!

[hrncvk]

OK schade ☹️

[hrncvk]

Ja muss es gäben, da es Leute gibt die mit Home Automation sowas bereits betreiben mit HTTP Calls um bspw. die Batterie mit günstigem Strom zu laden

[hrncvk]

Habe im Forum nachgefragt. Sobald ich eine Rückmeldung bekomme teile ich sie hier

[TobiasHuber1980]

Ich hatte das auch mal bei RCT angefragt....

Die Anbindung eines RCT-Systems an Tibber ist nicht möglich.
Nein es gibt nicht die Möglichkeit Batterien gezielt aus dem Netz zu laden.

Ich bin mir aber sicher, dass es geht, die wollen bloß nicht!

[do-gooder]

Um die Batterie komplett rauszunehmen, muss power_mng.soc_strategy auf 4 (Extern) gesetzt werden und power_mng.battery_power_extern sollte dann auf 0 stehen. Dann wird die Batterie nicht mehr verwendet!
Sollte sich die Frage wie kritisch das schreiben der Werte sein kann. Bei mir funktioniert das soweit gut. Allerdings in einem windigen python-Skript.

[do-gooder]

Gleiches gilt übrigens auch für das Laden mit Tibber: power_mng.soc_strategy auf 4 (Extern) setzen und power_mng.battery_power_extern auf z.B. -6000 setzen. Dann wird der Akku mit 6kW geladen. Alles was nicht von der PV kommt wird dann aus dem Netz nachgeladen.
Wenn man fertig ist, kann man einfach power_mng.soc_strategy wieder auf z.B. den Standardwert 2 (Intern) setzen.

[PhilJaro]

Ich wäre ebenfalls hieran interessiert und habe in dem Zusammenhang gerade das hier gefunden:
https://github.com/do-gooder/rctpower_writesupport

Eventuell kann diese Implementierung weiter helfen.

[do-gooder]

@andig: Kannst du https://github.com/do-gooder/rctpower_writesupport für RCT umsetzen? Von der Logik her sollte das nicht sehr komplex sein.

Mich würde vor allem die Entladesperre interessieren. Sollte sich das etablieren, ist das Netzladen auch interessant.

[maximilianadolf]

@do-gooder, ich benutze seit gestern dein https://github.com/do-gooder/rctpower_writesupport für smartes Laden mit Tibber. Ich habe es mit der zweiten Integrationsmethode als Package in HomeAssistant eingebunden und kombiniere es mit https://github.com/marq24/ha-evcc für die Statusmeldungen aus EVCC.

Automatisierung:
Wenn EVCC Smartes Netzladen ändert, dann schaue ich auf den Status von Smartes Netzladen TRUE und schaue ob ich laden auch auf TRUE habe. In dem Fall wird die Batterie gesperrt.
In allen anderen Fällen wird sie wieder entsperrt.

Zumindest die Ladesperre hat heute Nacht funktioniert, das entsperren noch nicht (deswegen habe ich jetzt das Laden hinzugefügt). Wahrscheinlich braucht die Sache noch ein wenig feintuning in der Automatisierung, aber das sollte sich so realisieren lassen.

Automation:
`

alias: Smartes Netzladen - Entladesperre
description: Wenn EVCC Smartes Netzladen startet, dann wird die RCT Batterie gesperrt.
triggers:
  - trigger: state
    entity_id:
      - sensor.evcc_garage_charged_energy
conditions: []
actions:
  - if:
      - condition: state
        entity_id: binary_sensor.evcc_garage_smart_cost_active
        state: "on"
      - condition: state
        entity_id: binary_sensor.evcc_garage_charging
        state: "on"
    then:
      - action: switch.turn_on
        metadata: {}
        data: {}
        target:
          entity_id: switch.rct_lock_battery
    else:
      - action: switch.turn_off
        metadata: {}
        data: {}
        target:
          entity_id: switch.rct_lock_battery
mode: single

`

[do-gooder]

Danke für dein Feedback!

Wenn du eine funktionierende Version hast, erstelle gerne ein Pull Request für das Projekt rctpower_writesupport.

[mr42hh]

Ich melde auch mal Interesse an, meine Eltern betreiben eine RCT-Anlage und bekommen demnächst einen elektrischen Ersatz für den Langstreckendiesel, wahrscheinlich kommt auch Tibber ins Haus...

[dynamicpete]

Hallo,
ich wäre ebenfalls an einer Lösung für den RCT-Power Speicher interessiert.

[andig]

Im Moment würde ich Euch vorschlagen, dass mittels custom meter extern zu integrieren. Die von uns verwendete RCT Library für Go unterstützt keine Schreibbefehle.

[dynamicpete]

Sorry für die blöde Frage, aber was genau bedeutet Dein Vorschlag?

[StefanSchoof]

Du kannst per custom meter https://docs.evcc.io/docs/reference/configuration/meters#custom shell Befehle ausführen https://docs.evcc.io/docs/reference/plugins#shell-script-lesenschreiben Die müssten dann das oben genannte Tool aufrufen.

[do-gooder]

Der Doku kann ich aber nicht entnehmen, dass ich ein Skript aufrufen kann, wenn z.B. die Entladesperre aktiviert werden soll.
Weiß dazu jemand mehr?

[andig]

Schau mal in die /templates/definition/meter wo batterymode verwended wird

[flod-1]

Ich hätte ebenfalls Interesse an einer Lösung hierzu.

[Maschga]

Update: #18178

[Maschga]

PR ist gemergt und ab morgen im Nightly. Gerne schon vor dem Release ausprobieren.

[documentONE]

Wow, vielen Dank für Eure Arbeit an dem Thema; darauf warte ich schon lange :-)
Weiß jemand, wie sich das Szenario mit zwei WR und jeweils eigener Batterie verhält?

[documentONE]

Ich werde testen und Rückmeldung geben
Danke für Eure Arbeit

[TobiasHuber1980]

Wenn die als Master/Slave konfiguriert sind, dann wird es als ein Gerät zusammengefasst.

[documentONE]

Das bekommt RCt in der eigenen App schon nicht geregelt...

[Maschga]

Hast du es testen können?

[documentONE]

Ich liege leider flach, im Moment komme ich nicht dazu

[TobiasHuber1980]

hat jemand von euch einen dynamischen stromtarif?

[documentONE]

aktuell noch nicht, aber zum Testen würde ich einfach einen konfigurieren

[rjanowsky]

Habe mal versucht, dass bei mir zu testen:

type: template
template: rct-power
usage: battery
capacity: 9
minsoc: 50
maxsoc: 97
host: 192.168.x.x

Ist das so richtig in der evcc.yaml oder fehlt noch etwas?

Nach meinem Verständnis sollte nun mehr beim Schnellladen die Battery nur bis zum minsoc: 50 herangezogen werden. Das hat so aber nicht funktioniert. I

m Log sind viele Einträge wie:
Feb 03 15:19:55 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:19:55 pv 1 power: invalid response to read of 536F6C61722067656E>
Feb 03 15:20:27 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:20:27 grid power: parsing failed in state 0
Feb 03 15:21:56 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:21:56 battery 1 power: parsing failed in state 0
Feb 03 15:23:26 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:23:26 battery 1 power: parsing failed in state 0
Feb 03 15:24:56 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:24:56 pv 1 power: parsing failed in state 0
Feb 03 15:26:26 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:26:26 pv 1 power: parsing failed in state 0
Feb 03 15:27:57 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:27:57 battery 1 soc: parsing failed in state 0
Feb 03 15:29:26 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:29:26 pv 1 power: parsing failed in state 0
Feb 03 15:29:28 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:29:28 grid energy: parsing failed in state 0
Feb 03 15:30:56 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:30:56 pv 1 power: invalid response to read of 536F6C61722067656E>
Feb 03 15:30:57 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:30:57 grid energy: parsing failed in state 0
Feb 03 15:32:26 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:32:26 pv 1 power: invalid response to read of 23494E56414C4944: >
Feb 03 15:32:26 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:32:26 grid power: parsing failed in state 0
Feb 03 15:33:57 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:33:57 battery 1 soc: parsing failed in state 0
Feb 03 15:33:57 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:33:57 grid power: parsing failed in state 0
Feb 03 15:35:25 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:35:25 pv 1 power: parsing failed in state 0
Feb 03 15:35:27 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:35:27 battery 1 soc: parsing failed in state 0
Feb 03 15:36:55 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:36:55 battery 1 power: invalid response to read of 4261747465727>
Feb 03 15:36:57 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:36:57 grid power: parsing failed in state 0
Feb 03 15:38:26 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:38:26 battery 1 power: invalid response to read of 4261747465727>
Feb 03 15:38:27 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:38:27 battery 1 soc: parsing failed in state 0
Feb 03 15:39:56 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:39:56 pv 1 power: parsing failed in state 0
Feb 03 15:41:26 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:41:26 battery 1 power: parsing failed in state 0
Feb 03 15:42:56 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:42:56 battery 1 power: parsing failed in state 0
Feb 03 15:42:57 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:42:57 battery 1 soc: parsing failed in state 0
Feb 03 15:44:26 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:44:26 battery 1 power: parsing failed in state 0
Feb 03 15:44:27 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:44:27 grid energy: parsing failed in state 0
Feb 03 15:45:57 raspi-evcc evcc[26110]: [site ] ERROR 2025/02/03 15:45:57 grid energy: parsing failed in state 0

Fehlerhafte Konfiguration auf meiner Seite?

[Maschga]

minsoc ist der Minsoc der Batterie, der SoC der Batterie wird damit nicht unter den SoC fallen, sollte also am Besten bei 7% bleiben. Das ist auch der Default von RCT. maxsoc ist der SoC, bis zu dem geladen werden soll.
Beide Parameter wurden von den Fahrzeugtemplates geklaut und passen deshalb nicht gut. Dafür gibt es schon ein Issue.
Lass den minsoc auf 7% und setze maxsoc auf 50%. Dann sollte es funktionieren.

[Maschga]

Ich glaube ich bringe hier etwas durcheinander. Ich war im Hold-Modus.
Das Feature, dass du gerne hättest, gibt es - glaube ich - in evcc (noch) nicht.

[rjanowsky]

Danke für die schnelle Antwort. ich warte dann noch einmal die weitere Entwicklung ab. Hat für mich keine Eile.

[HWE70]

Jetzt wo 0.200 verfügbar ist, hätte ich das auch gerne einmal ausprobiert. Bisher hatte ich mir dir RCT Daten aus FHEM per MQTT geholt. Mit der aktiven Batteriesteuerung geht das dann natürlich nicht (ok FHEM kann das auch, von daher ginge es schon über MQTT, aber ich will ja die RCT-Steuerung von EVCC testen). Um FHEM weiter an den RCT angebunden zu haben, habe ich in EVCC einen Modbus Proxy definiert und diesen dann auch RCT intern nutzen wollen:

modbusproxy:

• port: 8899
  uri: 192.168.40.18:8899
• name: rct
  type: template
  template: rct-power
  usage: grid
  host: 127.0.0.1
• name: pv
  type: template
  template: rct-power
  usage: pv
  host: 127.0.0.1
• name: battery
  type: template
  template: rct-power
  usage: battery
  host: 127.0.0.1

Obwohl sonst nichts mehr gegen RCT API läuft, bekommt man über den modbusproxy durchgängig Fehler:

[site ] ERROR 2025/02/13 23:21:51 battery 1 power: read tcp 127.0.0.1:39194->127.0.0.1:8899: read: connection reset by peer
[site ] ERROR 2025/02/13 23:21:51 battery 1 soc: read tcp 127.0.0.1:39210->127.0.0.1:8899: read: connection reset by peer
[site ] ERROR 2025/02/13 23:21:51 pv 1 power: read tcp 127.0.0.1:39226->127.0.0.1:8899: read: connection reset by peer

Allerdings nur für PV und Battery. Nicht für Grid. Ohne den modbusproxy dazwischen funktioniert es. Hat jemand Erfahrungen mit RCT und modbusproxy? Der Proxy ist je eigentlich genau dafür gedacht, die Anfragen zu serialisieren und Fehler wie oben zu vermeiden.

[Maschga]

Ich hatte gestern nach dem Update auf 0.200 den gleichen Fehler read: connection reset by peer. Nach ca. einer Minute wurde dieser Fehler in der UI angezeigt und bis zu diesem Fehler war die evcc-Energie-Verteilungsleiste ausgegraut (weil eben die Informationen von RCT dazu gefehlt haben). Nach diesem Fehler aber konnten diese Informationen angefragt werden, und diese Energie-Verteilungsleiste funktionierte wie gewohnt. Dieser Fehler kam gestern auch nicht mehr auf.

Heute habe ich evcc erneut gestartet, um zu testen, ob das gleiche Verhalten nochmal auftritt. Glücklicherweise nicht, das Starten von evcc funktionierte ohne Probleme.

Deswegen kann ich dir gerade nur raten, dein Vorhaben etwas später noch einmal auszuprobieren, wobei ich aber auch nicht modbusproxy nutze.

PS:
Mit evcc-Energie-Verteilungsleiste meine ich das hier:

[HWE70]

Hi, ohne den Modbus Proxy läuft das wunderbar. Es ist also eher ein modbusproxy Thema und kein Thema mit der RCT Connector an sich.

[Maschga]

Da kann ich dir leider nur schlecht helfen.
Ich weiß nicht, wie der Modbus-Proxy funktioniert.