Wallbox pulsar plus integration?

[GrantK]

@Swaffhouse

The Pulsar plus is flakey on the Bluetooth and wifi despite there being an AP only a couple of meters away in the garage.(Google Home 2.4 & 5Ghz)

Welcome @Swaffhouse,

I had similar problems in the beginning until I figured out how to lock the Wallbox to a nearby 2.4GHz access point. In my case, I needed to have different SSIDs for 2.4 and 5GHz, then select the appropriate SSID within the Wallbox app. Other APs in the house all have different SSIDs on 2.4GHz, so the Wallbox won’t try to connect to them.

The nearest AP is about 3 metres away in the garage ceiling above the Wallbox. Since locking the Wallbox to that AP, all connectivity problems have completely disappeared. I get the occasional error in the HA log where the Wallbox status cannot be retrieved via the API, but that’s a cloud problem, not a local problem.

Maybe you already know about separate SSIDs but in case you don’t, I hope the info above will be helpful.

[Deedzy (Norman)]

I’m connected by Ethernet with my commander 2 and same issues I had with 3 previous Pulsar Plus units.

[VdR]

I’m sorry to see you are having problems, but I do not think all is lost.

The Wallbox seems a bit picky when it comes to the the WiFi connection, but when solved it is solid. In my case I changed the AP to a dual band, the Wallbox now connects on 5 GHz and it is solid (still use the original 2.4 GHz AP elsewhere without any issues). Check @GrantK suggestion.

There is no communication of the SoC between the car and an AC charger (any car, any EVSE). It is not clear why that data exists in the integration, it cannot work, ignore it. You can reliably use the ‘added energy’ to add 100 km range.

Note that the integration communicates with the charger only every 30 seconds. I believe that may be the reason that when you change f.i. the pause status, it changes back and then (after the communication with the charger) to what you set it to. I see the same behaviour. That is a HA oddity. It should not affect functionality.

[GrantK]

@VdR

Note that the integration communicates with the charger only every 30 seconds. I believe that may be the reason that when you change f.i. the pause status, it changes back and then (after the communication with the charger) to what you set it to. I see the same behaviour. That is a HA oddity. It should not affect functionality.

This annoying behaviour from HA was one of the main reasons I used Node-RED for my Dashboard.

I still have a Pause/Resume button but it doesn’t display any status because that will be out of sync with the charger for about 30 seconds. The way it works is like this…

1. Press Pause/Resume button
2. Status message changes to Waiting for update
3. Any further taps on Pause/Resume button are ignored until updated status is received after about 30 seconds
4. When the updated status is received from the charger, it replaces Waiting for update
5. Pause/Resume button is re-enabled

Since implementing this logic, I have not had any further occasions where the Pause/Resume button seemed to be ignored. Before then, it happened quite often, so I think multiple activations were causing the problem.

[VdR]

Smart

(post must be at least 10 characters, now it is I guess)

[ColinRobbins]

Does anyone know how the Added Range is calculated?

In my situation, is is considerably over reporting, differing from the EVs view (VW ID3) by 15%.
The number seems to come from the Wallbox API, but does not appear in the Wallbox App.
Is is something the Wallbox is able to measure? Or is it making assumptions and estimating?

[GrantK]

@ColinRobbins

Does anyone know how the Added Range is calculated

It is making an assumption and estimating. Seems to be overly optimistic for just about everybody.

This sensor, along with several others, would be better if it wasn’t there. But we are at the mercy of an upstream library used by this integration.

[Deedzy (Norman)]

I added a sensor with a more accurate distance
’ ’ ’

km added changed for Wallbox Charger

sensor:

• platform: template
  sensors:
  km_added:
  friendly_name: Km Added
  unit_of_measurement: “Km”
  value_template: >
  {{ (((states (‘sensor.wallbox_portal_added_energy’) | float ) * 6.1 ) | round | int )}}
  ’ ’ ’

[GrantK]

@Deedzy

I added a sensor with a more accurate distance.

Taking inspiration from your suggestion, I added the following template:

# Controlled Circuit Power scaled to allow for different phase
platform: template
sensors:
controlled_circuit_watts:
friendly_name: Cont Cct Watts
unit_of_measurement: “W”
value_template: >
{{ (((states ('sensor.grid_power') | float ) / 0.58 ) | round | int )}}

