Wallbox pulsar plus integration?

Just to experiment I have implemented my own eco-Smart function in HA.

A simple proportional controller sets the charger current limit depending on the grid power. It works, but of course, going through the api with a 30 second update rate is not ideal. Clouds passing by and tumble dryers switching on and off is rather dynamic.

Of course now I can combine this mode with any schedule I want.

But being able to use the Wallbox implementation of eco-Smart would be a much better solution. Just need to be able to enable/disable through the API.

This is how I envision that:

  • a charge mode selector that can be ‘off’, ‘max’, ‘eco’, or ‘green’
  • the scheduler that has multiple switch points and includes the mode to use for a selected period.

‘off’ means no charging,
‘max’ means charging at max current,
‘eco’ means excess solar with a 6A minimum,
‘green’ means excess solar only.

2 Likes

I double checked, schedule does override the eco setting. However, once the schedule ends there is no auto switch back to eco smart.

1 Like

Can you share your setup? I try to build something as well but good to see your logic.

My thoughts to limit the amount of switching on/off is to trigger on at excess solar for X minutes and off at shortage longer than X minutes - I don’t think this differs much from what the ecosmart logic entails.

Can then optimize this by back testing and adjusting to improve results.

Is there an issue with charging the battery multiple times a day. I thought it was best to minimize the number of times it’s charged ie when it drops to say 40% charge to 80%.

Here’s the logic used by Wallbox according to an article in their Knowledge Base…

Wallbox for their Eco-Smart option use a 2 minute period during which solar export needs to exceed 1.38kW before charging starts. Then if it falls below that threshold for 30 seconds or more, they pause charging.

This is for a single-phase charger; it’s a bit different for 3-phase.

I don’t think there’s any issue with multiple short charges so far as they affect battery life. It’s just the number of Level 1/2 charges recorded by the EV will be higher. This is why it’s good to use Pause/Resume rather than terminating one session and starting another.

Wallbox for their Eco-Smart option use a 2 minute period during which solar export needs to exceed 1.38kW before charging starts. Then if it falls below that threshold for 30 seconds or more, they pause charging.

This must relate to the minimum charge current of 6A (1.38 kW at 230 V). However Wallbox eco-Smart has two modes. In ‘eco’ mode the charger continues charging at 6A, even when there is no solar export, in ‘green’ mode the charge is paused every time solar export drops below 1.38 kW.

1 Like

Can you share your setup? I try to build something as well but good to see your logic.

Warning:
My setup now is purely experimental, to play around, not a solution! As you can see in the graph I’m emulating ‘eco’ mode, not ‘green’ mode. The minimum charge current is 6A. You can also see that it turns into a ‘bang-bang’ controller, falling back to 6A all the time. The loop amplification must be tuned down. This means a larger static error is required. I couldn’t experiment any further because some-one took the car :slight_smile: . The controller should be changed into a PI controller, but with the 30 seconds time constant of the API in the loop I’m not hopeful that would lead to an acceptable result. Hence my constant plea to Wallbox to make eco-Smart useable through the API.

Enough bla bla, for my setup:

In the configuration I have:

input_number:
    # Wallbox        
    wallbox_charging_current_controller_k:
        name: "wallbox controller k value"
        unit_of_measurement: "A/W"
        initial: 0
        min: 0
        max: 0.1
        step: 0.001
        mode: box

sensor:
  - platform: template
    sensors:
        # solar control
        wallbox_charging_current_target:
            value_template: "{{ [[( states('sensor.actual_power') | float(0) * states('input_number.wallbox_charging_current_controller_k') | float(0) * -1.0 ) |round(0), 6] | max, 32] | min }}"

And an automation:

- id: '1654783449787'
  alias: WALLBOX - Excess solar power controller
  description: Controls the charger current to use excess solar power only (i.e. grid
    power to zero)
  trigger:
  - platform: time_pattern
    seconds: /30
  condition: []
  action:
  - service: number.set_value
    data:
      value: '{{ states(''sensor.wallbox_charging_current_target'') | float(0) | round(0)
        }}'
    target:
      entity_id: number.wallbox_portal_max_charging_current
  mode: single

That on 1 fase if I understand correctly. I am on 3 fases. Unfortunately this requires a minimum of 6a solar excess for eco smart to kick in (and 18 for the full solar). I would be great if the software would allow a 3 fase charger to “switch off” 2 of the 3 fases if solar drops but as far as I know that is not feasible today.

1 Like

So you only control the Amp’s of the wallbox? What if these drop below 6amp? Do you automatically pause charging?

So you only control the Amp’s of the wallbox? What if these drop below 6amp? Do you automatically pause charging?

No, I don’t. Charge demand less than 6A is set to 6A. Same as Wallbox ‘eco’ mode. Could automatically pause (just as Wallbox ‘green’ mode). Since the controller is not useable as it is now, I do not feel the need to implement such detail.

