There can’t be multiple statuses at the same time.
It would be great if you could try with the GitHub - jagheterfredrik/wallbox-mqtt-bridge at lock-status-trickery-debug branch
(Edit: there are a couple of different statuses but they are all a single value)
Edit: I sat down and mapped up the state machine state values and control pilot state values and exposed them as sensors on the debug branch
OK a lot of data for you to look at but I think this is suggesting that “Session state” is what we need to translate to a useable state. I have mostly provided the debug sensors you created but in some cases I’ve shown the logbook entry as several events occur too fast to capture.
Startup, not plugged in:
Added energy 30,709.3 Wh
Added range 0.0 km
Cable connected Unplugged
Charging power 0.0 W
Control pilot 161: Ready
Cumulative added energy 844,956.0 Wh
M2W status 6
S2 open 1
Session start timestamp 1
Session state 209: Lock
Status Locked
Plugged in: - this is the status that currently looks wrong as it reports paused instead of locked which you can get for session state.
Added energy 30,709.3 Wh
Added range 0.0 km
Cable connected Plugged in
Charging power 0.0 W
Control pilot 177: Connected 1
Cumulative added energy 844,956.0 Wh
M2W status 4
S2 open 1
Session start timestamp 1
Session state 210: Wait Unlock
Status Paused
Unlock:
Added energy 30,709.3 Wh
Added range 0.0 km
Cable connected Plugged in
Charging power 0.0 W
Control pilot 177: Connected 1
Cumulative added energy 844,956.0 Wh
M2W status 3
S2 open 1
Session start timestamp 1.70268e+09
Session state 179: Connected 3
Status Connected waiting schedule
After auto lock reengaged (but plugged in so still should be ready to charge):
Added energy 30,709.3 Wh
Added range 0.0 km
Cable connected Plugged in
Charging power 0.0 W
Control pilot 177: Connected 1
Cumulative added energy 844,956.0 Wh
M2W status 3
S2 open 1
Session start timestamp 1.70268e+09
Session state 179: Connected 3
Status Connected waiting schedule
Charging:
Wallbox Control pilot changed to 194: Charging 2
22:44:54 - 1 minute ago
Wallbox Session state changed to 194: Charging 2
22:44:54 - 1 minute ago
Wallbox S2 open changed to 0
22:44:54 - 1 minute ago
Wallbox Control pilot changed to 178: Connected 2
22:44:53 - 1 minute ago
Wallbox M2W status changed to 1
22:44:53 - 1 minute ago
Wallbox Status changed to Charging
22:44:53 - 1 minute ago
Wallbox Session state changed to 180: Connected 4
22:44:52 - 1 minute ago
Wallbox Charging enable turned on triggered by service Switch: Turn on
22:44:52 - 1 minute ago - Paul
Wallbox M2W status changed to 2
22:44:52 - 1 minute ago
Wallbox Status changed to Connected waiting car
22:44:52 - 1 minute ago
Added energy 2.7 Wh
Added range 0.0 km
Cable connected Plugged in
Charging power 1,434.0 W
Control pilot 194: Charging 2
Cumulative added energy 844,956.0 Wh
M2W status 1
S2 open 0
Session start timestamp 1.70268e+09
Session state 194: Charging 2
Status Charging
Paused charging:
Wallbox Control pilot changed to 177: Connected 1
22:47:13 - Now
Wallbox Session state changed to 182: Connected 6
22:47:13 - Now
Wallbox S2 open changed to 1
22:47:13 - Now
Wallbox Session state changed to 178: Connected 2
22:47:12 - 1 second ago
Wallbox Charging enable turned off triggered by service Switch: Turn off
22:47:12 - 1 second ago - Paul
Wallbox M2W status changed to 4
22:47:12 - 1 second ago
Wallbox Status changed to Paused
22:47:12 - 1 second ago
Added energy 51.3 Wh
Added range 0.0 km
Cable connected Plugged in
Charging power 0.0 W
Control pilot 177: Connected 1
Cumulative added energy 845,008.0 Wh
M2W status 4
S2 open 1
Session start timestamp 1.70268e+09
Session state 182: Connected 6
Status Paused
Unplugged:
Wallbox Session state changed to 209: Lock
22:49:04 - 25 seconds ago
Wallbox M2W status changed to 6
22:49:04 - 25 seconds ago
Wallbox Status changed to Locked
22:49:04 - 25 seconds ago
Wallbox Session start timestamp changed to 1
22:49:03 - 26 seconds ago
Wallbox Control pilot changed to 161: Ready
22:49:03 - 26 seconds ago
Wallbox Session state changed to 161: Ready
22:49:03 - 26 seconds ago
Wallbox Cable connected was unplugged
22:49:02 - 27 seconds ago
Wallbox M2W status changed to 0
22:49:02 - 27 seconds ago
Wallbox Status changed to Ready
22:49:02 - 27 seconds ago
Added energy 51.3 Wh
Added range 0.0 km
Cable connected Unplugged
Charging power 0.0 W
Control pilot 161: Ready
Cumulative added energy 845,008.0 Wh
M2W status 6
S2 open 1
Session start timestamp 1
Session state 209: Lock
Status Locked
Unlocked (cable disconnected):
Wallbox Session state changed to 161: Ready
22:50:54 - In 1 second
Wallbox Lock was unlocked triggered by service Lock: Unlock
22:50:54 - In 1 second - Paul
Wallbox M2W status changed to 0
22:50:54 - In 1 second
Wallbox Status changed to Ready
22:50:54 - In 1 second
Added energy 51.3 Wh
Added range 0.0 km
Cable connected Unplugged
Charging power 0.0 W
Control pilot 161: Ready
Cumulative added energy 845,008.0 Wh
M2W status 0
S2 open 1
Session start timestamp 1
Session state 161: Ready
Status Ready
Autolock engaged (cable disconnected):
Wallbox Session state changed to 209: Lock
22:51:55 - In 1 second
Wallbox Lock was locked
22:51:55 - In 1 second
Wallbox M2W status changed to 6
22:51:55 - In 1 second
Wallbox Status changed to Locked
22:51:55 - In 1 second
Added energy 51.3 Wh
Added range 0.0 km
Cable connected Unplugged
Charging power 0.0 W
Control pilot 161: Ready
Cumulative added energy 845,008.0 Wh
M2W status 6
S2 open 1
Session start timestamp 1
Session state 209: Lock
Status Locked
Ok, I’ve updated the non-debug branch to look for the “Wait Unlock” state, I think that should match expectations?
I think for most of us who are using this integration, the main objective is local control; the second most important objective is to improve upon the ‘Native Eco Green’ feature of the Wallbox. For me, that’s certainly the case.
My Dashboard gives much improved control compared to the Wallbox offering. For example, I have a function which prevents discharge of my house battery late in the afternoon when charging my EV. I can choose to prioritise charging the house battery, or the EV. I can also stop charging when a target kWh value is reached. Wallbox made a good start with Eco Green, but with HA, many more improvements are possible.
in my case the ECO smart functionality was the very reason to start with HA.
because I have two wallbox ev chargers with load balancing and dynamic power sharing, the ECO smart is not available.
so I made my own ECO charging with HA and at the same time I have improved it to my own liking too.
having the local control in HA makes it complete.
the only reason I use the app is for scheduling a session.
Have a look at ev smart charging:
I use it to plan based on electricity tariffs. I works great.
For a more advanced setup (including load balancing/ battery steering) I highly recommend Emhass, not for the faint of heart but once it works… especially when on dynamic tariff.
https://community.home-assistant.io/t/emhass-an-energy-management-for-home-assistant/
I’m definitely going to use this as part of my EV smart charging. I already have the automation written and was using the cloud integration but this local control will improve the control significantly due to the improved reaction time. My scheme is quite simple - when enabled, it measures the the excess solar production every 30 seconds and if it meets the required threshold it sets the Wallbox charging current to use the excess (plus or minus an optional offset). It’s crude but works quite well.
I have another automation that dumps the house battery into the Wallbox if I have excess power in the house battery and the next day’s solar forecast is good.
I know these can be replaced by something like emhass which I’m sure would do a better job but as mentioned, its quite a task to set up and no doubt a pain if it doesn’t give you the results you expect - my automations are simple so easy to debug. So please with having Wallbox local control, now all power control in my house is local.
my eco automation adjusts the max charge current 1 amp at a time.
when there is +700W excess solar energy going into the grid, it goes up 1A, waits 30 sec to check again, if again +700W excess, 1A up, etc…
when -200W consuming from the grid, it goes 1A down, waits 30 sec to check again, etc…
when more than -4000W consuming from the grid for more than 2 minutes, the charging stops until there is enough excess solar energy to the grid again (+4000W).
I find the 30 sec adjustment and the 2 minutes threshold very useful to take into account clouds, this way the current adjustment isn’t jumpy and the charging doesn’t pause/resume all the time on a sunny/cloudy day.
Have a similar algorithm based on the work of @GrantK among others. But since i am on dynamic tariff i find that price is a very decent proxy for CO2 saving as its generally wind and solar which push prices down. So as long as we have net metering in the Netherlands that works well.
Off topic: I have seen examples of people using Emhass in Australia saving hundreds of dollars per month - the spreads there are gigantic and with the right optimization you can seriously benefit. Max I have seen here in NL is +64c for a kWh vs. -50 in summer, both perhaps 2-3 hours in a year. Mostly the spreads are 7 - 15 cents between peak and through, just enough to justify cycle costs for the battery.
Differences between regions and countries is sometimes massive.
For me (Flanders) there is a monthly tariff, it’s the same price/kWh day and night for the month.
There is a tariff for consumption and we get payed for injected excess solar energy to the grid.
But we do have an extra cost for peak consumption to force the consumer to keep their energy peak consumption as low as possible at any given time.
Even though I’m on the other side of the world in New Zealand, the structure of my electricity charges is quite similar to @Krivatri in Flanders. There are 4 components to our monthly bill:
So for me, it makes no difference when I use the energy unless it’s on a very few days per year in the middle of winter. All the energy in our House Battery is used every night, so anything taken from it needs to be replaced @ 34c per kWh. Therefore, it never makes any sense for me to use House Battery energy to charge my EV. Much better to wait until the sun is shining (if possible), or if I can’t wait that long, use grid energy at night through the ripple-controlled meter.
My point being that each of us have different use cases and I love the flexibility afforded by HA where we can so easily tailor our controls to match our individual circumstances. I don’t use any HA automations at all, just a couple of templates. All my programming is done in Node-RED which is a visual programming environment I find very intuitive and easy to maintain.
I have a request regarding the availability of the mqtt bridge.
yesterday I disconnected the ethernet connection between my switch and the wallbox to do some testing on the ping integration in HA I have setup to check the availability of the wallbox.
after reconnecting the cable, the connection was restored and HA reported the wallbox as online.
but today when I wanted to charge the car, I noticed the bridge had stopped working,
although the network connection was still alive and the micro2wallbox topic was also active, the bridge was not, probably due to my disconnecting/reconnecting the day before.
so I would like to be notified when the bridge has stopped working or isn’t reachable/alive anymore.
I guess this has to be done through an availability topic or last will?
I’m trying to figure out how to implement this but I don’t have the know-how nor the coding skills to achieve this unfortunately.
Added logic to reconnect when the MQTT broker is disconnected
Edit: Also added a new feature: Halo light dimming. Do you find your Wallbox too bright? Dim it!
Was the disconnection issue ever fixed on this? I’m just setting up HA and noticed that my Wallbox Pulsar Plus is reporting a status of “Disconnected”, then “Ready” repeatedly.
Well that’s a first. The disconnection issue was from the bridge to the MQTT broker. This is your charger saying disconnected in relation to the car.
I have never seen the disconnected state, it’d be interesting to see what you get with the additional debug sensors if you use this branch: GitHub - jagheterfredrik/wallbox-mqtt-bridge at lock-status-trickery-debug
Is this with the mqtt bridge or the cloud integration?
I just added support for availability using last will to an availability topic. There is no need to use ping anymore.
Great! Thank you.
I didn’t use ping no more but the state of the connection in $SYS/broker/connection/bridge-ha/state
Its with the cloud integration. When I saw @jagheterfredrik 's response I did wonder if this thread was just for the MQTT version. Apologies if it is.
Whilst the MQTT option intrigues me, I’m a little nervous about pwning my wallbox in case I screw it up and brick it. Hence going with the cloud option.
The disconnected state is because of the cloud server, nothing you can do about it.
You don’t have to be afraid for trying mqtt, you can’t brick your wallbox this way, if you do it wrong, mqtt won’t work, but it does not affect the workings of your box.
