Thanks for engaging with the community Oriol_FP and best of luck.
Hacking update: I have gained root access on the Pulsar Plus and implemented a super hacky local HTTP API accessible over wifi that returns the charger status and can lock/unlock. If only the manufacturer could implement this 
Thank you for your contributions. I wish you success professionally and privately going forward.
Good luck indeed and thanks for engaging!
@jagheterfredrik - is this in addition to your bluetooth hack? Would be interested to try. How did you root it? Through the bt connection or does it require disassembly of the hardware?
As for the bluetooth connection, I followed the discussion on the proposed changes to the bt proxy implementation. Impressive, when do you think it’s available in the dev version of esphome?
This is separate from the Bluetooth integration. The rooting was triggered remotely and without hardware tampering and as such should go through a vulnerability disclosure process before publishing. 
Thanks! I’m blown away with the responsiveness and engagement from the devs in esphome/ha community and hope that it can land within a couple of days 
On the vulnerability disclosure, perhaps also the BT pairing is worth mentioning? The Wallbox Pulsar is very popular (at least here in the Netherlands), in my street alone there are about 5 of them installed. Effectively with the BT proxy enabled it would be possible to access these - I’m certain someone with malicious intend can go a great deal further than just turning on the charger.
Knowing this, I for one will move the wallbox to a separate VLAN and segregate it from the rest of my network 
If you want to protect the Bluetooth you can set a pin code. Download the BGXCommander app on iOS or Android, enter remote command mode and enter: bl e k <6-digit pin>. To revert, type: bl e k none.
@GrantK - good news, a fellow contributor here has supplied SH5000 data samples and my code doesn’t need updating. The SH5000 single-phase hybrid inverter will work just fine with my integration. If you do get chance to check it out, I’d be pleased to hear about your experience and any feedback.
Ok guys. What happened with the Wallbox Portal Added Range information? I have driven 2500km with my car and I’m seeing signs that tells me that I just charged extra 6000km range at night.
At the same time I’m seeing Added Energy 8,55kWh. That seems correct… but hmm…8,55kWh and 8551km. Something is now converting Added Energy to Added Range too.
@juicejuice - Excellent, thank you very much. After not having used the Redback API for over a year, it took me a while to remember how to gain access and to get the Dynamic Energy Data again. Nice to see that it works properly now, whereas last year it didn’t. I will install your integration via HACS and see how I get on.
P.S. I’ve just sent you a PM.
Many thanks again 
No change to the way my sensors are working (albeit range is not at all accurate).
Probably best to check you wallbox app and see what it shows there- might well be outside the parameters of this integration. to my knowledge there is by the way no possibility to input your cars average usage per 100km.
The wallbox has data for 69 different car models built in, e.g. KIA Niro PHEV: 153 (kWh/1000km)
This has been working normally until now. Added Range showed how much km/miles has been charged. I’m not sure how was it calculated but it was kind of nice to know information. I find nothing about “range” from wallbox side so I’m wondering if this information is gone.
What kind of car do you have?
Polestar 2.
EDIT: Wallbox was acting weird. Restarted it and we are back in business. Other bigger issue was that car was not charging anymore and it was “waiting” according wallbox.
Noticed it’s now included in the dev version, congrats!. Anything I need to change to my yaml code for the esp32 to activate the pairing?
I updated the fw based on the dev version of the esphome add-on; unfortunately still get the write error when connecting to the wallbox so clearly I am missing something.
I’ve just pushed a change to the wallbox-ble but you do need the dev version of HA as well.
Ah! That makes sense, i will wait a few more weeks in that case.
Adventure update: I started by cleaning out all Cloud services (a couple of different telemetry services talking to AWS IoT, the MyWallbox service with both REST and WS comms).
I then couldn’t stop myself from digging deeper and now have a pretty full picture of the hardware. The brains of the operation is the TMS320 Real-time MCU on the “backside” of the PCB to which the Raspberry CM talks to over Modbus-RTU.
I proceeded to map out (most of) the Modbus registers and have now replaced all Wallbox software with a Modbus-TCP bridge and can lock/unlock using it. The next “logical” step would be to make a completely custom firmware but I’m not sure it’s worth the effort.
Would that allow you to switch from 3 phase charging to 1 phase charging? Something we discussed at some stage on this thread is in order to optimize solar usage it might be beneficial to turn of 2 phases in order to reduce charging speed below 4.5kw. some people created this at a hardware level by adding relay switches but in theory it should be possible to implement this in the software.
Biggest downside i see of bypassing the wallbox software layer altogether is that it would also bypass the load balancing functionality which is quite useful to have.
I didn’t see anything related to controlling individual phases but it might be doable by tricking the dynamic power sharing.
Isn’t load balancing just changing the max current from a HA automation?