That on 1 fase if I understand correctly. I am on 3 fases. Unfortunately this requires a minimum of 6a solar excess for eco smart to kick in (and 18 for the full solar). I would be great if the software would allow a 3 fase charger to “switch off” 2 of the 3 fases if solar drops but as far as I know that is not feasible today.

I think that is totally feasible. But not implemented now.

Just developed something better:

A simple automation that 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.

The automation increases the max current with 1 A if the grid power is below limit 1, and decreases the max current with 1A if the grid power is above limit 2. Between the limits the max current is left alone.

I have the limit 1 set to -250 W, and the limit 2 set to 250 W. Of course this can easily be changed to other values.

I run the automation every 12 seconds, so a full sweep from 6 to 32 A would take a bit more than 5 minutes. This tames the controller. Again an actual update of the max current setting to Wallbox is only done every 30 seconds by the API. The 12 seconds value can be changes easily.

Nothing is required in the config file.

I hope I did not speak too soon. I cannot test actually charging a car because no sun on the panels anymore today :slight_smile:

The automation:

- id: '1654960233260'
  alias: WALLBOX - Charge 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
  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

Teaser:

Screenshot 2022-06-11 221935

Quick update:
Started testing with first sun on the panels this morning. The controller works like a charm. Will post some traces later.

The HA dashboard with charge mode setting is also taking shape. The principle works.

There is just one problem: it works. After me playing around last night, I left it in ‘Eco’ mode. My son came home late at night and connected a car expecting it to be fully charged early in the morning. But it only charged at 6A (eco mode), the car was not fully charged this morning. This function has it’s risks.

Traces as promised:
The controller doing it’s thing for the last 2 hours. The big dip to 6A is where the washing machine started (heating up the water), the smaller dip to 9A before that is the wife’s hairdryer.

@hesselonline
Small thing here. Not a bug, but an enhancement request. The link to GitHub you posted is for bugs only !?

The number ‘number.wallbox_portal_max_charging_current’ does not have a unit of measurement assigned by the integration, should be ‘A’.

PS
Apologies for the long message with different issues. I can’t post more than 3 consecutive messages. Interesting limitation …

3 Likes

Very interesting to see your charts @VdR

To me it seems that your choice of 12 second intervals between 1 Amp steps in charging current is just about perfect. The amount of energy exported to the grid consists of very narrow spikes so it won’t add up to much. Likewise the amount of energy imported from the grid is also very small.

Thinking back to my days at university where I learnt about PID controllers, it seems to me that you don’t have any I or any D, but just the P (proportional) component, with a 1 Amp per 12 second rate limit, acting as a low-pass filter. This keeps things very simple and it may well be good enough. Too much loop gain with higher bandwidth and you get oscillations as was happening in the earlier chart.

Great work!

Yes it seems to be tuned very well.

I believe it does have sort of an I component, the charger current keeps increasing or decreasing (1A per 12 seconds) as long there is an error (exported or imported power), but with a dead zone (-250 to 250 W), and independent of the size of the error.

There could be an optimization with the dead zone limits, depending if you want a balance between export/import, make sure you never export, or make sure you never import, the zone can be shifted. It should not be made smaller than 1A (about 230W).

Still fine tuning the ‘Green’ mode, to properly control the pause/resume.

Question to the community:
How to avoid a situation as described above with my son not getting the expected charge because of ‘green’ or ‘eco’ mode?

For context: I’m the only nerd in the family, my wife and two sons do not have HA on their phones and will not look at, let alone use, the tablet with HA interface in the kitchen.

Option 1: I can make a schedule that changes the charge mode to ‘max’ at 22:00, so any car connected will be charged the next day. Disadvantage, if I did not need the full charge, I miss the opportunity the next day to use my excess solar.

Option 2: I put a big button connected to HA (ESPHome) close the Wallbox to force ‘max’ charging (or multiple buttons to select the charge mode) in case I need it. Most other smart chargers I have seen have such a selector on the unit …

Other thoughts?

1 Like

Coming back to the power reporting bug (charge power not consistently reported by the Wallbox over WiFi). With the mode controller it is again of interest to see the charger power. So I have set up a work around that seems to do the job reasonably well.

I defined a sensor that takes the reported power, except when going zero while the status is ‘charging’, then it retains the previously reported value. This works well except at the end of the charge, because it takes a while before the status changes to ‘waiting for car demand’.

In the configuration file:

sensor:

        # alternative (advanced workaround as long as reported power is not solved)
        wallbox_portal_charging_power_w_tracked:
            value_template: >
                {% if states('sensor.wallbox_portal_status_description') == "Charging" %}
                    {% if states('sensor.wallbox_portal_charging_power_w') == "0" %}
                        {{ states('sensor.wallbox_portal_charging_power_w_tracked') | float(0) | round(0) }}
                    {% else %}
                        {{ states('sensor.wallbox_portal_charging_power_w') | float(0) | round(0) }}
                    {% endif %}
                {% else %}
                    {{ "0" }}
                {% endif %}
            unit_of_measurement: "W"

