yup I know, I do this too, I only mention it to put some polish on the mqtt integration 
I think there is so much polish on the MQTT integration now, it shines brightly like the sun and you almost can’t bear to look at it 
Seriously, we shouldn’t burden the authors with minor annoyances that we can easily work around by ourselves. Possibly, the idea of a ‘Unified Charge Control’ is one of those. It would be something nice to have, but not really that important in the big picture.
1 Like
Just installed it, some hiccups on pairing and connecting to the AP but once I was in this was a breeze.
And it’s lightning fast - fantastic!
Just one question - when running the script I was near the window, for best bluetooth and wifi coverage - not surprisingly in addition to my own Wallbox I saw 2 more. Whilst wallbox is busy repairing this security leak through a firmware update, what can we do? Is the rooted WB secure as is? Can we secure the bluetooth some how or change the wifi access code?
Also I assume that under no circumstances we should install further firmware updates? Can we prevent remote firmware updates in case WB would want to force these? Had this recently with a different hardware manufacturer (Philips) - their updates broke local control; only option was to firewall my devices from the internet completely.
1 Like
I write about it here Wallbox pulsar plus integration? - #636 by jagheterfredrik but it’s only until next reboot (I think!)
Ah, I liked that post in March and applied it. But clearly it did not stick as I rooted the wallbox just now without issues.
I was thinking, it should be possible to turn off bluetooth right? Seeing it’s just a PI4 board. Through SSH it should be feasible to enable/disable the service at will and perhaps (but that’s outside my skill level) even through mqqt or rest API?
Out of curiosity, did you get any thanks from wallbox for finding this vulnerability? I have not seen any publications from their end yet…
systemctl stop blewallbox; systemctl disable blewallbox will disable it completely. Hard to recover if you have wifi problems though
ok, so the best solution would therefore be to stop bluetooth but not disable it.
in case the wifi or ethernet connection fails, rebooting the wallbox will restore the bluetooth functionality.
thought so as well, but am a bit hesitant
I had something weird going on today.
Charged the car this afternoon and stopped the charge through HA using the pause button, then unplugged the car.
Many hours later I opened the wallbox app and saw the wallbox to be in the pause status.
In HA the mqtt status sensor shows Ready and the device itself has a green led.
After locking and unlocking the wallbox through HA everything is back to normal.
Anyone else noticed this behaviour?
I notice there is an update available for the MQTT Bridge. This is not an Integration for HA, nor is it an Addon for HA, nor is it a HACS Integration, so the update process is different to what I’ve encountered before.
Do I need to re-run Step 3 from the Readme Doc…
sshto your Wallbox and runcurl -sSfL https://github.com/jagheterfredrik/wallbox-mqtt-bridge/releases/download/bridge/install.sh > install.sh && bash install.sh
Or is there some other way of updating the MQTT Bridge?
I’ve often noticed the Status in the Wallbox Portal lagging well behind updates elsewhere, but usually the Wallbox App seems to be correct. Having said that, I hardly ever use the Portal or the App now, so something may have changed recently.
There was a small correction in the sensors.go file and the bridge file has been updated accordingly, so running the install script through ssh should replace the old version with the new one.
1 Like
Newbe question. I have been studying this excellent forum and great solutions from the different contributors.
I have just installed Wallbox Plus with OCPP and EV Smart Charging from Jonas. This all works quite well and follows the dynamic pricing that I use.
Still load balancing to implement, prefer Node Red based, but not found the best solution here for 3phase and P1 port. So suggestion which one to use is welcome.
One big question remains for me. Why should I go for the rooting Wallbox and installation of MQTT Bridge for Wallbox ? Is OCPP indeed too slow for the load balancing ? With MQTT I will have to change the code for EV Smart Charging as well .
Thanks, Rob
the most obvious reason to go with mqtt is being completely independent from cloud servers and communicate 100% locally with your wallbox, at the same time greatly reducing the response time.
when using the cloud integration, I had often a “disconnected” status, with mqtt never again.
modifying the code for mqtt is only once and not complicated, you only have to change the sensor names in the code.
about load balancing, I have the EM340 meter in my distribution board (the P1 model didn’t exist yet when I bought my wallbox, nor had I a digital smart meter, was still analog back then), so load balancing is done internally in the wallbox in my case, not through HA.
but using P1 for load balancing in HA is very straight forward and would also be a good reason to go with mqtt as the charging power readout from the cloud integration was very slow, lagging a lot and often the wrong value.
with mqtt it’s instant and the correct value, therefore ideal to compare with the readout from P1 for load balancing and acting on it.
anyway, I can recommend the mqtt integration, very happy to have made the transition!
Thanks for your explanation.
I don’t use cloud. Wallbox Pulsar is connected to my locally run OCPP server on HA.
So, for me I think there is no benefit to use MQTT. The benefit of local OCPP is that logging to the servers of Wallbox still continuous so, I have next to OCPP locally a cloud based backup.
My next step is now to add the load balancing with P1 as input.
Oh ok, didn’t know OCPP was local too. MQTT doesn’t cut the wallbox from the cloud also, but you can if you want to.
@register - I started with the OCPP integration before switching to this one. I found that the comms suffered from frequent disconnections, and the Pause/Resume function created a new charging session each time Resume was used. It meant a lot of short charging sessions appeared in the Wallbox App/Portal log and the L1/L2 session counter on my EV increased a lot.
With MQTT Bridge, I have the best of both worlds. Logging to the Wallbox servers continues and I have totally reliable local control with a properly implemented Pause/Resume function.
Thanks @jagheterfredrik, your work has made this excellent wallbox the best for Home Assistant!
Just one question, where can I find the sensors.go file? I would like to change the name of some sensors.
You’ll need to download the source files and change sensors.go from there and then rebuild the bridge file and upload it to your wallbox, that’s how I do it.
But why would you change the names there, it’s easier to do this in HA?