Hi,
I just wanted to share my successful learning experience with Modbus TCP, Home Assistant, and electric car charger.
I hope this helps others who are new to Modbus or are thinking about electric car charger control.
Difficult part was to understand that coil and register are just different datatypes of Modbus. mbpoll was usefull in early testing. It’s a Linux command line tool for sending and reading Modbus TCP. No passwords or any other means of security, so depending on your case this might be problem or benefit :).
I bought an electric car and a home charger (wallbox) for it about a month ago. The charger was the cheapest possible with Ethernet connection I could find (at least when considering my other requirements). Manufacturer did not provide any info on Ethernet, but I took the risk. I had found some pictures from other models of the same manufacturer, and they did contain a module from Phoenix Contact. After getting the charger it proved out to contain the charge controller form Phoenix Contact module (they sell modules only to OEMs).
Phoenix contact had datasheet for the module available, so soon after electrical installation I started to play around with it.
This is the working config:
modbus:
- name: wallbe
type: tcp
host: 192.168.0.8
port: 502
Additionally one needs some sensors (in my sensor.yaml):
- platform: modbus
scan_interval: 2
registers:
- name: ChargeTime
hub: wallbe
unit_of_measurement: s
slave: 255
register: 102
register_type: input
data_type: int
- name: ChargeCurrent
hub: wallbe
slave: 255
register: 528
register_type: holding
scale: 0.1
data_type: int
unit_of_measurement: A
- name: EVStateDec
hub: wallbe
slave: 255
register: 100
register_type: input
(For understanding EVStateDec charging standard needs to be read, 1 is state A)
And control via scripts.yaml (only the “-service” with address 528 is really needed for current control, 413 is enable (you could leave that always enabled), and about over current more later):
charge_0a:
sequence:
- service: switch.turn_on
entity_id: switch.ChargerOvercurrentDisable
- service: modbus.write_register
data_template:
hub: wallbe
unit: 255
address: 528
value: 0
- service: modbus.write_register
data_template:
hub: wallbe
unit: 255
address: 413
value: 0
- service: switch.turn_on
entity_id: switch.ChargerOvercurrentDisable
charge_6a:
sequence:
- service: switch.turn_off
entity_id: switch.ChargerOvercurrentDisable
- service: modbus.write_register
data_template:
hub: wallbe
unit: 255
address: 528
value: 60
- service: modbus.write_register
data_template:
hub: wallbe
unit: 255
address: 413
value: 1
charge_16a:
sequence:
- service: switch.turn_off
entity_id: switch.ChargerOvercurrentDisable
- service: modbus.write_register
data_template:
hub: wallbe
unit: 255
address: 528
value: 160
- service: modbus.write_register
data_template:
hub: wallbe
unit: 255
address: 413
value: 1
0A charge setting did not work, thus I implemented switch.ChargerOvercurrentDisable. It commands the charger to think that the car is taking more current that is allowed -> it goes to error state. Recovery is simple disable over current setting and set correct current. One problem I had to solve with automation is that if you connect car to charger that is in over current state, the charger state machine goes crazy (running through states constantly). My automation just calls the charge_0a when this happens.
Here is the missing switch.yaml:
- platform: modbus
scan_interval: 2
coils:
- name: ChargerOvercurrentDisable
hub: wallbe
slave: 255
coil: 409
.yaml -files above are included from configuration.yaml, with normal syntax, e.g.:
switch: !include switch.yaml
). SOC is used to start charging at night so that charging is ready at 6:30 (input_datetime). This optimises the charging losses for cabin heating and minimizes the time battery is at full SOC, also electricity is cheaper at night time.
. I can share any pieces you’d be interested in, or send more via pm, but putting it all here would require too much cleaning work…
