Webasto (now Ampure) Unite Wallbox Modbus Integration

Share your Projects!
3

No, OCPP must not been activated and does not influence our Modbus integration.

As discribed above, there is only one sensor controlling the Wallbox - see below.
To get this working, you also need to activated Modbus as shown above in your Carger Web-UI (but haven´t this tested this with a Vestel Box).

Sensor:

- name: Webasto_Unite_Charging_Current
      # R/W: 0-5A=Charging paused, 6-32A=Charging with set Amps
        unique_id: Webasto_Unite_Charging_Current
        slave: 255
        input_type: holding
        address: 5004
        data_type: uint16
        device_class: current
        state_class: measurement
        unit_of_measurement: A
      # Dynamic charging current

There is hardware wise no way for dynamic Phase Switching (1 Phase ↔ 3 Phase), as those chargers have only an internal 3-phase relay and not two separted 1-Phase/2-Phase relais.

1 Like
4

@lemuba Maybe you should also add the modbus specification file to this thread, so people can read the meaning of each register.
It is not officially published on the Ampure site. And I have seen a version from the Vestel EVC04 which is similar…

5

The official File does not provide any additional relevant info/descriptions as noted in my first post and code.

6

@lemuba I have found three (3) different modbus specifications: Vestel EVC04, Webasto Live & Webasto Next. All are generally the same, but have some differences. On my Webasto Unite I have tried to investigate which registers are supported.
But of course that’s only what I can determine in my setup.
So beware that is nu definite source of truth about this interface (available on the open internet).

Which leads to some specific questions about:

  • User priority (responds, but does not seems to contain information)
  • EV Battery state / SoC (responds, but does not seems to contain information)\
  • EV Battery capacity (responds, but does not seems to contain information)
  • EV required energy (responds, but does not seems to contain information)
  • Required battery state(responds, but does not seems to contain information)
  • Charged Energy (responds, but does not seems to contain information)
    Some of these can be explained, because the Unite does not know anything about de battery in de EV (the used protocols do not communicate this information). Others could have worked or may do in some setups.

So beware that these registers might not behave like expected.

7

Hello, please I have problem with webasto next chargeing and evcc, if I connect car, and dont have freeCharging enabled, it will not started charging, is there any way how to evcc or HA start charging with indetifier regarding vehicle?
Thank you in advance
Jozef

8

@joztoz I have no experience with EVCC. I think you can not use both EVCC and HA at the same time.
But it looks like your problem has to do with the wallbox itself.

You describe that freecharging works. In this mode you do not need to authorize the charging session. If freecharging is not enabled, you need to authorize the session.
You do this by holding the RFID card close to the wallbox. The RFID that is read by the wallbox needs to be recognized by the ‘backend’. Question is: which backend do you use?

EVCC is not a backend. It is a ‘local’ controller which uses the modbus TCP interface of the Webasto. Using this interface you can not do authorization. Also using HA using the modbus TCP interface will not do authorization. Neither is the ‘backend’.

By default the backend for the Websto Next is Webasto ChargeConnect App (or actually CPMS) which uses the OCPP interface. This is the interface that has the freecharging option. So assume this is the backend that you use right now.

This backend needs to do the authorization. So this backend must know the RFID card that you use. You can ‘add’ teh RFID card to the backend from the Webasto ChargeConnect app and/or in the CPMS website.

There is an alternative where you do not use a backend. That is called ‘Standalone mode’. If you use this mode, you can ‘store’ the allowed RFID cards in the wallbox itself.

There is much more you need to know to fully understand all (im)possibilities of RFID authorization. They have nothing to do with HA. The main thing to learn from this,is: your problem is not with HA but with configuring authorization in the Websasto Next.

9

Hey @lemuba, wanted to thank you for your work here so far. I’m very new to HA and have just gotten the register data from my inverter into HA (not easy… Don’t buy Sungrow if you’re wanting to use HA!)

As it happens, I have a Webasto Next Wallbox, and as the energy manager my PV system came with is so unreliable, I want to replace it with HA to regulate current based on how much energy is being generated by the system / battery state. Have you got your Next Wallbox yet? Any updates to share if so?

