Wallbox pulsar plus integration?

Very excited at what the local access could result in.
I think the MQTT access would be great so things like the status and charging current could be set to update on a set frequency.
With local access, doing things like dumping excess solar power will be so much more reliable - currently with such a long delay related to cloud control, it works for me but isn’t great.

Out of curiosity, are you also able to turn on 1 fase charging on a 3 fase charger?

Also, is it possible to keep the existing wallbox cloud connection in parallel to your local rooting solution?

I’m still under the impression that it’s not doable in software, i.e. I believe the relays are connected to the same pin on the TMS. I have not verified this however.

The cloud connection is unaffected by the rooting. The rooting can be fully undone by a restore in the app or physical button inside the box.

2 Likes

I have Wallbox Pulsar Plus paired with the power meter. I wanted to expose the power meter readings to Home Assistant for my energy dashboard and to load shed other appliances such as the heat pump water heater when I’m close to the electrical panel ampacity. Thanks @jagheterfredrik for the root access!

What I did:

  1. Installed and setup the Mosquitto broker addon following instructions at https://www.youtube.com/watch?v=dqTn-Gk4Qeo

  2. On the wallbox, in /etc/mosquitto/mosquitto.conf I added the following (don’t forget to change the Home Assistant IP address and mqtt username/password) to forward all micro2wallbox topics to the mqtt on HA:

connection bridge-ha
address 192.168.86.4:1883
remote_clientid bridge-ha
remote_username mqtt-user
remote_password mqtt-pass
topic micro2wallbox/# out 0
  1. On the Home Assistant, in /config/configuration.yaml I added:
mqtt: !include_dir_merge_named mqtt/
  1. On the Home Assistant, I created /config/mqtt/wallbox.yaml with:
binary_sensor:

  - name: "charging enable"
    unique_id: "micro2wallbox_state_values_charging_enable"
    state_topic: "micro2wallbox/state_values/charging_enable"
    value_template: "{{ value_json.samples[0].value }}"
    payload_on: "1"
    payload_off: "0"
    device_class: "running"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox

  # - name: "welding"
  #   unique_id: "micro2wallbox_state_values_welding"
  #   state_topic: "micro2wallbox/state_values/welding"
  #   value_template: "{{ value_json.samples[0].value }}"
  #   payload_on: "1"
  #   payload_off: "0"
  #   device:
  #     identifiers:
  #       - "micro2wallbox"
  #     name: micro2wallbox

