The issue does only occur if you have a Wifi connection, when I use BT the value gets updated all the time.
I filled a bug at Wallbox, let’s see what happens.
My guess is that they will blame it on your WiFi connection …
I have made a fix (for status) for the ootb version of the integration, probably available in the next release. The lock function is now also available in the builtin version, Will work on the pause function in the coming time.
1 Like
Regarding the charging power disappearing, I dont have it at all, I think your car needs support for it as well to show up. Did have some WiFi issues early on, but I am using a cable now (wallbox copper sb).
The charging power is available for the first couple of minutes of charging and returns to zero and stays that way till the end. When I pause and resume, again a couple of minutes charging power is filled but went back to zero again.
All,
I just updated the ‘custom version’ repo. Basically its now the exact same code as OOTB (including status fix) but with the pause/resume added. Please let me know how the switch works, and if you encounter issues → that way we can improve it for the release in the OOTB version!
Don’t think it relates to the car, because it used to work fine on the Polestar 2 and on the Fiat 500e, now it does not work on either.
Maybe it is somehow WiFi related. I have had connection problems when the access point in the garage was 2.7 MHz only. I have since updated the AP to 5 GHz and the problems went away until the missing power started playing up. The Wallbox app tells me it has full signal WiFi strength, which is to be expected it sits 2.5 m line of site away from the AP.
@RienduPre , let’s find out what our setups have in common?
Once more really appreciate your efforts on helping the community. I have updated the costum_component with your latest code (since I lost the swtich), but unfortunately, the status of the button doesn’t update. Meaning, it starts the charging (if the car is waiting to be charged and in paused mode), but in HA, the button doesn’t reflect it.
HA:
Mywallbox:
As well, state of charging states always Unknown and Current Mode is always 1.
Debugging logs, when you try to operate the switch:
Logger: homeassistant.components.websocket_api.http.connection
Source: custom_components/wallbox/init.py:182
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 4:31:57 PM (1 occurrences)
Last logged: 4:31:57 PM
[3813712152]
Traceback (most recent call last): File “/config/custom_components/wallbox/init.py”, line 179, in _pause_charger self._wallbox.resumeChargingSession(self._station) File “/usr/local/lib/python3.9/site-packages/wallbox/wallbox.py”, line 116, in resumeChargingSession raise (err) File “/usr/local/lib/python3.9/site-packages/wallbox/wallbox.py”, line 114, in resumeChargingSession response.raise_for_status() File “/usr/local/lib/python3.9/site-packages/requests/models.py”, line 960, 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/v3/chargers/135294/remote-action The above exception was the direct cause of the following exception: Traceback (most recent call last): File “/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py”, line 191, in handle_call_service await hass.services.async_call( File “/usr/src/homeassistant/homeassistant/core.py”, line 1633, in async_call task.result() File “/usr/src/homeassistant/homeassistant/core.py”, line 1670, in _execute_service await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)( File “/usr/src/homeassistant/homeassistant/helpers/entity_component.py”, line 204, in handle_service await self.hass.helpers.service.entity_service_call( File “/usr/src/homeassistant/homeassistant/helpers/service.py”, line 668, in entity_service_call future.result() # pop exception if have File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 930, in async_request_call await coro File “/usr/src/homeassistant/homeassistant/helpers/service.py”, line 705, in _handle_entity_call await result File “/config/custom_components/wallbox/switch.py”, line 83, in async_turn_on await self.coordinator.async_pause_charger(False) File “/config/custom_components/wallbox/init.py”, line 187, in async_pause_charger await self.hass.async_add_executor_job(self._pause_charger, pause) File “/usr/local/lib/python3.9/concurrent/futures/thread.py”, line 58, in run result = self.fn(*self.args, **self.kwargs) File “/config/custom_components/wallbox/init.py”, line 182, in _pause_charger raise InvalidAuth from wallbox_connection_error custom_components.wallbox.InvalidAuth
OK, what are the status descriptions you get in HA? The switch should be available when the status is either paused, or charging. The http error is strange, it seems the user is unauthorized, I need to look into that.
I might understand your first remark better now, if the charger is paused, the switch is on. Off is ‘not paused’
Yeah, the swtich aviability seems to be OK. For instance, right now the Status Description states, “Waiting for car demand” and indeed the swtich is not available, that seems to be consistent with mywallbox UI experience:
But 1hour ago, when was charging, the following was happening (let me try to describe it by bullet points for better understanding):
- Car is charching and switch is available ON HA : OK;
- mywallbox UI gives be a “Pause” button to allow me to pause the charging process : OK;
- On HA UI, the switch should be “ON” and keeps “OFF”.
- If I toggle it once, it keeps “ON” and the UI on mywall is updated;
- Returning to the mywallbox UI, if I toggle it to pause;
- On HA, the swtich keeps “ON” altough my expections is to see the switch returning back to “OFF”
My assumption, is that due an authenticatoin error (line 960 described above), the code is not able to retrieve correctly the status\or resume the operation of charging. Happy to help you on the debugging if needed.
I think there was some reverse logic there… I created an update can you try this new version?
This is the the commit right ?
Testing this one, seems to resolve the switch state well done 
I would just recommend to add other state as well “Scheduled”. Most part of us, have schedules on this wallbox’s and you may jump in a situation that you want to force the charging outside your scheduled - makes sense ? Meaning, I want to be able to resume\start charging when the state is “Scheduled”, so the switch needs to be available on this situation as well. Did some changes and it’s working great.
Other question I have, it may help have a better control over the charging process via node-red since it’s a numeric value, the Current Mode is always 1, I don’t find much information about the Wallbox API, do you know if this state changes ? Of course we can control using the Status, but once more using a numeric fielf would be easier.
Thank you!
I can add ‘scheduled’ to the code, that way the switch is available when scheduled. I don’t know whether the API Will accept the commando hoever, but we can try… Regarding your 2nd question, there is also a status ID, might that work for your purposes? I could include that…
Cool, that would be great. It does accept, on my tests yesterday I was able to start a charging process when the status was “Scheduled” and if we think, it wouldn’t make sense to reject it. I should be allowed to charge the car when I want. Around the status ID would be awesome. If you could add that and a short description of which one of them would be amazing helpful.
Veric Nice job on that Wallbox !
For info we began to do the same job on the cheap BESEN/MOREC B20 wallbox … starting to do reverse engineering on the Wallbox protocol https://community.home-assistant.io/t/besen-b20-evse/405737
Last off topic message for me 
1 Like
@hesselonline Just a quick shoutout, I had my first EV delivered a month ago, they took a few weeks to install the wallbox, and I was watching this thread and had tried the custom components, but the state description was broken by then.
Just ran up the new custom compnents version and it is working perfectly! Pause and Resume was a must in my use case, as I have Nodered polling the solar at home and adjusting the amps accordingly, so my charging stays within my free solar generation. Now I can stop entirely when lots of clouds come over and it kicks off again on it’s own.
Thanks again
3 Likes
Wallbox has accepted the charging power over Wifi disapearing as a bug and will be solving this in a future firmware release. This is a start, but I got no indication when we can expect an update.
Keep you posted.
2 Likes
That is good news. Well done! I only got about 10 very nice and very useless e-mails. Now I can stop looking for the problem here. Thx.
I added scheduled to the code just now.
1 Like