Wallbox pulsar plus integration?

Hi. I see WB Pulsar Plus 5.13.11 firmware is available… https://support.wallbox.com/en/rn/release-of-8th-november-2022/

Has anyone loaded this up? Hoping it does not break anything with this integration :slight_smile:

No problems here.

1 Like

The release note is very helpful “Fixed some minor bugs”!

I believe I have resolved the intermittent authentication errors. I have contributed some code to the Wallbox Python (upstream) package that allows for setting a ‘time drift’ on the TokenTTL.

Basically this allows us to trigger refreshing the token before it has totally expired (for example, setting the drift to 30 seconds will also refresh the token if its about to expire in 30seconds). This prevents the token from being valid during authentication check but expired when the subsequent refresh starts.

Changes have been merged and should thus start appearing soon in releases of hass.

3 Likes

Installed the new firmware on 1 of my 2 Pulsar Plus chargers.
I did the update during a charging session which started around 19:00 first I see the old faulty behaviour but after the update I did at around 19:45 I see the behaviour I should expect.

So it seems the charging power issue is solved with this firmware release.

5 Likes

That’s fantastic news, thanks for posting :grinning:

I can confirm that the power reporting issue is solved with this release.

However, I now also have a Shelly EM (calibrated with a DMM) measuring the Wallbox. The Wallbox communicates a current limit to the car, the car charger controls the current drawn from the EVSE. So you would expect the power to vary with the mains voltage. In my location the mains voltage varies quite a bit in time (under-dimensioned utility network). The Shelly precisely reports a constant current drawn by the car and a power varying with the mains voltage. The Wallbox simply reports a constant power. I believe it measures (or even assumes) the current drawn and multiplies with an assumed mains voltage. In my case it reports a good 15% too high (low actual mains voltage).

To illustrate the above:

Started charging at about 8:00. Mains voltage around 210 V. With the sun coming out the mains voltage rises to about 240 V. The Wallbox is set at 16 A max, the car draws a constant 15 A. The Shelly EM shows an increasing power (constant current and rising voltage), the Wallbox stoically reports a constant power.

2 Likes

“The Wallbox simply reports a constant power. I believe it measures (or even assumes) the current drawn and multiplies with an assumed mains voltage. In my case it reports a good 15% too high (low actual mains voltage).”

This explains why my power readings from the Wallbox are so far out. In the middle of the day, my line voltage is often around 245V. With abundant solar power at this time of year, that’s often when I’m charging my EV and the Wallbox says 3.15kW whereas the EM provided with my solar power system says 3.6kW. I know from experience that the solar power EM agrees very closely with the utility meter installed by my power company, therefore I can trust the readings are accurate. Wallbox consistently reads low by 15% or sometimes more. It’s good to know why, so thanks @VdR for the detailed analysis.

Tomorrow I’ll be charging my EV with upgraded software in the Pulsar Plus for the first time. Looking forward to seeing my Dashboard behaving correctly at last.
P.S. It works perfectly with no dropouts :+1:

1 Like

Here’s a good illustration of the operation of my Pulsar Plus charger in the presence of passing clouds and varying household loads. The only time the indicated charging power drops to zero is for very brief periods, just before the battery reaches 100%. This is what actually happens with a Nissan Leaf, so it’s not a fault.

1 Like

Looks great, still a pity the 3phase version cannot switch to 1phase - I need a minimum of 4kw to charge. That being said, I will switch to a dynamic contract soon, so will have to change my thinking / algorithms altogether.

Hello everyone.

I’m considering pulling the plug on one of those, but HA integration is key for me.

The thread is too long for me to read it all, but I glanced over it and know that there was an HACS integration that is now native, and that’s awesome.

However I believe I also read that you can’t control the charge (or charge modes ?) from HA. Is that still the case ?

As most of you the only reason I want to use that much money on a wallbox when cheapers alternatives exist, is for the solar power excess charging.

Is there a list a supported energy meters ? My electrical panel is in a shitty place and I can’t really use electrical clamps as much as I want.

Thanks.