Thanks again so much for your work, it’s a fantastic starting point for me :+1:

10

Using the Unite wallbox, I have now created an automated charging system that optimizes for the lowest price of electricity using a dynamic pricing contract.

See: EV Smart charging with dynamic energy prices in the EU

Hopefully this may inspire others to do the same. If you have any questions about that, post them in that topic. I’ll try to help you is I can over there.

11

I finally managed to get the modbus readouts correctly from a Webasto Next with the above settings for Unite on firmware v3.1.16 - Many thanks for the work of @lemuba - highly appreciated.

Nevertheless I have a small problem with the current slider - the keepalive button works so far.

modbus.yaml is set up like @lemuba described. Nevertheless HA still drops me an error if I try to implement the value slider. When checking configuration in the developer section of HA it gives me:

Integration error: webasto_unite_charging_current_value_slider - Integration 'webasto_unite_charging_current_value_slider' not found.

I put the following code to configuration.yaml

automation.yaml includes the following code:

Loxone (which I´m not using!) has a documentation to the modbus protocol of NEXT linked:

So address 5004 is the same with NEXT as it is in UNITE and also has the “Charge Current” writable.

What do I oversee here?

12

@KlausTrophie : can you post what messages you see in the homeassistant.log (menu Settings / System / Logs)?

13

Hi @BrainDra1n (Ceceile). Thanks for your help. Highliy appreciated.

For Context: I have replaced all occurrences of “Webasto_Unite” with “Webasto_Next” in all Scripts.

Hmm…

Logger: homeassistant.components.modbus.modbus
Quelle: components/modbus/modbus.py:331
Integration: Modbus (Dokumentation, Probleme)
Erstmals aufgetreten: 4. August 2024 um 11:36:29 (73492 Vorkommnisse)
Zuletzt protokolliert: 16:17:03

  • Pymodbus: Webasto_Next: Error: device: 255 address: 1014 → pymodbus returned isError True
  • Pymodbus: Webasto_Next: Error: device: 255 address: 1502 → pymodbus returned isError True
  • Pymodbus: Webasto_Next: Error: device: 255 address: 5004 → pymodbus returned isError True
  • Pymodbus: Webasto_Next: Error: device: 255 address: 100 → pymodbus returned isError True
  • Pymodbus: Webasto_Next: Error: device: 255 address: 100 → Modbus Error: [Input/Output] ERROR: No response received after 3 retries

Logger: homeassistant.util.yaml.loader
Quelle: util/yaml/loader.py:474
Erstmals aufgetreten: 4. August 2024 um 11:45:02 (150 Vorkommnisse)
Zuletzt protokolliert: 16:16:21

  • YAML file /config/automations.yaml contains duplicate key “description”. Check lines 1 and 14
  • YAML file /config/automations.yaml contains duplicate key “trigger”. Check lines 2 and 15
  • YAML file /config/automations.yaml contains duplicate key “condition”. Check lines 5 and 19
  • YAML file /config/automations.yaml contains duplicate key “action”. Check lines 6 and 20
  • YAML file /config/automations.yaml contains duplicate key “mode”. Check lines 11 and 28

On Fresh Bootup also:

2024-08-07 16:25:38.094 WARNING (MainThread) [homeassistant.helpers.translation] Failed to load integration for translation: Integration ‘webasto_next_charging_current_value_slider’ not found.

2024-08-07 16:25:39.928 ERROR (MainThread) [homeassistant.setup] Setup failed for ‘webasto_next_charging_current_value_slider’: Integration not found.

I´m a bit lost and a 100% newbie on HA… Using a Portainer-Version… Hope this helps. Thanks for your time!

14

I think there must be more than problem.

The modbus error messages seems random. The addresses are all OK. So something else must be happening. These messages do not contain a timestamp. So it is difficult to see if there an interval between them (or something like that).
My guess would be that there is a communication timeout between HA and Next. Maybe the keepalive is not updated frequently enough. Check that value in holding register 2002 is larger that the interval used to reset the keepalive in holding register 6000. The interval is determined by your automation ‘Webasto Unite Keep Alive’.

The YAML errors I can not explain. Looks like a duplicate definition in the automations.yaml file.