sensor:

  # Based on the power limit and Power Boost
  - name: "max charging current"
    unique_id: "micro2wallbox_state_values_max_charging_current"
    state_topic: "micro2wallbox/state_values/max_charging_current"
    value_template: "{{ value_json.samples[0].value }}"
    device_class: "current"
    unit_of_measurement: "A"
    state_class: "measurement"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox

  # Based on the dip switch
  # - name: "max available current"
  #   unique_id: "micro2wallbox_state_values_max_avbl_current"
  #   state_topic: "micro2wallbox/state_values/max_avbl_current"
  #   value_template: "{{ value_json.samples[0].value }}"
  #   device_class: "current"
  #   unit_of_measurement: "A"
  #   device:
  #     identifiers:
  #       - "micro2wallbox"
  #     name: micro2wallbox

  # - name: "mid status"
  #   unique_id: "micro2wallbox_state_values_mid_status"
  #   state_topic: "micro2wallbox/state_values/mid_status"
  #   value_template: "{{ ['DISABLED', 'UNAVAILABLE', 'ENABLED_BUT_DIFFERENT_SN', 'ENABLED_BUT_COMMUNICATION_ERROR', 'ENABLED_AND_WORKING'][value_json.samples[0].value] }}"
  #   device:
  #     identifiers:
  #       - "micro2wallbox"
  #     name: micro2wallbox

  # - name: "power sharing status"
  #   unique_id: "micro2wallbox_state_values_ps_status"
  #   state_topic: "micro2wallbox/state_values/ps_status"
  #   value_template: "{{ ['STANDALONE', 'SLAVE_PAIRED', 'SLAVE_UNPAIRED', 'MASTER_READY', 'MASTER_UNCOMPLETE'][value_json.samples[0].value] }}"
  #   device:
  #     identifiers:
  #       - "micro2wallbox"
  #     name: micro2wallbox

  ###############################
  # micro2wallbox/state_values/ac
  ###############################

  - name: "ac current rms"
    unique_id: "micro2wallbox_state_values_ac_current_rms_l1"
    state_topic: "micro2wallbox/state_values/ac/ac_current_rms_l1"
    value_template: "{{ value_json.samples[0].value }}"
    device_class: "current"
    unit_of_measurement: "A"
    state_class: "measurement"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox

  - name: "ac voltage rms"
    unique_id: "micro2wallbox_state_values_ac_voltage_rms_l1"
    state_topic: "micro2wallbox/state_values/ac/ac_voltage_rms_l1"
    value_template: "{{ value_json.samples[0].value }}"
    device_class: "voltage"
    unit_of_measurement: "V"
    state_class: "measurement"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox

  # - name: "ac current freq"
  #   unique_id: "micro2wallbox_state_values_ac_current_freq_l1"
  #   state_topic: "micro2wallbox/state_values/ac/ac_current_freq_l1"
  #   value_template: "{{ value_json.samples[0].value }}"
  #   device_class: "frequency"
  #   unit_of_measurement: "Hz"
  #   device:
  #     identifiers:
  #       - "micro2wallbox"
  #     name: micro2wallbox

  # - name: "ac voltage freq"
  #   unique_id: "micro2wallbox_state_values_ac_voltage_freq_l1"
  #   state_topic: "micro2wallbox/state_values/ac/ac_voltage_freq_l1"
  #   value_template: "{{ value_json.samples[0].value }}"
  #   device_class: "frequency"
  #   unit_of_measurement: "Hz"
  #   device:
  #     identifiers:
  #       - "micro2wallbox"
  #     name: micro2wallbox

  - name: "ac temp"
    unique_id: "micro2wallbox_state_values_ac_temp_l1"
    state_topic: "micro2wallbox/state_values/ac/temp_l1"
    value_template: "{{ value_json.samples[0].value }}"
    device_class: "temperature"
    unit_of_measurement: "°C"
    state_class: "measurement"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox

  ###############################
  # Following are available only if paired with a power meter
  ###############################

  # Based on the max current per phase in the power boost settings
  - name: "icp max current"
    unique_id: "micro2wallbox_icp_max_current"
    state_topic: "micro2wallbox/icp/max_current"
    value_template: "{{ value_json.samples[0].value }}"
    device_class: "current"
    unit_of_measurement: "A"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox

  # TODO: map int value to string
  - name: "powerboost status"
    unique_id: "micro2wallbox_dca_powerboost_status"
    state_topic: "micro2wallbox/dca/powerboost_status"
    value_template: "{{ value_json.samples[0].value }}"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox

  - name: "energy"
    unique_id: "micro2wallbox_dca_energy"
    state_topic: "micro2wallbox/dca/energy"
    value_template: "{{ value_json.samples[0].value }}"
    device_class: "energy"
    unit_of_measurement: "Wh"
    state_class: "total_increasing"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox

  - name: "current amp l1"
    unique_id: "micro2wallbox_dca_current_amp_l1"
    state_topic: "micro2wallbox/dca/current_amp_l1"
    value_template: "{{ value_json.samples[0].value }}"
    device_class: "current"
    unit_of_measurement: "A"
    suggested_display_precision: 1
    state_class: "measurement"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox

  - name: "current amp l2"
    unique_id: "micro2wallbox_dca_current_amp_l2"
    state_topic: "micro2wallbox/dca/current_amp_l2"
    value_template: "{{ value_json.samples[0].value }}"
    device_class: "current"
    unit_of_measurement: "A"
    suggested_display_precision: 1
    state_class: "measurement"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox

  - name: "voltage l1"
    unique_id: "micro2wallbox_dca_voltage_l1"
    state_topic: "micro2wallbox/dca/voltage_l1"
    value_template: "{{ value_json.samples[0].value }}"
    device_class: "voltage"
    unit_of_measurement: "V"
    suggested_display_precision: 1
    state_class: "measurement"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox

  - name: "voltage l2"
    unique_id: "micro2wallbox_dca_voltage_l2"
    state_topic: "micro2wallbox/dca/voltage_l2"
    value_template: "{{ value_json.samples[0].value }}"
    device_class: "voltage"
    unit_of_measurement: "V"
    suggested_display_precision: 1
    state_class: "measurement"
    device:
      identifiers:
        - "micro2wallbox"
      name: micro2wallbox
2 Likes

Sorry for the late reply, but for some reason my whole HA setup broke and I had to reinstall everything. But to reply to your quesiton … yes I can see the SoC of the battery.

SoC of the car I can’t seem to get (Tesla) but it is set to automatically stop charging at a specific Charge leve.

How do firmware updates work? Are they installed automatically or do you have to confirm on the app? How to disable firmware updates to prevent losing root access? systemctl stop software_update.service?

I don’t think they are auto applied and even if they were shouldn’t remove root access unless the vendor actively chooses to do so.

The updates are essentially an apt get install

@tronikos - Firmware Updates are notified by the Wallbox app and also inside the MyWallbox portal but you don’t have to install them. Both of those notifications have been appearing for months now but I just ignore them.

Great to hear about Root Access now being available and many thanks for your detailed step-by-step instructions regarding MQTT. I’m still thinking about whether to install it or not. For now, the Wallbox API continues to work very well, but if that changes, I’ll look to install Root Access and change my system to local control.

Not sure if you managed to find a good implementation for this, but you can probably use NFC tags near your charger, so when one is scanned by a phone, it sets the charging for the night at full power!

Has anyone else been noticing frequent disconnections while charging, over the past few days?

The orange part of the chart shows ‘Paused’ status, and there were no disconnections for many hours before I started charging, just after 10AM (light blue colour on chart). Within less than a minute, the first disconnection occurred (purple colour on chart) and it lasted for exactly 60 seconds. Some disconnections are 30 seconds, some are 60 and some are 90 seconds.

