Wallbox Pulsar Plus alternative to OCPP

[sweber]

Hello everyone,

here you find a little user experience and a solution to get the Wallbox Pulsar Plus working without OCPP

Introduction

me and my neighbor are using a Wallbox Pulsar Plus charger in conjunction with our SolarEdge Hybrid PV (with attached battery).
However OCPP with Pulars Plus in conjunction with evcc always gave us headaches. It wasn't working very reliable. Sometimes the charger/evcc went out of sync etc.

Solution

We stumbled across the following project https://github.com/jagheterfredrik/wallbox-mqtt-bridge/tree/main
Thus enabling the Pulsar Plus to communicate over mqtt.

I got it to work however i was facing some issues with stale values in evcc.
To fix it and making it work smoothly with evcc i forked it https://github.com/sweber/wallbox-mqtt-bridge

Advantages

With this version and the provided installation steps evcc and Pulsar Plus work like a charm. Its way more responsive than OCPP. evcc starts up very fast. And the best, no more OCPP and no more wrong protocol usage from Pulsar Plus.

Notes

Keep in mind it only works with v5.x firmware of Pulsar Plus
And yes i'm a very happy evcc user since a long time even a sponsor.

[sincze]

Great initiative.

It would be great if EVCC would be able to adopt with the original-bridge.
Like https://github.com/evcc-io/evcc/blob/master/charger/warp2.go

As mentioned here: jagheterfredrik/wallbox-mqtt-bridge#65 (comment)

[sincze]

Would you be so kind to share the working yaml ;-) config, mine currently bounces between.
"Paused" and " Waiting for Car"

Causing these messages:
wallboxcopper: charger logic error: disabled but charging
wallboxcopper: charger out of sync: expected disabled, got enabled

[sweber]

Please share your config.
Mine is available in the fork of fredriks mqtt bridge

[sincze]

meter:
  - name: wallboxcoppermeter
    type: custom
    power:
      source: mqtt
      topic: wallbox_xxxxxx/charging_power/state
    energy: # optional energy (kWh)
      source: mqtt
      topic: wallbox_xxxxxx/cumulative_added_energy/state
      scale: 0.001
    currents:
      - source: mqtt
        topic: wallbox_xxxxxxx/charging_current_l1/state
      - source: mqtt
        topic: wallbox_xxxxxx/charging_current_l2/state
      - source: mqtt
        topic: wallbox_xxxxxx/charging_current_l3/state

chargers:
  - name: wallboxcoppercharger
    type: custom
    status: # charger status A..F
      source: mqtt
      topic: evcc/input/charger_state # different topic than sweber produces!
      timeout: 0
    enabled: # charger enabled state (true/false or 0/1)
      source: mqtt
      topic: wallbox_xxxxxx/charging_enable/state
      timeout: 0
    enable: # set charger enabled state (true/false or 0/1)
      source: mqtt
      topic: wallbox_xxxxxx/charging_enable/set
      payload: ${enable:%d}
      timeout: 0
    maxcurrent:
      source: mqtt
      topic: wallbox_xxxxxx/max_charging_current/set
      timeout: 0

[sincze]

Please share your config. Mine is available in the fork of fredriks mqtt bridge

Might need to redact the second part of your config.
chargers section

[sweber]

Your problem comes from chargers: status: the mqtt topic that your are using doesn't provide the correct values.
Status needs to be A,B or C. That is only available in topic control_pilot with my version of the bridge

[mfuchs1984]

According to several users here, the wallbox works reliably with the new pulsarplus-fw5 template. Which template did you use and experience issues with?

[sincze]

Ah yes you are referring to https://docs.evcc.io/docs/devices/chargers#pulsar-plus-pulsar-max-commander-2-copper-sb-fw-5x This requires enabling OCPP, basically getting it to work and cutting off my box towards the cloud.
My friends use the cloud if they charge at my home.

