This has been a lot more reliable lately! Is there any way I can set the Max Amps in the HA addon so someone couldn’t go higher than 24A instead of the max 40A? It’s all too easy to swipe the slider and go overboard which would trip the circuit in no time.
@penguinponics - You can set the Max Amps inside the lid of the Wallbox Pulsar. Might be the safest way in your case.
Nice setup, just installed it but seems not to behave like it should.
What does green and eco do?
When I put it in eco… it doesn’t change the current and neither on green. When I increase it… it drops step by step back to 6A. While the export power (active) is 3.5kW and PV generates 4kW. Don’t know what I’m doing wrong.
A slight idea might be the fact that all my values are positive… so when injecting it is positive and when using the grid it is negative.
The “Eco” mode will control the charger current to use only excess solar. It does this by controlling the mains current (what you import or export) to zero. There is minimum of 6A charging current (a limitation of the communication protocol between the EVSE and the car). So the charge will never stop, just slow down.
The “Green” mode is the same, except for how it deals with the minimum 6A charging current. The charger will pause if less than 6A is available and resume when 6A becomes available (with hysteresis).
If the logic controls the current down to 6A, is sees an import of power. Are you using the right sensor for the mains power, and does it have the correct sign?
Note that the controller considers export a negative power and import a positive power. I think that is the inverse of what you have.
1 Like
I believe it is the case… this is the chart I’ve made of the values how they are.
So this means I need to change the values to positive or how to adapt?
Yes, for you the current delivered to the grid is positive so the charging control logic fails the way you describe.
You must either inverse the grid power calculation, or you must change the charging control logic.
The charger control logic has two actions; one to step the current up (when the grid power is below -250W) and one to step the current down (when the grid power is above 250W). You should change that to step the current up (when the grid power is above 250W) and step the current down (when the grid power is below -250W).
Success!
Below is my set-up. If you swap the ’ below “-250” ’ and ’ above “250” ’ statements you should be good.
alias: EVSE - Charger current controller
description: >-
Controls the Wallbox charger max current setting up and down (between 6 and 32
A), maintaining the grid power around zero, to use excess solar power only.
trigger:
- platform: time_pattern
seconds: /12
condition:
- condition: state
entity_id: input_boolean.charger_max
state: "off"
- condition: state
entity_id: sensor.wallbox_portal_status_description
state: Charging
action:
- choose:
- conditions:
- condition: numeric_state
entity_id: sensor.actual_power
below: "-250"
sequence:
- service: number.set_value
data:
value: >-
{{ [((states('number.wallbox_portal_max_charging_current') |
float(0) + 1.0) | round(0)), 32] | min }}
target:
entity_id: number.wallbox_portal_max_charging_current
- conditions:
- condition: numeric_state
entity_id: sensor.actual_power
above: "250"
sequence:
- service: number.set_value
data:
value: >-
{{ [((states('number.wallbox_portal_max_charging_current') |
float(0) - 1.0) | round(0)), 6] | max }}
target:
entity_id: number.wallbox_portal_max_charging_current
mode: single
1 Like
So it seems to be working after adapting it. Only thing I was wondering the logic of pause and resume. Because when you are charging the export is low. So when I set it to below 250… it goes to pause because it is charging. So I set it to 0 and when going below it… it goes in pause. Time I adapted to 3min because it takes 120 to go from 16A to 6A.
What I notice is that when it went in pause and resumes… the Amps are set to high and seems not to adapt until I push on green, then it starts from 6A…
One issue is the fact I have a battery so when I use more than PV generation then the battery comes in… so this needs also to be adapted from the moment the there’s a discharge on the battery it goes in pause.
Any suggestion?
I assume your battery starts taking power when there is excess solar power available. So the battery and the car charger compete for this power. That can led to some strange instable controller behavior. Probably the car should take priority.
Since you know the power taken by the battery you could control the EVSE based on the sum of the grid and battery current.
Mind your power directions, your grid power is positive when absorbing power, but you battery power is negative when absorbing power.
Made a simple trigger when the battery is discharging for 2min and the EV is charging to put Wallbox in pause. After that it will resume based on the excess of PV power 
I have been watching this thread with interest, but am not sure of how to apply it in my situation.
I seem to have two competing Wallbox needs.
- I have Intelligent Octopus. This uses an OCPP connection to Octopus to control my Wallbox. When my EV is plugged in Octopus chose the right time to charge it to make use of cheap electricity. There is a both a fixed and dynamic element to the time window they choose to charge the EV.
- During the day, if generating excess solar, I’d like to use one of the strategies in this thread to charge the EV.
What I am missing is how to run both OCPP and one of the above Solar approaches.
To use ECO mode via Wallbox config, I have to turn OCPP off. I can’t see how I can automate this switchover in HA?
If I leave OCPP to Octopus on, it seems I need to use HA to automate (as described in threads above) to detect excess solar, and set the Wallbox to charge at an appropriate power.
However, when I try setting the Wallbox to charge via HA, it seems to “upset” the OCPP connection to Octopus, and when the sun has gone down, if my EV still needs more Power, Octopus does not seem to kick in.
I can sometimes “reset” OCPP, by unplugging the EV and plugging in again, but that’s not ideal.
Sometimes I have to reboot the Wallbox to re-establish OCPP.
Has anyone found a successful strategy of automating a switch between daytime solar charging, and nighttime Octopus Intelligent?
1 Like
Hi, you can’t run both OCCP and this integration concurrently - if technically possible (which I doubt) then that would cause conflicts. Switch off functions like OCCP from HA to my knowledge is not possible either. This is because we rely on a cloud based api solution and those settings are not exposed.
What’s left for your use case is a possibility to reverse engineer the “Octopus” solution in HA. You can use EV Smart charging for this combined with nordpool. The integration picks the cheapest hours within a timeframe you can indicate yourself.
https://github.com/jonasbkarlsson/ev_smart_charging
Then combine this with the automation for solar charging.
Define an input switch/ boolean - off being cheap/night charging and on being green/solar charging. Depending on the state of this bool either of the automations is active or inactive.
I am working on the same setup but given a general lack of time / competing projects and net metering in NL i decided to fully use the EV Smart charging integration for the time being and turned off my dynamic/eco setup altogether.
In my case EV Smart charge triggers the wallbox pause/resume. Included some additional tests upon ha restart or wallbox state changes to manage/avoid uncontrolled behavior.
Thank you for the suggestion, but sadly I don’t think emulating Intelligent Octopus will work.
The cheap energy time slots are only calculated when the EV is detected as plugged in by Octopus.
If you don’t use OCPP for a while and do it manually, Octopus notify you and switch you back to Octopus Go (a fixed timeslot tariff - also cheap, but not as cheap as Intelligent Octopus).
So to get the best deal overnight OCPP to Octopus seems a must.
I agree the Wallbox integration is currently limited, and via the API you can’t switch OCPP off.
So it seems my use case is not possible unless Wallbox makes more features available in the API.
Seems my best option right now is to charge overnight on Octopus OCPP (10p) and sell excess daytime Solar back to them (5p). Thus an effective cost of 5p to charge the car (when the sun is out).
Thank you for taking the time to reply.
TL;DR; I put an embryo of a home assistant component that can locally control a Wallbox Pulsar Plus over Bluetooth on Github.
Longer:
I was searching high and low for a EVSE with local API and the one I did find (the go-e) were expensive and unavailable. So I got the Wallbox Pulsar Plus for its sleek design.
Hardware wise, I don’t think I have ever seen a more expensive BOM. A Raspberry pi compute module! Two(!) radios, one WiFi+BT, one BT only. Pretty insane considering there are cheaper MCUs that come with both WiFi and BT built in for a tenth of the price of just the RPi module.
Reading this thread gave me some hope: I guess OCPP is better than nothing but the delay that has been mentioned is somewhat off-putting.
I haven’t even installed it yet but started hacking together control over Bluetooth and ended up with something that is really fast and can control the EVSE without a cloud connection. The embryo mentioned at the top is highly experimental and implements only the locking functionality for now. It can’t handle being disconnected. Enabling it for a box will make it impossible for the Wallbox app to connect to that box over Bluetooth, cloud still works. Of course uninstalling the component and restarting HA re-enables Bluetooth for the app. PRs welcome!
3 Likes
Promising; do you connect via an esp32 or directly from the device running home assistant? Mine is very much out of bluetooth reach (upper attic) so can’t test this unfortunately but through an esp32 might be able to pull it off.
Updated the integration with reconnection logic, set charge current, start/stop charge and charging status. Changes are reflected in the Wallbox with sub-second latencies, all locally.
Some Wallbox Pulsar Plus energy consumption numbers:
WiFi+BT+Front light: ~4.5W
BT+WiFi: ~3.8W
BT only: ~3.4W
2 Likes
This is very interesting work @jagheterfredrik ! I am impressed. Been using the current integration but I was hoping for something local.
I know it’s an embryo but maybe to get some more people onboard (as in: free testers 
)you could add a more detailed “readme” to help people get the custom component running.
Or maybe would you consider adding it to HACS?
Just add the link (GitHub - jagheterfredrik/wallbox-ble: Home assistant component for local control of Wallbox Pulsar Plus over BLE) as a custom repository in HACS and install the “Wallbox BLE” integration 
The wallbox will be automatically discovered in the “Devices and Services” settings page.
2 Likes
Yeah - I know that’s how you do, I just meant to make it more visible to other people.
But I know it takes time and I am just happy if you focus on the dev
PRs welcome 
1 Like