I’ve checked my WiFi connection to the Pulsar and it is rock solid. RSSI is -58dBm and Uptime is about 2 days.

Is there an issue with tokens expiring at the Wallbox end?

P.S. I’ve just had some further thoughts about this…

*** Maybe Wallbox have changed their portal so it isn’t fully compatible with older versions of Pulsar Plus Firmware?

I am still running v5.17.44 because this was the first version in which the ‘Charging Power’ sensor worked correctly and didn’t keep resetting to zero during a charging session. Someone else on this page mentioned a while ago that this particular bug had reappeared in a later version of firmware.

*** Interested to know which firmware versions others are using, and whether or not the ‘Charging Power’ sensor works correctly. If there is a later version which works properly in this regard, maybe it’s time for me to upgrade and it might fix this new problem of frequent disconnections during charging.

Same experience. I upgraded and it’s now less of an issue.

1 Like

@RT1080 - After watching the performance of this integration for some days, I can see that the disconnections are less frequent than they were prior to the Wallbox Firmware upgrade. Intervals between disconnections are now between 1 minute and 60 minutes, with many of them being around 5 minutes. Each disconnection consistently lasts for 30, 60 or 90 seconds.

I guess, I could tolerate this situation if it gets no worse. In the medium term, the solution will no doubt be to adopt local control. Then I would no longer be at the mercy of Wallbox.

@tronikos has given some excellent instructions on how to install an MQTT broker, edit some YAML files and create the necessary sensors. It’s still unclear whether there is a Charge Current Control, or only some sensors providing monitoring of charge current.

What’s also unclear is how this local control can coexist with control via the Wallbox Cloud. Won’t there be a conflict?

I am reluctant to disable the Wallbox Cloud functions because their analysis charts are useful sometimes, and it would take a lot of work in HA to duplicate them.

I’ve spent some time studying the source code developed by @jagheterfredrik and I can understand much of what’s happening, but I don’t know enough about installing the various PIP libraries to attempt this with confidence. I’m familiar with basic Unix commands and the Bash Shell. Also, how to install Cron jobs etc. But when the instructions say: “To be uploaded to Wallbox using SCP”, I get a bit lost.

For me to make this work, I would need a set of step-by-step instructions, similar to what @tronikos wrote for the HA part.

Also, the comment “MQTT bridge … Highly experimental” doesn’t give me much confidence that I could actually get it working.

Obviously, these are early days and I need to wait patiently for a more polished integration, but there is my feedback for what it’s worth :slight_smile:

My instructions only provide read only sensors. @jagheterfredrik has provided several prototypes but are only for advanced users.

1 Like

This has been happening me also. Only fix I can find is to restore the charger and leave it on original firmware. If I upgrade to latest version it starts happening again

1 Like

The rooting does not affect cloud functionality nor does the experimental mqtt bridge. I might look into polishing it.

1 Like

Did you try the Bluetooth integration of @jagheterfredrik as well? Previously it was unstable but with recent upgrades to esp home the connection stays “alive” without interruption on my end.

1 Like

@tronikos - Thanks for explaining about the read-only sensors you’ve implemented.

After looking further, I can see the functions Lock/Unlock, Set Max Charging Current and I think Charge Enable are included in the Rest API. I am familiar with Curl so I guess I could invoke these functions using the appropriate calls from Node-RED.

However, I would prefer that they were available as Switches and Number entities in HA. Then I can monitor them and chart their history along with all other entities. So I think I’ll wait until some clever person fully integrates those additional entities into HA.

Thanks @RT1080 for reminding me about the Bluetooth integration. I would need additional hardware to implement that, so I’d prefer to stick with a WiFi connection. All necessary pieces of the puzzle will be available eventually.

@jagheterfredrik it would be great if you could put some polish on the MQTT bridge…I’d love to move to local MQTT control but not quite confident enough to do anything with it in the current state.

@yavinmaster - Please excuse me for dredging up an old thread. Elsewhere, I found where you mentioned the following…

yavinmaster** commented on Mar 17, 2022

I managed to get the Wallbox to connect to my network but not without some considerable efforts (it doesn’t seem to like Unifi’s more advanced functionality):
I had to create its own 2.4GHz wifi network, disable every advanced networking feature including minimum datarate, PFM, Group Rekey Interval, BSS Transition, UAPSD, Fast Roaming, Proxy ARP and enabling IGMP Snooping. I also had to play around until I found the Wallbox would connect on channel 11 with 20MHz bandwidth. I might be able to re-enable some of these functions but as it is just the Wallbox on this network I can’t be bothered at the moment to find out which one(s) are actually needed. I did report my findings to Wallbox but they didn’t seem to care…not been impressed by their customer service which is a shame as I quite like the product.

I have been just monitoring the Portal status description in the integration - no need to add a ping integration. So long as this isn’t “off-line” then everything is fine. I have found that it still drops out but at least it reconnects again. What is very interesting is the drop out is always around 24 minutes long.

I have just noticed that my Wallbox is doing exactly the same thing. Constant disconnections from the WiFi even though it is a very strong signal, only a few metres away. Turning the Wallbox off then on again solves the problem for a while, but eventually it reappears. Did you ever manage to fix this problem?