The message ‘integration not found’ seems weird to me. The ‘webasto_next_charging_current_value_slider’ is not an integration, but an entity created from a helper. Maybe someone else can shine a light on this.

1 Like
15

Others seems to have an issue with ‘Failed to load integration for translation’ as well. So it might not be specific to you:

16

modbus.yaml:

- name: Webasto_Next_Failsafe_Timeout
      # R/W: No need to change (Standard: 20 seconds)
        unique_id: Webasto_Next_Failsafe_Timeout
        slave: 255
        input_type: holding
        address: 2002
        data_type: uint16

automation.yaml

description: Webasto Next Keep Alive
trigger:
  - platform: time_pattern
    seconds: /5
condition: []
action:
  - service: switch.turn_on
    data: {}
    target:
      entity_id: switch.Webasto_Next_Alive_Register
mode: single

alias: Set Webasto Next Charging Current Limit
description: Set Webasto Next Charging Current Limit
trigger:
  - platform: state
    entity_id:
      - input_number.webasto_next_charging_current_value_slider
condition: []
action:
  - service: modbus.write_register
    data:
      hub: Webasto_Next
      address: 5004
      slave: 255
      value:
        - "{{ (states.input_number.webasto_next_charging_current_value_slider.s>
mode: single

I haven´t changed anything from the original scripts ^ from @lemuba
I could try to set another timing of 4 seconds / 3 seconds to see if it changes anything.

As you see in automation.yaml there are no duplicate entries. There are 2 aliases - Or could it be that I have to split these and put the code starting with the second “alias:” into a separate file ?

17

Ok. I finally managed to get the Webasto NEXT to run without errors.
I deleted all queries from the modbus script of @lemuba that lead to errors. I also deleted the slider in the config as it seems to drop errors as @BrainDra1n mentioned.

So now it looks like this:

image
image477×1097 53.6 KB

As I´m on the most recent firmware it seems that the NEXT is not hibernating and the keepalive function has also been deleted from the scripts.

So now my only point is to bring back the slider to set the output Ampere via modbus Port 5004. By the way this port is only writable and not readable refering to the doc found over at the evcc project. The upper script from @lemuba tried to read and display it also - so I got rid of this.

My now working config without any errors in the logs looks like this:

configuration.yaml:

# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
modbus: !include modbus.yaml

modbus.yaml:

# Protocol requirements
# The Webasto Next charging station acts as a slave device in Modbus TCP/IP communication.
# Charging station should be in the same network with the master device, or proper routing should be applied to provide communication between slave and master devices in different sub networks.
# Each charging station should have a different IP address. There can only be one active Modbus master connection at any time.
# Parameter Modbus TCP
# Each Wallbox Next must be given a unique IP.
# Parameter                     Value 
# IP-address:                   Any IP address; All Webasto Next on the same subnet (e.g., xxx.xxx.xxx.xxx)
# Modbus Port:                  502
# Modbus Unit ID:               255
 
  - name: Webasto_Next
    type: tcp
    timeout: 5
    host: 192.168.2.123
    port: 502
    sensors:
      - name: Webasto_Next_Charge_Point_State
# 0: "Available",
# 1: "Preparing",
# 2: "Charging",
# 3: "SuspendedEVSE",
# 4: "SuspendedEV",
# 5: "Finishing",
# 6: "Reserved",
# 7: "Unavailable",
# 8: "Faulted",
        unique_id: Webasto_Next_Charge_Point_State
        slave: 255
        input_type: input
        address: 1000
        data_type: uint16
        
      - name: Webasto_Next_Charging_State
# 0: Not Charging, State Ax, Bx, Dx or C1 1: Charging, state C2      
        unique_id: Webasto_Next_Charging_State
        slave: 255
        input_type: input
        address: 1001
        data_type: uint16
        
      - name: Webasto_Next_Equipment_State
# 0: Initializing
# 1: Running
# 2: Fault
# 3: Disabled
# 4: Updating      
        unique_id: Webasto_Next_Equipment_State
        slave: 255
        input_type: input
        address: 1002
        data_type: uint16

      - name: Webasto_Next_Cable_State