You can control the charge, but not the charge modes from HA. You can only control the charge modes with the Wallbox app when connected to the charger through BT. This is a huge oversight in my opinion, I don’t want to walk out to the charger to interact with it, that defeats the purpose of the app.

The good news is that you can control the charger through HA, and thus recreate the charge modes with simple automations.

You only need an energy meter connected to the Wallbox if you must protect your main fuse (power boost) or if you want to use the Wallbox charge modes (eco). Note that the energy meter connects to the Wallbox through a modbus connection, you cannot conveniently get access to the data in HA.

To realise the charge mode automations in HA, you need an energy meter on the mains that you can read in HA.

In my setup I have the energy meter connected to the Wallbox to protect the main fuse. I do not use it for the Wallbox charge modes. I have a second energy meter connected to HA, that is also used to realise my own charge modes (including excess solar).

1 Like

Thanks for taking the time to answer.

I know I can redo it myself and I am also investigating that option. If I were to do so I would go with a cheaper option like an OpenEVSE kit.

I can get my solar production from my solarEdge inverter already.

I guess this might be the way to go, all the off the shelves solutions seem to have shortcomings or be more annoying to setup.

Note that to use excess solar you need the mains power. The logic tries to keep that mains power at zero controlling the charger power. If you use the solar power you do not take other consumers in the house into account.

Two reasons why I went with the Wallbox: I needed the power boost function to protect a relatively small main fuse (50A). And it has built in dc leak protection, which saves a good 100 euro on the external GFI. On top of that it has never let me down for the key function of charging the car.

To be honest, at this moment I am rather happy with the Wallbox and the integration. What would really be nice (and I am actually asking @Oriol_FP here) is to be able to switch on and off the LED with an API.
Not the current LED timeout function, but actually deciding at any time if the LED should be on (whatever current color it should be) or off.
Example use case: when there is no car LED is off. Switches on when there is a car parked. Or when charging it goes off after a timeout but switches on again if movement is detected … and so on.

1 Like

[quote=“VdR, post:517, topic:200339”]

Looks great, still a pity the 3phase version cannot switch to 1phase - I need a minimum of 4kw to charge. That being said, I will switch to a dynamic contract soon, so will have to change my thinking / algorithms altogether.

Hi @RT1080
That is a very good request to gain some efficiencies in the system. I take note. Thanks for sharing. I remember there was a problem with switching too often between mono and threephase charging within the EV that justify why that wasn’t that easy to implement. But I will double check

Hi @andyfsimon
Thanks for sharing your needs.
The deeper request here is whether wallbox should open their functions for external party Home Automation and Home Energy Management System (HEMS) in a more user-friendly way than OCPP.
Also, there is a deeper topic on whether which is the best standard to do so. It is non-sense that every Charger OEM develops their one API or whatever integration instead of using a common lenguage.
Besides that, would come, the agreement on which functions are the best to be open.
We don’t have answers yet for that but we are currently focusing more on building integrations with utilities rather than directly with B2C clients or Home Automationos and HEMS systems.
Hope this helps clarifying some of your concerns.

I agree with you @Oriol_FP , but expecting every single provider of car chargers to join in and move to a common standard (expecially while OCPP is available already) seems rather wishful thinking. Wallbox working with utilities also pretty much defies the intentions of most HA users (get rid of cloud).
On the other hand, Wallbox APIs exist now and Wallbox will be continuing the development of their app for the years to come (at least until such new standard will arise) so a request to open up an available function seems much easier and down-to-earth to handle than waiting for “the perfect integration which unfortunately we don’t want to use because depends on someone else’s cloud”.
If this is the direction Wallbox is taking, I see it less and less a favorable choice of HA users.

Great thoughts @andyfsimon
Thanks for sharing them.
I agree with you that, maybe, we just shall focus on this easy to implement quick wins. Unfortunately there’s no more I can do apart from taking note of this request and sharing it internally.

1 Like

That’s way beyond our abilities here @Oriol_FP , so it’s still very much appreciated :slight_smile: !

1 Like