Hallo Community,
nachdem der Controller mit seiner derzeitigen Funktionalität beschrieben ist, hier nun die evcc Seite der Geschichte. Unser evcc.yaml startet mit dem Üblichen …
# definition of site
site:
title: Zuhause
meters:
grid: my_grid
pv: my_pv
battery: my_battery
… die loadpoints sind schon etwas interessanter …
# definition of loadpoints
loadpoints:
- title: Garage
...
priority: 10 # ensure, that Wallbox gets served first
# definition of heatpump
- title: Wärmepumpe
charger: my_heatpump_control
vehicle: my_heatpump
meter: my_heatpump_power
priority: 0 # ensure, that heatpump has the lowest priority
enable:
threshold: 4000 # Stiebel Eltron WPL-A 07 HK 230 Premium consumes max. 3,5kW
delay: 30m # threshold needs to be exceed for at least 30 minutes
disable:
threshold: 500
delay: 15m
… da hier definiert wird, dass unser E-Auto eine höhere Priorität als die Wärmepumpe bekommt und es wird ebenfalls definiert, dass (in unserem Fall) mindestens ein Überschuss von 4kW für 1/2h bestehen muss, bevor Betriebsmodus 3 der Wärmepumpe angeworfen wird.
Um die Einspeisung zu messen nutzen wir ein Shelly Pro 3em …
# definition of meters (see https://docs.evcc.io/docs/devices/meters)
meters:
# Shelly Pro 3em as grid meter
- name: my_grid
type: template
template: shelly-pro-3em
usage: grid
host: <your ip address>
# Solarwatt PV
- name: my_pv
type: template
template: solarwatt-flex
usage: pv
host: <your ip address>
# Solarwatt Battery Flex
# remark: the template as provided by evcc holds an error, therefore utilize a custom definition
- type: custom
Power:
source: http
uri: <your uri>
headers:
- content-type: application/json
jq: .state|split(" ")[0]|split(".")[0]
SoC:
source: http
uri: <your uri>
headers:
- content-type: application/json
# jq: .state
jq: .state | sub(" %"; "") | tonumber
Energy:
source: http
uri: <your uri>
headers:
- content-type: application/json
jq: .state|split(" ")[0]|split(".")[0]
scale: 0.001
name: my_battery
Haben der Vollständigkeit halber den Solarwatt Teil drin gelassen. Interessant ist an dieser Stelle der Wärmepumpenteil …
# definition for heatpump
- name: my_heatpump_power
type: custom
power:
source: http
uri: http://homeassistant.local:8123/api/states/sensor.warmepumpe_summe_verbrauch
method: GET
jq: .state | tonumber
headers:
- content-type: application/json
- Authorization: Bearer <your token>
energy:
source: http
uri: http://homeassistant.local:8123/api/states/sensor.warmepumpe_energie_verbrauch
method: GET
jq: .state | tonumber
headers:
- content-type: application/json
- Authorization: Bearer <your token>
… wir greifen, über REST, auf Sensoren unserer Home Assistant Instanz zu und ermöglichen es so die entsprechenden Werte im UI von evcc darzustellen. Notwendig hierfür ist ein sogenanntes “long lived access token”. Wie man dazu kommt ist u.a. hier beschrieben. Dank dieses Ansatzes konnten wir bisher MQTT vermeiden.
Nun kommt der interessanteste Teil:
# definition of charger (see https://docs.evcc.io/docs/devices/chargers)
chargers:
- name: my_charger
type: template
template: openwb-pro
host: <your ip address>
# definition for heatpump as a smart switch
- name: my_heatpump_control
type: template
template: homeassistant-switch
baseurl: http://homeassistant.local:8123
token: <your token>
switchentity: input_boolean.anforderung_sg_ready_betriebszustand_3
standbypower: -4000
integrateddevice: true
icon: heatpump
Unsere Wärmepumpe ist, wie schon in der Architekturübersicht gesagt, als “Smart Switch” aufgesetzt. evcc meint also es hätte es mit …
… zu tun
# definition of vehicle
vehicles:
- name: my_car
...
# definition for heatpump
- name: my_heatpump
type: template
template: homeassistant
title: 'Stiebel Eltron'
icon: heater
uri: http://homeassistant.local:8123 # address of Home Assistant instance
token: <your token>
phases: 3
soc: sensor.heatpump_pv_optimization_soc
… einen simulierten SoC, der es uns ermöglicht im evcc UI das Aufheizen des Wassers durch die Wärmepumpe in Betriebszustand 3 zu visualisieren.
Damit wäre der evcc Anteil komplett.