It worked fine in the Template Editor under Developer Tools, but the moment I tried to paste it into Configuration.yaml, I got the following error…

can not read an implicit mapping pair; a colon is missed at line 37, column 72:
     ... oat ) / 0.58 ) | round | int )}}
                             ^

A mystery as to why it would work in one place, but not the other. Hopefully, there’s something obvious I’ve done wrong.

P.S. I’ve just fixed it by doing this…

# Controlled Circuit Power scaled to allow for different phase
platform: template
sensors:
  controlled_circuit_watts:
  friendly_name: Cont Cct Watts
  unit_of_measurement: “W”
  value_template: >
    {{ (((states ('sensor.grid_power') | float ) / 0.58 ) | round | int )}}

Didn’t realise that Configuration.yaml was so fussy about indenting!

[Deedzy (Norman)]

I couldn’t work our how to keep the formatting in the post from my phone. Not sure if you can.

[GrantK]

I’m using a laptop, so it’s much easier. Sadly, my indented version still didn’t work. The File Editor said that Configuration.yaml was OK, but when I went back to check under Configuration Validation, it said the following…

Configuration invalid

Integration error: sensors - Integration 'sensors' not found.
Integration error: platform - Integration 'platform' not found.

[Deedzy (Norman)]

You need to have a proceeding
Sensor:
section or else add
Sensor:
To the start of it

[GrantK]

OK, I got it working now by using the ‘Modern Template Configuration’ as defined on this page…

Template

# Controlled Circuit Power scaled to allow for different phase
template:
  - sensor:
    - name: "controlled_circuit_watts"
      unit_of_measurement: W
      state: >
        {{ (((states ('sensor.controlled_circuit_power') | float ) / 0.58 ) | round | int )}}

I started using the ‘Legacy Template Configuration’ but it seems the Modern version is easier. Still quite difficult to debug though!

[ColinRobbins]

Thank for the suggested templates, but that still looks like an approximation, based on magic numbers ‘6.1’ or ‘5.8’ in the examples.
I think I may try something a bit more ambitious…
At the start of charging, run an automation to grab the current range of the EV into an input_number. Then use a template sensor to calculate the different between the EVs current range, and range at start of charging.
(I accept this will still be approximate, but based on the EVs own estimates).

[VdR]

The charger (EVSE) has no access to that vehicle data. So that could only work if you have an API to get that info from the car.

I use the added energy with a fudge factor to calculate added SoC percentage points, never more than 1 percentage point off. But only correct for one of our EVs.

[Swaffhouse]

Thanks Team …That makes sense. The 30 secs thing I will try and allow for in the automation.
I have a spare AP somewhere about so might set it up for the Wallabox on 2.4…Might solve a couple of issues with eWelink devices too.

[hmadsen]

Hi

Just a simple questions.

Is it possible to adjust the charge speed “on the fly” ?

I mean, would it be possible to lower or raise the charge speed while the car is connected, and charging or is it needed to stop the charging before adjusting ?

[VdR]

Yes that is possible.

[GrantK]

When my dashboard is running in 'Solar-only' mode, the charging current is often adjusted every 10 seconds and it’s no problem at all. This happens with passing clouds, people turning on a tap which starts the water pump, electric jug is boiled and so on.

The Pulsar Plus reacts to charging current changes quickly - usually within about 7 seconds. It’s only the meter readings which are delayed for about 30 seconds.

I must give credit to @VdR for sharing the original idea which I used in the algorithm controlling my dashboard. I suggest you read this post to understand what I mean…

Wallbox pulsar plus integration?

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 …

In the weeks since that post, I’ve fine-tuned the functions further, but that’s where my 'Solar-only' mode came from.

P.S. I guess you are not happy with the ‘Cheap Chinese Charger’ you bought back in March?

[GrantK]

@VdR - Sorry to see you’ve had some connection problems. Bluetooth hasn’t worked with my Pulsar Plus for months now, but WiFi has been faultless ever since I started using this integration. HA logs occasional authentication errors, but they disappear within a minute or two and only occur a few times per week.

Did you manage to solve your problem?