As an alternative to keep the original CLOUD functionality of the wallbox, there is a guy who developed a local bridge to the wallbox via MQTT. @jagheterfredrik. It provides a lot of the data needed to get it working with EVCC however some fields are different @sweber has more experience in the field of explaining ;-)

It publishes the following:

The bridge publishes the latest state to MQTT however EVCC seems to need regular updates on the topic in order the state doesn't get stale.. I also looked at the EVCC documentation and found:

chargers:
  - name: my_charger
    type: custom
    status: # charger status A..F
      source: ...
      # ...
    enabled: # charger enabled state (true/false or 0/1)
      source: ...
      # ...
    enable: # set charger enabled state (true/false or 0/1)
      source: ...
      # ...
    maxcurrent: # set charger max current (A)
      source: ...
      # ...

With the MQTT bridge there is no status: # charger status A..F
@sweber found out that even Wallbox did not implement this correctly. It is being mapped to different string values.

var controlPilotStates = map[int]string{
	0xE:  "Error",
	0xF:  "Failure",
	0xA1: "Ready 1", // S1 at 12V, car not connected
	0xA2: "Ready 2",
	0xB1: "Connected 1", // S1 at 9V, car connected not allowed charge
	0xB2: "Connected 2", // S1 at Oscillator, car connected allowed charge
	0xC1: "Charging 1",
	0xC2: "Charging 2", // S2 closed
}

Full list is here: https://github.com/jagheterfredrik/wallbox-mqtt-bridge/blob/main/app/wallbox/wallbox_const.go

In my current struggle to get EVCC operational I have issues finding the correct MQTT messages that should be reference to enabled / enable

enabled could be:
'online' , I guess, however not accepted within the current documentation.

and
enable:

I hope I explained it a bit better??

[jagheterfredrik]

For the timeout it seems that setting it to zero disables it?

For enabled: if enabled is supposed to start/stop charging, it is slightly complicated in Wallbox:
Pseudo code would look something like:

def start():
  if car_plugged_in and not lock and not charging_enable: set_charging_enable(true);
  else: set_lock(false)

Stop looks like

def stop():
  if car_plugged_in and charging_enable: set_charging_enable(false)
  else: set_lock(true);

Note that Wallbox will automatically set charge enable to true when plugging in a car unless the Wallbox is locked.

[sincze]

tnx @jagheterfredrik, hope it will inspire the EVCC to look into it.

Regarding the meters section it should not be a problem like this:

meters:
  - name: wallboxcoppermeter
    type: custom
    power:
      source: mqtt
      topic: wallbox_******/charging_power/state
    energy: # optional energy (kWh)
      source: mqtt
      topic: wallbox_******/added_energy/state
#      scale: 0.001
    currents:
      - source: mqtt
        topic: wallbox_******/charging_current_l1/state
      - source: mqtt
        topic: wallbox_******/charging_current_l2/state
      - source: mqtt
        topic: wallbox_******/charging_current_l3/state

for chargers, still figuring it out especially regarding the payload.

#    wallbox_******/lock/state            lock*:           1       0
#    wallbox_******/status/state          status:          Locked  Ready
#    wallbox_******/charging_enable/state charging_enable: 0       1

#                                                          No      Yes
#    wallbox_******/cable_connected/state cable_connected  0       1
#
#    wallbox_******/max_charging_current/state  max_charging_current*      6
#
#    * Can be changed via MQTT by wallbox_******/topic/set

chargers:
  - name: wallboxcoppercharger
    type: custom
    status:
      source: mqtt
      topic: .....
    enabled: # charger enabled state (true/false or 0/1)
      source: mqtt
      topic: wallbox_******/charging_enable/state
    enable: # set charger enabled state (true/false or 0/1)
      source: mqtt
      topic: wallbox_******/charging_enable/set
      payload: ${enable:%d}
    maxcurrent:
      source: mqtt
      topic: wallbox_******/max_charging_current/set
    features:
      # no vehicle
      - integrateddevice
      # SoC as temperature
      - heating