Can use this workaround until Wallbox has figured out how to send data over WiFi.

1 Like

For the empty car, does your car API report anything? EG distance driven since last charge or battery state? If so you could override solar mode based on one of those parameters. This is what I intend to do, if <50 switch to grey mode. Depending on the weather forecast I can, through a service call, also cap the battery at 50-100% to leave headroom for solar the following day.

What does your sensor “actual power” represent? Is this Amp? For me not much sense changing the amp, my max solar output is 7a so I cap mine at 6a (for green mode) and 16a (for grey off peak)

Currently I monitor the excess power generated, if it exceeds 2k watt for 2 minutes then a Boolean switches on, if again for 2 minutes, it moves below (in case charger is idle) or net consumption > 2k (if charger is charging) it switches off. These values are reported by my smart meter.

The 2 minute delay is to avoid switching too often. The Boolean subsequently triggers a pause/resume on the wallbox.

Realize I can do this more efficiently but the Boolean allows me to debug more easily

Neither of our cars (Polestar 2, Fiat 500e) have an API. I don’t think any logic can predict how the car should be charged, live has too many variables.

‘actual power’ in my case is what actually is delivered by the grid (or received when negative). It’s power in “W”. Could have used ‘actual current’, but in the end the meter meters power.

If your max solar is 7A , with the charger minimum being 6A, you indeed only need an on/off (pause/resume) controller for ‘green’ mode and a ‘max’ mode, no point to have ‘eco’ mode :slight_smile: .

I take it your solar is 7A three phase? You mentioned before that the charger current is minimum 6A per phase? That is a big disadvantage indeed. No useful ‘eco’ mode. But you switch the charger on at 2 kW, that is about 3A per phase. Starting to charge at 6A per phase immediately exceeds the 2 kW excess solar. I would expect the system to continuously switch on and off?

I should have expressed myself more clearly, sorry. That’s 3 phase indeed, so approx 2kw max solar output per fase, Total 5.8kw max, at this time of the year I generate 4kw or more between 10am and 15pm - total power generation of 40-45kwh per day at the moment. In winter this drops to as low as 100kwh per month. So very much need the off peak grey charge as well :grinning:

At 7amp per phase my car charger consumes nearly all my solar as long as nothing else is on. Eco-mode (wallbox style) works between 9am and 16pm at this time of year with limited on off switching. Did not try full green.

I would welcome the option to charge on 1 phase as it would allow me to use excess solar more optimally @Oriol_FP , is this feature being developed for the pulsar plus? EG allowing the 3 phase charger to switch to 1 phase?

Have another 3 years before net metering is phased out so no rush… :wink:

Hi Roland. The single and three phase WallBox Pulsar Plus are identical, except for the electrical grid connection. Mine is fitted with a 4 pole 63A change over switch. 1 phase - off - 3 phase. Reason for 4 pole is to also switch off the neutral when off - a requirement here… The charger automatically charges using the number of phases connected when it is powered on. I have this so I can charge (faster) using all 3 phases over night on cheap electricity, but during the day I can charge on 1 phase. Even though I have 3 phase solar (3 separate systems - no load balancing) - using only one phase lets me be sure I always have the required 1.4kW excess on this phase…

The WB app does not report 1 or 3 phase - I wonder if this info is in the API? Great if it is? Otherwise a switch on a ESP to select 1 or 3 phase charge active, and then you could do a eco charge on 3 phases by being sure there is more than 1.4kw (6A) available on each phase…

Currently I have a ESP with a 3 position switch mounted next to my WallBox - so I can select eco, emergency, night modes - and 3 LED’s to give conformation of mode selected.

eco = start @ 6A if >7A available for > 5min, then step up / down current or pause if needed to keep a 1A buffer (will eventually decrease this).
emergency = ignore solar excess and time of day and charge at max rate anyway
night = start charging after 9pm (when our electricity is cheaper)

I will eventually add a second switch mounted beside the charger to let me tell the system I am in 3 phase charge mode (but much better if this info is in the API, and then we know automatically - how can we check, or have it added??) - then I will monitor all 3 solar phases for >1.4Kw on each phase, etc. We don’t have net metering, so I would like to do this now :slight_smile:

Really interesting stuff… have just paid for the car - pickup in a few days - so can start testing soon.

I am doing this in Node-RED with HA - thanks @GrantK for pointing me in this direction… gives a nice visual representation of the logic flow…

BTW, even better yet - if the charger is wired to 3 phase, let the user select via WB app / HA API whether to charge using 1 or 3 phases - then we could automate this (if only one phase has > 1.4kW then single phase charge, if all 3 phases have > 1.4kW each, then 3 phase charge) - I wonder if WallBox is listening :slight_smile:

The 6A (1.4kW) limitation is (I understand) set by the car charging standard internationally - on single phase you need 1.4kW, and on 3 phase you need 1.4kW x 3.

2 Likes