# 0: Cable not connected 1: Cable connected, vehicle not connected 2: Cable connected, vehicle connected 3: Cable connected, vehicle connected, cable locked
        unique_id: Webasto_Cable_State
        slave: 255
        input_type: input
        address: 1004
        data_type: uint16
        
      - name: Webasto_Next_EVSE_Fault_Code
# 0: No fault
# Other: Fault code      
        unique_id: Webasto_Next_EVSE_Fault_Code
        slave: 255
        input_type: input
        address: 1006
        data_type: uint16
        
      - name: Webasto_Next_Charging_Current_L1
        unique_id: Webasto_Next_Charging_Current_L1
        slave: 255
        input_type: input
        address: 1008
        data_type: uint16
        device_class: current
        offset: 0
        scale: 0.001
        precision: 0
        state_class: measurement
        unit_of_measurement: A

      - name: Webasto_Next_Charging_Current_L2
        unique_id: Webasto_Next_Charging_Current_L2
        slave: 255
        input_type: input
        address: 1010
        data_type: uint16
        device_class: current
        offset: 0
        scale: 0.001
        precision: 0
        state_class: measurement
        unit_of_measurement: A

      - name: Webasto_Next_Charging_Current_L3
        unique_id: Webasto_Next_Charging_Current_L3
        slave: 255
        input_type: input
        address: 1012
        data_type: uint16
        device_class: current
        offset: 0
        scale: 0.001
        precision: 0
        state_class: measurement
        unit_of_measurement: A
        
      - name: Webasto_Next_Active_Power_Total
        unique_id: Webasto_Next_Active_Power_Total
        slave: 255
        input_type: input
        address: 1020
        data_type: uint32
        device_class: power
        state_class: measurement
        unit_of_measurement: W
        
      - name: Webasto_Next_Active_Power_L1
        unique_id: Webasto_Next_Active_Power_L1
        slave: 255
        input_type: input
        address: 1024
        data_type: uint32
        device_class: power
        state_class: measurement
        unit_of_measurement: W
        
      - name: Webasto_Next_Active_Power_L2
        unique_id: Webasto_Next_Active_Power_L2
        slave: 255
        input_type: input
        address: 1028
        data_type: uint32
        device_class: power
        state_class: measurement
        unit_of_measurement: W
        
      - name: Webasto_Next_Active_Power_L3
        unique_id: Webasto_Next_Active_Power_L3
        slave: 255
        input_type: input
        address: 1032
        data_type: uint32
        device_class: power
        state_class: measurement
        unit_of_measurement: W

      - name: Webasto_Next_Meter_Reading
        unique_id: Webasto_Next_Meter_Reading
        slave: 255
        input_type: input
        address: 1036
        data_type: uint32
        device_class: energy
        state_class: total_increasing
        offset: 0
        scale: 0.001
        precision: 3
        unit_of_measurement: kWh

      - name: Webasto_Next_Session_Max_Current
        unique_id: Webasto_Next_Session_Max_Current
        slave: 255
        input_type: input
        address: 1100
        data_type: uint16
        device_class: current
        state_class: measurement
        unit_of_measurement: A

      - name: Webasto_Next_EVSE_Min_Current
        unique_id: Webasto_Next_EVSE_Min_Current
        slave: 255
        input_type: input
        address: 1102
        data_type: uint16
        device_class: current
        state_class: measurement
        unit_of_measurement: A

      - name: Webasto_Next_EVSE_Max_Current
        unique_id: Webasto_Next_EVSE_Max_Current
        slave: 255
        input_type: input
        address: 1104
        data_type: uint16
        device_class: current
        state_class: measurement
        unit_of_measurement: A

      - name: Webasto_Next_Cable_Max_Current
        unique_id: Webasto_Next_Cable_Max_Current
        slave: 255
        input_type: input
        address: 1106
        data_type: uint16
        device_class: current
        state_class: measurement
        unit_of_measurement: A

      - name: Webasto_Next_Session_Start_Time
        unique_id: Webasto_Next_Session_Start_Time
        slave: 255
        input_type: input
        address: 1504
        data_type: uint32

      - name: Webasto_Next_Session_Duration
        unique_id: Webasto_Next_Session_Duration
        slave: 255
        input_type: input
        address: 1508
        data_type: uint32
        device_class: duration
        state_class: measurement
        unit_of_measurement: s

      - name: Webasto_Next_Session_End_Time
        unique_id: Webasto_Next_Session_End_Time
        slave: 255
        input_type: input
        address: 1512
        data_type: uint32
        
      - name: Webasto_Next_Failsafe_Current
      # R/W: Can be set in the Next WebUI (Standard:6A)
      # Charging power will fall back to 6A, if ALive Register 6000 not triggered with 1 within each 20 seconds 
        unique_id: Webasto_Next_Failsafe_Current
        slave: 255
        input_type: holding
        address: 2000
        data_type: uint16
        device_class: current
        state_class: measurement
        unit_of_measurement: A
      # Failsafe charging current during communication failure

      - name: Webasto_Next_Failsafe_Timeout
      # R/W: No need to change (Standard: 20 seconds)
        unique_id: Webasto_Next_Failsafe_Timeout
        slave: 255
        input_type: holding
        address: 2002
        data_type: uint16
      # Communication timeout for switching to Failsafe charging current. If the timeout has occurred and the TCP socket is still active, TCP socket restarts. If set, Failsafe period is timeout/2, otherwise 20 sec.

