OK, that makes sense. At least you are seeing the correct reading for a decent amount of time. By comparison, look at my chart from Pulsar Plus. There were 2 charging sessions - last night from 9pm to 11pm and again this morning from 6:30am to 8am, all at 16 Amps, so the power level should be constant at that level, but instead, it stays at zero most of the time…
Now, here is the chart from Shelly EM. The small steps are where underfloor heating switched on and off…
Many thanks for all the work on this integration - I works like a charm. One question though - I use the eco-smart settings on the wallbox; however, if the battery is below a certain percentage (eg. <50%) I would like to “force” a charging session. Idea is to create an automation which triggers at 23.30 (to benefit from off peak conditions) and is conditional on the battery level; right now though this doesn’t work on account of the eco-smart settings.
According to the wallbox website their app however allows a forced override through either 1) a scheduled charge and 2) a manual start.
Would it be possible to achieve the same in this integration? Either through disabling eco smart through a service call (although this seems only possible over a BT connection?) or through enabling the pause/resume button when the status of the charger is waiting for green energy?
I was intending to use Eco-Smart at the beginning, so I ordered the Carlo Gavazzi energy meter, hooked it up to RS485 but for various reasons it didn’t work out. So I know what you are dealing with regarding the ‘Upgrades’ menu of the app.
As you say, a manual start will override the Eco-Smart setting, whereas Eco-Smart being enabled will override any schedules that are set. So I don’t think you need to worry about disabling Eco-Smart for your idea to work. You just need an automation in HA which triggers at the appropriate time, checks for the status indicating the charger is waiting for green energy, and if so, does a manual start.
How are you intending to check for SoC < 50%?
Perhaps you aren’t aware yet, but that function of this integration doesn’t work. AC charging doesn’t allow for SoC to be detected by the charger. It only works with DC Fast Charging. Another way of detecting SoH is via OVMS, if your EV supports that. Personally, I find it easier to jump in the car and flick the On switch to see what SoC it has.
I don’t know how much experience you have with HA Automations. I found the setup process very limited and difficult to debug. So I’ve been using Node-RED for my charger dashboard and found it does everything I need and much more. I have a simplified charging timer working and I’ve found it more reliable than the schedules in the Wallbox App. On several occasions, charging failed to stop as scheduled, whereas my timer has always worked so far.
Thanks for your suggestions/ideas! my car (enyaq) has an API which reports the battery state. This I use to check the status. There are some other helpful possibilities to steer the charging process.
Although I have net metering I want to use as much solar during the day to avoid burdening the grid (and possibly switch off of my invertors). To achieve this the intended setup is as follows:
The above part works already with ha automations. I want to add some rules which force a charge if SoC<50 - conditional on off peak tarriff.
Your “waiting on energy” suggestion is very helpful but when you say:
“(…) checks for the status indicating the charger is waiting for green energy, and if so, does a manual start.”
How do I initiate a manual start with the integration? If there is no pause/resume toggle activated (it shows up as “unavailable” when the charger is waiting for green energy) I would not know how/which entity to activate.
"How do I initiate a manual start with the integration? If there is no pause/resume toggle activated (it shows up as “unavailable” when the charger is waiting for green energy) I would not know how/which entity to activate."
Yes, very good point. Because I don’t have Eco-Smart I haven’t seen what happens under those conditions. But come to think of it, I did notice that the Pause/Resume control was unavailable when the status was ‘Waiting for EV demand’ (battery full). So I guess it’s a similar situation.
You could have a look through the Python source code for this integration and see if there’s anything you can modify to change this behaviour. Or you may find the relevant code in the underlying Wallbox repo maintained by Cliviu74.
Congrats on your ownership of a Skoda Enyaq. It’s great that they provide an API for access to the status of your vehicle. I would need to have an OBD2 dongle permanently plugged in to my Nissan Leaf to get that, which is something I’d rather avoid.
Hi. Just discovered Home Assistant last weekend 
It looks great!
But I am having trouble getting my WallBox Pulsar Plus connected. The WallBox itself is on latest firmware, and close to an AP. I can access it on wifi from my phone, etc.
I tried the ‘official’ WallBox integration - it recognized ‘Wallbox Portal Max Available Power’ (Non-default 25A - so there was some connection happening), but I could not do anything.
I removed that and used HACS to install WallBox from GitHub - hesselonline/wallbox But doing this I was never asked for a serial number, username or password. I removed that and then tried manually copying the ‘wallbox’ folder into custom_components folder (directory structure, etc looks correct). Nothing appears in settings, integrations…
So back to the official integration… For example, when I try changing the ‘WallBox Portal Max Charging Current’ I get this error:
Any ideas? I am happy to try copying the git repo wallbox folder again - but how do I start the configuration process?
Thank you!
Welcome Andrew. I wonder if during the process of trying so many integrations, things have become messed up somehow. Did you by any chance make a backup before you installed the first Wallbox integration? I find it’s always a good idea to do that, just in case things go awry.
If you have such a backup, restore from it and then install this ‘unofficial’ integration directly through HACS, using the Repo link you posted earlier (hesselonline).
After reading about the limitations of the official one, I never bothered with it, coming straight to this one via HACS. Upon starting the integration, the Configuration menu appeared which is where I was asked for serial number, password etc.
If you don’t have a backup, you may be able to start from scratch by first removing the integration via Configuration | Devices and Services, then go to HACS and Remove it completely from there.
Once you’ve got everything running correctly, I strongly encourage you to install the ‘Google Drive Backup’ integration, which keeps a copy of the latest 4 (or whatever number you choose) backups in the cloud, just in case your SD card, SSD or whatever gets trashed and you need to start again. Having invested so much time in learning the ropes of HA, developing a Pulsar Plus Dashboard in Node-RED, I don’t want to have to start again from scratch.
Best of luck and let us know how you get on.
Hi Grant - Thank you… I have made some backups, but I think I will get a blank SD card tomorrow and start again. Once I have the WallBox integration working I will slowly add everything else. By pure chance I have the Solar Analytics solar monitoring system, and have 5 minute data points from that - so should be able to control the charger for an eco charge using Home Assistant (I hope)…
Lucky you having access to your solar data!
Redback Technologies (Australia) who provided my system, weren’t so forthcoming, only giving me access to a crippled API after weeks of waiting. Worst thing is, the Session Tokens expire after an hour and have to be renewed manually 
So I gave up on that approach and installed my own Energy Meter in the switchboard, now connected to HA. Not the ideal solution, but it will allow me to automate charging according to excess solar power.
Yep, would be really great if all companies were happy to allow access to ‘our’ data… being able to control devices based on solar production is a great use of automation. Mind you, not much solar around here at the moment
Just a different opinion on the use of the official version versus HACS. I believe the limitations no longer exist and maintaining the official version is easier. So I strongly prefer, and now only use, the official integration. All functions work for me.
I found it helpful to start development with just a list of all available entities on the dashboard. Even if not all the entities make sense (added range), or even give data (state of charge).
type: vertical-stack
cards:
- type: button
name: ALL (DEVELOPMENT PURPOSE)
show_icon: false
- type: entities
entities:
- entity: sensor.wallbox_portal_added_energy
- entity: sensor.wallbox_portal_added_range
- entity: sensor.wallbox_portal_charging_power
- entity: sensor.wallbox_portal_charging_speed
- entity: sensor.wallbox_portal_cost
- entity: sensor.wallbox_portal_current_mode
- entity: sensor.wallbox_portal_depot_price
- entity: lock.wallbox_portal_locked_unlocked
- entity: sensor.wallbox_portal_max_available_power
- entity: sensor.wallbox_portal_max_charging_current
- entity: switch.wallbox_portal_pause_resume
- entity: sensor.wallbox_portal_state_of_charge
- entity: sensor.wallbox_portal_status_description
- entity: number.wallbox_portal_max_charging_current
state_color: true
Tried to change the integration - making the switch available on “Eco-smart waiting” is a piece of cake; however when triggering the switch an error appears:
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/MyChargerID/remote-action
A closer look at the my.wallbox portal shows that, through the cloud, the pause/resume button is not available either / greyed out, eg. this functionality seems to be not supported by the API. On the android app however, via bluetooth, the button is available and it is possible to override eco mode.
Are any of the wallbox team on this forum? Perhaps they can comment
I noticed they did make a contribution to the wallbox repo.
I did a clean install of HA, and decided to first try the official integration. After installation, restart and configure I get this:
If I then go to integrations and ‘reload’ WallBox, I get this (note: I changed the max charge current using the WallBox integration before ‘reloading’ - it did this with an error as explained)
Additionally, the lock button is not working in HA - but if I lock the WallBox using the phone app AND then ‘reload’ WallBox in HA, the charger status correctly shows locked.
Any ideas? This is a clean install of HA 8.1 64bit on a RPi4. The only think I have done is added the official WallBox integration. Thank you!
The problems you’ve encountered are the reasons why I’m sticking with the Unofficial (custom components) version for now at least. Also, I’m still running HassOS 7.0 and I’m not wanting to upgrade just yet. I prefer to stay a few releases behind the ‘bleeding edge’.
I’m using the official integration and the current slider works! I also added a sensor with a more realistic Added km for my IONIQ 5.
Screenshot_20220608-083418|316x500
I have installed HA 7.0, and trying to install WallBox from GitHub. I have enabled ssh, and copied custom_components/wallbox to HA. After a restart I see no indication of a new integration available. Any thoughts?
I also tried (again, from a new 7.0 install) installing HACS, and then loading wallbox as a custom repo. The files are appropriately copied to custom_components, there is a wallbox tile in HACS, but nothing in it and nothing to configure, etc
This is the only integration I have had issues with (so far ) - I am using a RPi4 - could my issues be hardware related? Is there a better hardware choice for running HA?
I have also tried a clean install of 8.1, updated to 2022.6.4 - then the official wallbox integration installed.
Do these log errors help?
Error doing job: Task exception was never retrieved
2:09:23 PM – (ERROR) components/wallbox/sensor.py - message first occurred at 2:08:52 PM and shows up 2 times
Error while setting up wallbox platform for number
2:08:22 PM – (ERROR) Number
Error adding entities for domain sensor with platform wallbox
2:08:21 PM – (ERROR) Sensor - message first occurred at 2:08:21 PM and shows up 2 times
2022-06-08 14:09:23 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 137, in _handle_refresh_interval
await self._async_refresh(log_failures=True, scheduled=True)
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 270, in _async_refresh
update_callback()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 330, in _handle_coordinator_update
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 533, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 571, in _async_write_ha_state
state = self._stringify_state(available)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 539, in _stringify_state
if (state := self.state) is None:
File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 388, in state
value = self.native_value
File "/usr/src/homeassistant/homeassistant/components/wallbox/sensor.py", line 174, in native_value
round(self.coordinator.data[self.entity_description.key], sensor_round),
TypeError: type NoneType doesn't define __round__ method
Andrew, I’m at a loss to understand what’s going on with your system and why this integration is causing you so many problems. This is only the 3rd integration I’ve tried and 2 of them needed HACS, so I’ve had to get to grips with it to some extent.
I’m also using a Raspberry Pi4 and made this choice after asking advice from users of the first integration I started with. The consensus was that it’s not the most powerful platform out there, but it’s capable of running fanless for light duties (such as this integration) and it’s a very simple way to get started with HassOS. So far, I’m very happy with my choice as I don’t intend using HA for much more than controlling my Pulsar Plus, running a few Shelly devices etc.
I have an Intel NUC running my weather station and video surveillance, and that would be my choice if the Raspberry Pi4 runs out of grunt. The NUC has been running faultlessly for almost 5 years now, but does have a tiny fan which is almost inaudible.
So I think your choice of hardware is not the issue. Are you running other integrations which require HACS, or only this one?
On my original installation I had GPIO on the RPi working with a HACS integration. Currently just a blank slate, trying to get WallBox working. I have now tried the official + github installations of wallbox on ‘blank’ versions of 7.0 and 8.1 with no success. There is communication with the charger - when I move the current slider on the integration dashboard I see the charge current change on the wallbox app on my phone - but HA throws an error, and does not display the new value. If I restart the wallbox integration, it then displays the new current value correctly.