Here’s the full list
READY(0),
CHARGING(1),
CONNECTED_WAITING_CAR(2),
CONNECTED_WAITING_SCHEDULE(3),
PAUSED(4),
SCHEDULE_END(5),
LOCKED(6),
ERROR(7),
CONNECTED_WAITING_CURRENT_ASSIGNATION(8),
UNCONFIGURED_POWER_SHARING(9),
QUEUE_BY_POWER_BOOST(10),
DISCHARGING(11),
CONNECTED_WAITING_ADMIN_AUTH_FOR_MID(12),
CONNECTED_MID_SAFETY_MARGIN_EXCEEDED(13),
OCPP_UNAVAILABLE(14),
OCPP_CHARGE_FINISHING(15),
OCPP_RESERVED(16),
UPDATING(17),
QUEUE_BY_ECO_SMART(18);
thx, much appreciated!
It needs to be added manually to the Home Assistant integration. I have done most of the work on the integration so far, but the project is open source → you can create a PR by yourself. However, there is quite a steep learning curve involved, I notice that people often struggle with creating a valid and complete PR. Regarding this functionality, I’m curious if other people are also interested in this being added to the integration. To me, it seems not very useful (in my workflow, maybe different for others) and potentially harmful when restarting at a wrong time. Not sure if we should go this route. Also woried about Wallbox withdrawing support for this integration (or worse, considering the recent Mazda integration story).
I don’t see the need for a Restart function to be added to this integration. If constant restarts are needed, it is an indication that something else is wrong - mostly likely communication errors. I can’t remember the last time I restarted my Wallbox. It would have been many months ago at the time I was battling communication problems of my own. Having resolved those, my Pulsar Plus has behaved impeccably.
It is easy to do a software restart of the Pulsar Plus, either from the app or from the Wallbox Portal. I see no justification for including this function in the integration. Using it carelessly could result in ‘Bricking’ the charger, as mentioned in the Github repo.
I would like the feature. My wall box unit doesn’t update itself; but it would benefit restarting a car charge for me; sometimes it gets stuck. Always has but I am not going to spend a significant amount of money changing the unit out when I could build a quick automation in HA.
I guess if this isn’t added; I could just root it and reboot it that way from the linux CLI.
Decided to root as I also have a power meter and like the idea of polling the topic info to get more info on actual load. Thank you @jagheterfredrik and @tronikos saved me a lot of time creating sensors in ha.
I can use mqtt to reboot it and tie my automation into this as needed now. Thanks.
Since you also have a power meter, if you are interested in approximating energy usage of large appliances and getting notified when they finish take a look at Energy Disaggregation or Non-Intrusive Load Monitoring (NILM) blueprint
Amazing; thank you; I will definitely take a look. I have also got sensor data from the micro2wallbox topic using mqtt; this is brilliant.
Re the integration of the latest version of Wallbox in the end I decided to use appdaemon to pull the latest version then created a python script/app to reboot the wallbox as needed. Was the obvious way in the end and uses the “official” method; it was also easier to combine with other HA sensor data using hass api.
@jagheterfredrik Thank you for the root!
Works great, everyone should do it before Wallbox decide to lock us out.
I have been poking around in there and looking at your code add-ons, I see that it is all running out of the MySQL database inside the unit. Do you think that something like FastAPI would be able to function without messing up the original cloud functions?
If so it would not be too hard to write an API to receive commands and output data and even possibly a simple web based interface for stats etc… That said there must be some sort of API in there to talk to the Wallbox cloud, seems a bit “hacky” going in to the database directly.
I believe the components do RPCs using POSIX message queues if you want to skip the DB.
The micro2wallbox component is the one that communicates with the hardware (by talking modbus-RTU with the TMS320). Cloud is handled by the (iirc) wallbox_cloud component.
The cloud functionality won’t be affected unless you remove the queue connecting the two.
@jagheterfredrik There is really no need for an API to run on the device to return values from the database as HA can do that directly, I am sure it can modify them too but I have not figured out how yet!
I have added a user in to the WB’s mysql database and modified the /etc/my.cnf to change bind_address=127.0.0.1 to bind_address=0.0.0.0 (my LAN is resonably secure). I can now get HA to connect directly to the WB and read the database tables via the SQL add-on. Next step is to modify max_charging_current and pause/resume when I figure out where it is.
Interesting approach, does the sql integration in HA have support for changing DB state? Seems read only from my brief scan of docs.
Indeed it is read only, unless I am missing something, however I have found this
I will have a go at using it to change the max_current in wallbox_config, I have been monitoring the mysql processes and it looks like the services are polling the database about once a second, so any changes should happen fast, but I need to confirm that this is the case.
Been testing this for a while and it works great. It seems to work together even when I have a home battery.
Only there’s no setting that stops from discharging the home battery when there’s no sun anymore.
Nice option during autumn/winter would be to have a timer or stop charging when the PV starts producing again. So in my example, when the home battery is drained… I start to charge the car (keep under 2,5kW due to capacity tariff) and stop it in the morning when PV starts to produce.
I’ve noticed with core version 2023.11 it’s possible to set the charging current less than 6A (even negative values are possible), but it’s just the slider and buttons in HA, the charger itself does not go below 6A tho.
anyone else have this issue?
Good find, I think that’s a bug in my code somewhere. The number component changed a bit with the introduction of the energy price setting. Btw, Wallboxes don’t go lower than 6a so setting it lower will have no effect.
I have a Node Red script that sets the charging current depending on the available solar power, off-peak time, etc… It has been working fine for several months.
Recently i noticed that it had stopped working and gives an API error
I am writing to the “number.wallbox_portal_max_charging_current” entity but it seems to think that I am trying to set the “energy_price”.
I’m not sure when this started but I did receive a software update on the Wallbox recently so it might be related
The wallbox integration has been updated with energy price setting. This is so great. Many thanks to the contributor 
But be careful I tested manual settings and the price is processed at disconnection. So the price has to be left until disconnection. This is essential when the charge is done during off peak hours and the disconnection is done during peak hours.
I did some digging in your code (number.py) and changing the return value from 0 to 6 fixed my issue.
I don’t know if this will impact other things, I’m not an expert in coding, far from it lol.
if you would be so kind to validate this is OK to change?
def min_charging_current_value(coordinator: WallboxCoordinator) -> float:
"""Return the minimum available value for charging current."""
if (
coordinator.data[CHARGER_DATA_KEY][CHARGER_PART_NUMBER_KEY][0:2]
in BIDIRECTIONAL_MODEL_PREFIXES
):
return cast(float, (coordinator.data[CHARGER_MAX_AVAILABLE_POWER_KEY] * -1))
return 6 # was 0 before
yes, that is the fix indeed. Wallbox Change Minimum Value Charging Current by hesselonline · Pull Request #104553 · home-assistant/core · GitHub