automations.yaml:

alias: Set Webasto Next Current Limit
description: Set Webasto Next Current Limit
trigger:
  - platform: state
    entity_id:
      - input_number.webasto_next_current_value_slider
condition: []
action:
  - service: modbus.write_register
    data:
      hub: Webasto_Next
      address: 5004
      slave: 255
      value:
        - "{{ (states.input_number.webasto_next_current_value_slider.state) }}"
mode: single

My next 2do is to reimplement the slider to fully support dynamic loadings controlled by my. Any idea how I could do this ? Any help is highly appreciated :wink: Thx!

18

I tried to put this back to configuration.yaml - immediately receive the error:

image
image1010×63 5.79 KB

Code added to configuration.yaml:

webasto_next_current_value_slider:
    name: webasto_next_current_value_slider
    initial: 16
    min: 5
    max: 32
    step: 1
19

The strange thing about the ‘integration <> not found’ message is, that the slider is not an integration. It is just a entity.

Maybe this a syntax thing, I’m not sure. You state that you have added the slider definition in configuration.yaml. I only know entries in configuration.yaml that start with a defined keyword, like: automation, script, modbus, etc. These keywords are all ‘integrations’ according to the documentation. E.g. Modbus - Home Assistant (home-assistant.io).
If so, the declaration starting with ‘webasto_next_current_value_slider:’ is interpreted as the keyword for an integration. This should then be prefixed with Number - Home Assistant (home-assistant.io), like:

number:
  webasto_next_current_value_slider:
    name: webasto_next_current_value_slider
    initial: 16
    min: 5
    max: 32
    step: 1

The way I created the slider is different. I used the user interface to create it.
Menu Settings / Devices &service / Helpers; Create Helper select Number.
This creates an entity of Type number. Placing this entity on a dashboard creates the possibility to modify its value. Then created the automation, again through the user interface that triggers on a state change of the ‘Number’ entity.

The result should not be different that what you did. But maybe try this, using a different name for the entity. Just to see if this does work.

20

@KlausTrophie Were you able to solve it? What did work for you?

21

Thank you so much for your code and explanation. I am a newbie to HA and I managed to set everything up as you do here. So I can read the entities from my wallboy and enable automation for the current value slider .

but my question is, now how do I effectively set the charging amperage through HA programming.

thanks in advance Walter Dekson

22

@walter.annaert : As shown in the initial post by @lemuba you need two things:

a) A slider to input the desired charge current (which you now have)
b) An automation that triggers on the slider (changes) and sends a command to the wallbox (see the post).

But maybe your question is: how do I automatically start / stop charging?
For this there are multiple integrations. The one that I use is EV Smart Charging which is available under HACS. It uses ‘dynamic pricing’ to find the moment of lowest electricity prices to charge the EV.

If you want to see how I used this, look at the post EV Smart charging with dynamic energy prices in the EU - Energy - Home Assistant Community

There are also Integrations that work with solor panels and home batteries. I have no experience with those.