Wallbox pulsar plus integration?

@VdR Did you manage to read the energy consumption measured by the Carlo Gavazzi Powerboost through the Wallbox?

No.

I have the Carlo Gavazzi at the mains connection (i.e. total power of the house) to realize the ‘Power Boost’ function of the Wallbox. That means the Wallbox reads the meter to throttle the charger to protect the main fuse. The Wallbox does not provide the reading of the meter. It should be possible to read the RS485 bus, I have bought an interface, but I have still not tried that.

Wallbox says that if you want an accurate charger power measurement you must connect a (second) Carlo Gavazzi at the charger connection and enable the MID meter function. That is a pricy solution that the Wallbox should provide without an external measurement.

1 Like

Probably you will find the iPhone version of the app also has the fix in the next version, but for now it’s Android only according to the release notes.

This woke up my interest in pursuing this :slight_smile:

I originally bought a RS485 to TTL converter to connect to an existing ESP8266 close to the main distribution. However since I recently moved my HA RPi close to the main distribution, I’m now looking into using an RS485 to USB converter straight on the PI, using the HA MODBUS integration.

DSD TECH SH-U11L

I have figured out the bus connection and termination requirements to add said converter to the bus (now simply connecting the EM112 to the Wallbox). But I can’t find out how to deal with the master/slave set-up.

image

Current set-up. EM 112 is terminated (pin 3) and the Wallbox must have a fixed termination. I can add the converter to the bus on the EM 112 terminals and disconnect the EM 112 termination, the converter has a fixed termination. The converter becomes the other end of the bus.

In the current set-up the Wallbox must be acting as the MODbus master (and the EM112 as a slave). But I can only find documentation of the converter also working as the bus master. And a MODbus can have only one master. Can a slave even ask for data from another slave? How is this supposed to work? Clearly no MODBus expert here.

EDIT:

I found some answers here:
https://product-help.schneider-electric.com/ED/ES_Power/NT-NW_Modbus_IEC_Guide/EDMS/DOCA0054EN/DOCA0054xx/Master_NS_Modbus_Protocol/Master_NS_Modbus_Protocol-2.htm

It confirms there can only be one master and only a master can request data.

I think you need to ‘Eavesdrop’ on the RS485 bus without transmitting anything. You should be able to see outgoing transmissions from the Wallbox followed by the corresponding responses from the EM112. This of course assumes the Wallbox is polling the EM112 regularly, but I don’t see why it wouldn’t, given that it is performing the ‘Power Boost’ function in your case. Regular monitoring of the total house consumption is essential to avoid tripping the main breaker.

This may mean that the existing HA automation is of no use unless it allows direct access to low-level single byte I/O functions of the UART. Hopefully the developer hasn’t restricted access to higher-level functions dealing only with complete MODbus transactions.

Yes, that could theoretically work. Certainly it queries the EM112 frequently, but not necessarily for all interesting data (it only need current for the power boost function). Also there does not seem to be a formal MODbus implementation for snooping.

Really the Wallbox should provide data from the EM112, but it does not, it does not even have an official API. I have come to the conclusion that the Wallbox is not the ideal connected charger.

I gave serious consideration to eavesdropping on the RS485 bus between my Solar Inverter and the Energy Meter it uses. It annoyed me that I’d already paid for an energy meter, but was unable to access the data from it.

In the end though, the simplicity and convenience of adding a Shelly EM with WiFi connection made so much sense. No need to bother with an RS485 converter, or extra wiring into the switchboard - I just placed another WiFi access point behind the wall and it communicates with 100% reliability even though the switchboard has an earthed metal enclosure because it is outside.

By the way, Oriol from Wallbox has assured me that a fix for the Pulsar Plus energy readings is currently being tested for validation. Happy days :smiley:

1 Like

You are right Shelly EM is the most effective way to go. Would program it with ESPHome for easy HA integration.

Just decided to purchase one and first test it on the Wallbox connection to finally get a reliable power reading again. Now you tell me that is going to be fixed :slight_smile: .

1 Like

A new problem has shown up.

My solar excess charging mode ‘eco’ works great, except that now the connection between the Wallbox and the HA Wallbox integration fails every 15 minutes. Then HA looses control over the charger current setting, the charging continues. Reloading the Wallbox integration immediately restores the connection.

Screenshot 2022-10-08 125340

Solar excess solar at work. 3 times on a row the connection is interrupted after exactly 15 minutes. Cant’ imagine this is the HA integration. Suspect the Wallbox cloud rejects the connection.

Anybody else seeing this?

Updating HA and a HA restart did not help.

Restarting the Wallbox (as in switching the power off and back on) does not help. Interestingly enough, the connection time is still 15 minutes even with the power off in that time, more reason to believe that the cloud just rejects the connection after 15 min.

Yeah, it’s not working today.
Works for a few minutes after restarting Homeassistant, but then all the sensors show - “unavailable” again.
The mobile app and web interface for wallbox are working.

Thanks for the conformation. I sure hope this is not the Wallbox cloud purposely disconnecting.

Same here, already was checking my wifi connection so somehow glad others have the same issue. :wink:

What would be required to use the Bluetooth connection? HA supports remote bluetooth, eg through an esp. It would be awesome if we could transform this into a completely local solution

Not elegant, and I hope this is just a fluke, but I won’t hold my breath. This workaround does the trick for me:

- id: '1665247721676'
  alias: EVSE - Reload Wallbox integration
  description: Reload the Wallbox application every 12 minutes to re-establish communication
    with the cloud
  trigger:
  - platform: time_pattern
    minutes: '/12'
  condition: []
  action:
  - service: homeassistant.reload_config_entry
    data: {}
    target:
      device_id: 4d8aaae830e5d33899abc1496d3a6f75
  mode: single
2 Likes

Thanks! Will use this for the time being.

@Oriol_FP - anything the matter with the cloud? This is highly annoying, especially with current energy prices in Europe. The whole concept of a smart ev charger is to allow users control.

On the topic of cloud independence, would wallbox be willing to share the Bluetooth keys so we can connect esphome through Bluetooth? Alternatively, is there a willingness to share the cloud api so as to allow developers to build a local api?

Any updates on earlier requests from users on this forum?

Perhaps add a trigger on a wallbox entity becoming unavailable?

trigger:
  - platform: state
    entity_id:
      - number.wallbox_portal_max_charging_current
    to: unavailable

Can confirm this works

1 Like

Yes that will work too. Since I see consistently 15 minutes, I made it proactive.

Same for me. Maybe happened after updating to 2022.10.1
Reloading the integration works for a few minutes.

I see the same behaviour. When I check the logs I see:

requests.exceptions.HTTPError: 401 Client Error: Unauthorized for url: https://api.wall-box.com/chargers/status/xxx

However reloading the integration makes everything work again.

That seems an interesting idea. Considering that we (or at least non-business users) don’t actually pay for the cloud service, I don’t see any loss from Wallbox to allow this.
@Oriol_FP is it something you guys could consider? If you remember, during our video call I mentioned that local access is one of the main topics for smart appliance users… this seems to have proven the point :slight_smile:

I had not updated to 2022.10.1 yet when it first occurred. So I do not believe it is related to the HA version.