Interesting use case. If you’re able to use Bluetooth I can add OCPP settings as a home assistant service in my integration?
I’ve documented almost the entire protocol; wifi settings, schedules, software updates, restore, front LED setting (did you know you can dim the leds?). Let me know if there’s some specific needs.
You can control the LEDs?!?!? Friend, you’re in for a statue hahaha! 
Joking, we knew they could control all this but for some reason they keep avoiding providing control via the API.
My only fear is that they’ll stop this by implementing some extra encryption on the bluetooth interface…
Well LED on/off is available from the app but you can also set the LED brightness which I haven’t seen in the app.
Well that’s another thing I was surprised about is that a factory restore also reverts to the factory firmware.
They probably didn’t risk updating the backup partition with the previous software or made it read/only.
Thanks. I will take a look as some point.
My first issue is the distance between HA and Wallbox is too far for Bluetooth, so will need to look at proxy options.
I tried the proxy using an esp32 - whilst it automatically picked up my switch bot [pleasant surprise, forgot I had one!] it could not find the wallbox unfortunately.
Keen to hear if others are more successful and/or if you’ve taken additional steps to put the wallbox in pairing mode.
Range is not an issue here as the proxy was within one meter of the wallbox.
I was planning to run a test with the proxy eventually - I’ll try to do it today and report back.
Anybody know what are the states of entity wallbox_portal_locked_unlocked? I need for this overload automation:
alias: Wallbox overload
description: ""
trigger:
- platform: numeric_state
entity_id: sensor.power
above: "4050"
id: "off"
- platform: numeric_state
entity_id: sensor.power
below: "1000"
id: "on"
condition:
- condition: state
state: ??????
entity_id: lock.wallbox_portal_locked_unlocked
action:
- service: switch.turn_{{ trigger.id }}
target:
entity_id: switch.wallbox_portal_pause_resume
mode: single
So, I just installed an ESP32 bluetooth proxy and indeed it picked up the Wallbox immediately.
I don’t have any entity available (but they’re there!) because the car is not connected.
@RT1080 I don’t know why yours is not picking up - maybe play around with the ble proxy parameters… also, I believe it can only pick up 3 ble items at once, so it could also be that it’s overwhelmed ?
Awesome, I will tweak mine a bit further. May I ask, which MCU do you use? Can you share your esphome yaml code?
It’s Locked/Unlocked - you can test it in developer settings by checking the state.
What are you trying to achieve though? Mine is locked when charging and locked when not charging - would it not be easier to assess the status description sensor? This also shows “charging”, “waiting for car demand”, “locked, plugged in” etc.
sensor.wallbox_portal_status_description
Not using anything fancy - I just dropped a Wemos_d1_mini32 with minimal conf - relevant parts:
framework: esp-idf
And:
esp32_ble_tracker:
scan_parameters:
interval: 1100ms
window: 1100ms
active: true
bluetooth_proxy:
active: true
The entity should become available even without car connected 
I’ve got this:
But I really blamed it on the car not being connected. Once it’s back this evening I’ll re-check.
I changed the esp32 settings in line with your code - now it works. But same as you all entities are unavailable. My car is connected, charged to the max so perhaps it’s that - otherwise the bluetooth proxy element may be the cause?
Is it as intended that the bluetooth connection is fully unprotected? Eg. when my new bt proxy was onboarded the Wallbox BLE showed up as new device and was added without any input requirements - I recall when I connected the first time by phone I was prompted to provide a serial number of some sorts?
You’re right… didn’t think of that! So the whole security concept relies on their app not letting you connect to a foreign Wallbox?!?
Then all the user, password etc… on the website is just facade. If you’re in BT range you can unlock any Wallbox.
Should we notify our contact @ Wallbox about this?
Looks like Wallbox already know…
Worse, from the BT connection is seems you can recover your WiFi password!
That’s from AGES ago!
It’s not the same vulnerability, it merely points out that by using a CM4 your wallbox is exposed to anyone who would break in and open it up.
This is a whole new level.