I’ve never seen “delayed actions of up to 10 minutes”. Usually, the response is within 30 seconds unless the sensors are temporarily “unavailable” and that is almost always resolved within another 30 seconds resulting in a delay of 60 seconds at most. Sounds as though you have a communication problem somewhere. The Wallbox does have pretty weak WiFi performance, so you need to have an Access Point within a very few metres. I put one in the ceiling of my garage, 2 or 3 metres away.
That is interesting. But as indicated related to UK regulator only (for now). I believe the purpose here is to make sure that not all EVs start charging at the same time (f.i. the moment the low tariff starts), that could bring the network down. Therefore changes in demand are randomly delayed up to 10 minutes.
However, when you are completely off-grid this should not apply. Maybe you can get another s/w version, maybe you can change locale, …
Yes - it makes sense not to load the grid at exactly the same time but still annoying as I need quicker adjustments for my totally off-grid solar system. I wrote to them… lets see.
Hi all,
I use the EV Smart Charging integration (GitHub - jonasbkarlsson/ev_smart_charging: Electric vehicle smart charging for Home Assistant.) with the Wallbox integration.
EV Smart Charging integration controls the pause/resume switch entity, but the entity is not not available until the EV itself is connected. So the EV Smart Charging integration cannot control it when the vehicle is not connected.
See the scheduled windows of charging of the EV Smart Charging integration
So at the moment charging is off and while start somewhere in the night when the price is low
But as soon as I connect my car the the Wallbox, it start charging automatically and the pause/resume entity becomes available with the state resume.
I like to control the Wallbox state, On or Off, without having the car connected to the Wallbox and set it to on at the desired time.
Any help is more than welcome.
Thanks,
Rien
Hi Rien,
The situation you have described can occur in 2 different cases:
- When the vehicle is first plugged in.
- If the charger was previously paused and there is a power failure. When power returns, the charger will start charging even though you don’t want it to (for example if you are waiting for surplus solar power to become available).
To deal with both these cases, I have a switch on my Dashboard captioned ‘Enable Charger’. Every second, I have some code which reads the current charger status and displays it. If I find that the charger is running when it shouldn’t be (if ‘Enable’ switch is OFF), this happens:
var enabled = flow.get('enable_charger');
...
if (msg.payload === "Charging") {
msg.data = "CHARGING"; // make the dashboard display look nicer
if (! enabled) {
flow.set('stop_charger',true)
}
The charger will then ‘Pause’ within a few seconds. The above code is from a Node-RED flow. If you are using HA automations, the same idea can be used. In your case, I suggest using a timer to enable the charger at the appropriate time.
This function was introduced last October in firmware v5.13.9. Surprising we haven’t heard about it until now…
Maybe you can configure your router to block communication with the UK Regulator?
With your system being off-grid I can understand how pointless and annoying this would be 
I don’t think there is communication with the regulator. The change in demand is simply always delayed by a random time if you are in the UK.
Since the last HA update I have this problem, does anyone else have it?
Este error se originó a partir de una integración personalizada.
Logger: custom_components.wallbox
Source: custom_components/wallbox/init.py:131
Integration: Wallbox
First occurred: 14:03:46 (21 occurrences)
Last logged: 14:30:49
Unexpected error fetching wallbox data:
Traceback (most recent call last):
File “/config/custom_components/wallbox/init.py”, line 117, in _get_data
data: dict[str, Any] = self._wallbox.getChargerStatus(self._station)
File “/usr/local/lib/python3.10/site-packages/wallbox/wallbox.py”, line 56, in getChargerStatus
raise (err)
File “/usr/local/lib/python3.10/site-packages/wallbox/wallbox.py”, line 54, in getChargerStatus
response.raise_for_status()
File “/usr/local/lib/python3.10/site-packages/requests/models.py”, line 1021, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 403 Client Error: Forbidden for url: https://api.wall-box.com/chargers/status/7006
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py”, line 258, in _async_refresh
self.data = await self._async_update_data()
File “/config/custom_components/wallbox/init.py”, line 135, in _async_update_data
return await self.hass.async_add_executor_job(self._get_data)
File “/usr/local/lib/python3.10/concurrent/futures/thread.py”, line 58, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/wallbox/init.py”, line 131, in _get_data
raise ConnectionError from wallbox_connection_error
ConnectionError
Forget it, it was my configuration error
1 Like
Dear friends, my wallbox integration installation has stopped working and I can make it work again. I’ve tried reinstalling without luck. I’d appreciate any ideas to try.
Thanks in advance.
I’m wondering how all of you are doing those beautiful dasboard cards. Any pointers on where to start ? I currently only have the Default card 
I have built a charging bot in Node Red using Tibber Pulse (P1) and the regular Wallbox API + calendar entry generated for lowest price hrs (with automation script). It does both smart price charging and/or solar surplus charging (or not). I have 2 chargers (not parallell as I have a small main fuse at 16A and 3-phase and 1-phase charging is needed so would get unbalanced). The benefit is that it’s very simple, and uses standard integrations. It’s not cleaned up yet or optimized but it works like a charm so far
I have completely reconfigured my Wallbox automation. Manually deciding when to connect/enable and switching between green, eco and power modes is simply too complicated (not even talking about needing a phone to do that, or trying to explain this to the family).
So I now have one automation that covers:
- Charge
- Absorb excess solar power
- Overvoltage protection
- Undervoltage protection
For the family I will create three easy to understand physical buttons next to the charger in the garage:
- Now
- Tomorrow
- Whenever
“Now” will immediately start a charge at full power. “Tomorrow” will use the connected car battery to buffer excess solar and provide overvoltage protection, but will start charging at at full power in the evening to be ready for tomorrow. “Whenever” will only use the connected car battery to buffer.
Charge:
Can be enabled from the HA dashboard and is of course enabled with the “Now” and “Tomorrow” buttons. The start time can be set on the HA dashboard, but there is no real reason to change it from the default (21:00). The charge current limit can be set on the HA dashboard, but again there is no real reason to change it from the default (32A).
Absorb excess solar power:
The function is there in case you don’t get enough compensation for power delivered to the mains. I have net metering so I don’t care.
Can be enabled from the HA dashboard. A start time and an end time can be set on the HA dashboard. When active I don’t want to enable/disable the charger for each cloud passing by, so the there is a minimum 6A charge going on. Therefore the time window, set to the time the sun is on the panels. I could imagine automating the timing with the sun rise and sun set times.
Overvoltage protection:
I live in the country side with a crappy network, not ready for the many new solar farms and EV chargers. The mains voltage is all over the place. When the 10 minute average voltage at the solar inverter exceeds 253 Volt the inverter will shut down (as per the EU regulation). On a sunny day, that happens several times a day.
This function will start charging the car when that 253 Volt threshold is approached and stop charging when the voltage drops below another threshold (hysteresis). The trick is to have the neighbors system shut down first and it works like a charm!
Can be enabled from the HA dashboard. The upper threshold and the charge current can be set on the HA dashboard, but there is no real reason to change the default values (enabled, 252.0 Volt, 16A).
Undervoltage protection:
The mains voltage can drop really low (below 190 Volt) in the early evening, this means that electric stoves loose a lot of power.
The undervoltage protection will slow down the EV charging to at least not contribute to the dropping mains voltage. It helps a bit.
Can be enabled from the HA dashboard. The lower threshold can be set on the HA dashboard, but there is no real reason to change the default values (enabled, 200 Volt).
The enabled functions simply run in parallel.
Dashboard under development:
Overvoltage protection in action:
PS
Apologies for the long post.
2 Likes
Sounds great! I’m on a dynamic contract so moved away from the solar based planning but whenever net metering comes at an end your setup sounds great (albeit the grid issues you describe are not an issue in my region)
Will you share the code as well? For inspiration?
The code is still very much work in progress. Here is the automation at the core of this:
alias: EVSE - Automatic charger control
description: >-
Controls the Wallbox charger pause and max current setting up and down (between 6 and 32
A)
trigger:
- platform: time_pattern
seconds: /12
condition:
- condition: or
conditions:
- condition: state
entity_id: sensor.wallbox_portal_status_description
state: Paused
- condition: state
entity_id: sensor.wallbox_portal_status_description
state: Charging
action:
- service: input_number.set_value
data:
value: "0"
target:
entity_id: input_number.charger_current_limit
- if:
- condition: state
state: "on"
entity_id: input_boolean.charger_overvoltage_protection_enabled
then:
- choose:
- conditions:
- condition: numeric_state
entity_id: sensor.sma_voltage_moving_average
above: input_number.charger_overvoltage_protection_threshold
sequence:
- service: input_number.set_value
data:
value: >-
{{
states('input_number.charger_overvoltage_protection_current')
| float(0) | round(0) }}
target:
entity_id: input_number.charger_overvoltage_protection_setpoint
- service: input_boolean.turn_on
data: {}
target:
entity_id: input_boolean.charger_overvoltage_protection_active
- conditions:
- condition: numeric_state
entity_id: sensor.sma_voltage_moving_average
below: "250"
sequence:
- service: input_number.set_value
data:
value: "0"
target:
entity_id: input_number.charger_overvoltage_protection_setpoint
- service: input_boolean.turn_off
data: {}
target:
entity_id: input_boolean.charger_overvoltage_protection_active
- service: input_number.set_value
data:
value: >-
{{ states('input_number.charger_overvoltage_protection_setpoint') |
float(0) | round(0) }}
target:
entity_id: input_number.charger_current_limit
- if:
- condition: state
state: "on"
entity_id: input_boolean.charger_excess_solar_absorption_enabled
- condition: time
after: input_datetime.charger_excess_solar_absorption_start_time
before: input_datetime.charger_excess_solar_absorption_end_time
then:
- choose:
- conditions:
- condition: numeric_state
entity_id: sensor.actual_power
below: "-250"
sequence:
- service: input_number.set_value
data:
value: >-
{{ [((states('number.wallbox_portal_max_charging_current') |
float(0) + 1.0) | round(0)), 32] | min }}
target:
entity_id: input_number.charger_excess_solar_setpoint
- conditions:
- condition: numeric_state
entity_id: sensor.actual_power
above: "250"
sequence:
- service: input_number.set_value
data:
value: >-
{{ [((states('number.wallbox_portal_max_charging_current') |
float(0) - 1.0) | round(0)), 6] | max }}
target:
entity_id: input_number.charger_excess_solar_setpoint
- service: input_number.set_value
data:
value: >-
{{ [(states('input_number.charger_current_limit') | float(0) |
round(0)), (states('input_number.charger_excess_solar_setpoint') |
float(0) | round(0))] | max }}
target:
entity_id: input_number.charger_current_limit
- service: input_boolean.turn_on
data: {}
target:
entity_id: input_boolean.charger_excess_solar_absorption_active
else:
- service: input_boolean.turn_off
data: {}
target:
entity_id: input_boolean.charger_excess_solar_absorption_active
- if:
- condition: state
entity_id: input_boolean.charger_scheduled_charge_enabled
state: "on"
- condition: or
conditions:
- condition: time
after: input_datetime.charger_scheduled_charge_start_time
- condition: time
before: "06:00:00"
then:
- service: input_number.set_value
data:
value: >-
{{ [(states('input_number.charger_current_limit') | float(0) |
round(0)), (states('input_number.charger_scheduled_charge_setpoint')
| float(0) | round(0))] | max }}
target:
entity_id: input_number.charger_current_limit
- service: input_boolean.turn_on
data: {}
target:
entity_id: input_boolean.charger_scheduled_charge_active
else:
- service: input_boolean.turn_off
data: {}
target:
entity_id: input_boolean.charger_scheduled_charge_active
- if:
- condition: state
state: "on"
entity_id: input_boolean.charger_undervoltage_protection_enabled
then:
- choose:
- conditions:
- condition: numeric_state
entity_id: sensor.mains_voltage
below: input_number.charger_undervoltage_protection_threshold
sequence:
- service: input_number.set_value
data:
value: >-
{{
[((states('input_number.charger_undervoltage_protection_setpoint')
| float(0) - 1.0) | round(0)), 6] | max }}
target:
entity_id: input_number.charger_undervoltage_protection_setpoint
- conditions:
- condition: numeric_state
entity_id: sensor.mains_voltage
above: "220"
sequence:
- service: input_number.set_value
data:
value: >-
{{
[((states('input_number.charger_undervoltage_protection_setpoint')
| float(0) + 1.0) | round(0)), 32] | min }}
target:
entity_id: input_number.charger_undervoltage_protection_setpoint
- service: input_number.set_value
data:
value: >-
{{ [(states('input_number.charger_current_limit') | float(0) |
round(0)),
(states('input_number.charger_undervoltage_protection_setpoint') |
float(0) | round(0))] | min }}
target:
entity_id: input_number.charger_current_limit
- choose:
- conditions:
- condition: numeric_state
entity_id: input_number.charger_current_limit
above: "1"
sequence:
- service: number.set_value
data:
value: >-
{{ states('input_number.charger_current_limit') | float(0) |
round(0) }}
target:
entity_id: number.wallbox_portal_max_charging_current
- service: switch.turn_on
data: {}
target:
entity_id: switch.wallbox_portal_pause_resume
- conditions:
- condition: numeric_state
entity_id: input_number.charger_current_limit
below: "1"
sequence:
- service: number.set_value
data:
value: "6"
target:
entity_id: number.wallbox_portal_max_charging_current
- service: switch.turn_off
data: {}
target:
entity_id: switch.wallbox_portal_pause_resume
mode: single
Here is the overvoltage protection function visible.
Showing the solar power output for three successive days. Friday the overvoltage issue clearly showed, 5 times the inverter shut down (went zero output, the other dips are clouds). On Saturday one shutdown, then I manually started charging of a car, no more shutdowns. Today with the overvoltage protection working (it activated 7 times) no shut downs.
I published Json on below link, note that I have created helper’s and virtual switches to set charge mode. It’s a bit un optimized but does the job. I also have a auto generated calendar entry for when it’s cheep to charge (a virtual switch turn on when is time and turn off when it’s not).
Json: Loading bot - JustPaste.it