What’s the difference between “Added Energy” and “Added Range”?
What’s the difference between the “Charging Power” and “Charging Speed”?
What’s the “current mode”?
“State of Charge” is typically understood as as the % of energy available in the battery. We don’t provide this datapoint by any means because our AC chargers don’t get this data. So, how are you getting this datapoint?
I have been able to reproduce the issue
1.1. I have not reproduced the 4 minutes pattern that VdR shared. However as my load was unable to keep at a constant rate for more than 4 minutes most of the time, it may be for this that I haven’t been able to reproduce this patter
Surprisingly, one time, the charging power stopped being reported also in the Commander 2 HMI and also App-BT. I haven’t found the reason and I was unable to reproduce it a second time.
Other topic: reported power in the app via wifi is slightly higher than the reported value on the charger(hmi) or via app-bt. This relates with another issue HA communities where reporting.
Here my next question:
How is this issue negatively impacting your user experience @Deedzy , @VdR , @GrantK , @RienduPre ? I cannot understand clearly why this is a big issue for you so I cannot really propose to our tech team to escalate this above the many other topics we need to solve.
TOPIC 3:
Happy to see you are helping each other decide the best charger to purchase Community driven sales TOP!
Originally, i’ve contacted wallbox support to talk about this issue with power and eronous measurement. i tought that was just a firmware bug and i did’nt hope anything more. I tought this issue could be corrected by an update. THEY took the problem very serious and THEY insisted to replace my wallbox. I was very sceptical but finally the replacement solved the problem. Since one month, all is fine.
I admit it’s a cosmetic issue which doesn’t stop Pulsar Plus from charging my EV. However, if Wallbox are going to provide sensors inside their chargers, they should report consistently, according to what is happening at the time; not sometimes a valid reading and sometimes zero, when nothing has actually changed.
Interesting question: “We advertise this function, we sell this function, but why do you expect it to work?”.
Well, speaking for myself, the charger is not just a dumb appliance (although it works just fine like that). The smart functions where a major reason for my choice. One of the functions is the reporting of the charge power (through the app, the HA connection is not a given). I expect that to work. The fact that the most important smart functions can only be conveniently used through BT, and thus only when standing next to the charger is a major let down for me. Would defenitely have influenced my choice if know in advance.
But to take this further. Some users (like most of the people in this discussion) are interested in the cutting edge playing field. Interested in understanding the power use of our vehicles in real time. Interested in minimizing our electricity bill. Supporting the optimal use of the electric grid. That is where the smart functions really come to play. That is why the charger should have an official supported API for integration. Unless Wallbox is happy with the dumb appliance label and the rest is for show.
I also think Wallbox should come clean on this. Is the failing power reporting issue a s/w or a h/w problem (for one poster here, replacement of the unit has resolved the issue), and is there a serious plan to resolve?
For sure we (Wallbox) need to solve this issue as it is not behaving in the expected way. I was not saying the opposite, I just want to understand the impact to facilitate the internal discussions to prioritise this fix considering the rest of things we need to solve. Check our app reviews and you will appreciate the amount of improvements we should also need to address.
I completely understand your higher expectations considering your techy profile.
We are already studying how to best approach integrations with HEMS systems like HA whether solved through API, Matter, EEBus, Modbus Sunspec, OCPP, etc… I will let you know when an official integration becomes available, if any, whenever comes.
Totally agree, we need to further research if this is a HW or SW issue. If Deedzy didn’t solve this issue even with a change of charger, looks like this makes it a SW issue.
Fully agree with @VdR - the BT only focus makes no sense. Whilst local control is great it is now restricted to an app, if anything we should have the option to control the wallbox more directly, preferably over http. Ideally the following changes would be welcomed:
More control through the cloud in favour of app only focus, well documented API (ideally possibility to setup a local API reducing dependency on cloud servers)
More flexibility to change pause / resume settings. Right now the charger starts automatically when a cable is connected and the car demands energy. I now test a number of conditions when state changes to “Charging” and failing the condition I pause the charger.
@RT1080 - I haven’t shared the source code of my Dashboard on Github because I don’t want the bother of maintaining a repo. However, I’m happy to send you the Json file.
Send me a Private Message through this page and I’ll share the link with you once I’ve prepared the file. There are a few personal ID strings I need to remove first. You’ll need Node-RED installed if you don’t already have it. I’m still using v11 and will probably stick with that version because they’ve changed some things in v12 which may be annoying.
I’m concerned about this too. Recently we had a power failure in the early morning and my Pulsar started charging when the power returned. Fortunately it was only set to 6 Amps and I noticed about 30 minutes later. But it would have been really annoying if it had spent 6 hours at 16 Amps and filled the EV battery instead of waiting for surplus solar.
I’m thinking of adding an extra switch saying ‘Disable Charging’ or something like that. If this switch is On and the status changes to ‘Charging’ I’ll stop it immediately.
I’m interested to know exactly which conditions you are checking before deciding whether to pause. As you mentioned, it would be good if the Wallbox API provided this function. Interestingly, when OCPP is enabled, charging doesn’t start by itself - the HA automation needs to do it.
Here you go, I defined eco mode as minimum 3kw solar, max 1kw grid. Green max 0.250kw grid. I have separate consumption (import) and production sensors (export). This automation triggers on either a HA restart, the wallbox state moving from anything to charging and the triggering of eco and green modes (in a scenario where it is charging at max and I want to activate either green or eco this enforces an immediate test against max grid import)
alias: Pause / Resume Wallbox - Charger connected
description: ''
trigger:
- platform: state
entity_id:
- sensor.wallbox_portal_status_description
to: Charging
for:
hours: 0
minutes: 0
seconds: 0
- platform: state
entity_id:
- input_boolean.wallbox_charger_green
to: 'on'
- platform: state
entity_id:
- input_boolean.wallbox_charger_eco
to: 'on'
- platform: homeassistant
event: start
condition:
- condition: or
conditions:
- condition: and
conditions:
- condition: state
entity_id: input_boolean.wallbox_charger_green
state: 'on'
- condition: numeric_state
entity_id: sensor.power_consumption
above: '0.250'
- condition: and
conditions:
- condition: state
entity_id: input_boolean.wallbox_charger_eco
state: 'on'
- condition: numeric_state
entity_id: sensor.power_consumption
above: '1.000'
- condition: state
entity_id: sensor.wallbox_portal_status_description
state: Charging
action:
- service: switch.turn_off
data: {}
target:
entity_id: switch.wallbox_portal_pause_resume
mode: single
Hi, these are the sensors which are being provided by the Wallbox API (wallbox · PyPI), but I do agree that not all work in my own setup. Of course, I have only 1 car and 1 charger and don’t know what works for others. State of charge indeed for example doesn’t work for me.
Would you achieve the same in a simple, intuitive way if instead of a schedule, you would give a target SoC and timestamp to achieve that SoC? The automation could then calculate the latest moment to go to ‘max’ charging to achieve the target SoC at the timestamp set and change to ‘max’ at that point. This would still require a reading of the vehicle SoC or a work around based on energy added.
I Purchased a Wallbox charger because I saw there was an integration…Big mistake . Should have read the comments more carefully. No criticism of the integration as Im certain the problems are on the wallbox end…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)
Running Home Assistant Core 2022.6.7
Home Assistant Supervisor 2022.06.2
Home Assistant OS 8.2
Wallbox version : 5.11.14
ie have just updated everything and the problems have not changed…
Simply the Wallbox Portal Pause/Resume switch does not work reliably.
If I click it to start/stop the charger for the first after 3 or 4 attempts it will switch off then turn on again. After the third or fourth attempt it will hold and and then immediately display an error “failed to call service”
Same thing happens when I am trying to turn off or on…
I promised my wife a simple automation switch on the wall that will add 100K range as the Hyundai Kona does not appear to provide SOC. The automation stops with an error as soon as it tries to turn off (pause) the charge which I am sure is related to the above problem.
I gave up on Wallbox and the Charging power issue especially after the dissapointing comment why we even want this functionality. Does not give me the feeling that the customers are respected.
One exception is @Oriol_FP of course !!
I ordered and installed a Shelly EM3, which costs me over a 100 euro to have the same functionality as Wallbox promised.
Community driven sales 