I’ll try with a proxy later tonight. I just tested BLE Long Range and it works but is not straightforward to configure.
Security is definitely very lax on the BLE interface… I haven’t been able to extract the wifi password so that’s good 
and yes, unlocking wallboxes is definitely possible. That said, I don’t think we should continue this discussion in public.
Since this component keeps an active connection with the charger, no one else can connect 
This error originated from a custom integration.
Logger: custom_components.wallbox_ble
Source: custom_components/wallbox_ble/api.py:226
Integration: Wallbox BLE (documentation, issues)
First occurred: 13:23:50 (697 occurrences)
Last logged: 15:20:38
Failed to write to Bluetooth e=BleakError('Bluetooth GATT Error address=8C:F6: xx redact handle=23 error=15 description=Insufficient encryption')
Failed to write to Bluetooth e=BleakError('')
Failed to write to Bluetooth e=BleakError('Bluetooth GATT Error address=8C:F6:xx redact handle=23 error=133 description=Error')
Will put debug on tonight but my log is flooded with errors
I chose it bacause it’s the only way I found to have the automation always working. So I have a input boolean that switch the Wallbox and the other automation for the overload:
helper:
input_boolean:
enable_ev:
name: Enable Wallbox
icon: mdi:car
first automation:
alias: EVSE toggle
description: ""
trigger:
- platform: state
entity_id: input_boolean.toggle_ev
to: "on"
id: "on"
- platform: state
entity_id: input_boolean.toggle_ev
to: "off"
id: "off"
condition: []
action:
- service: switch.turn_{{ trigger.id }}
target:
entity_id: switch.wallbox_portal_pause_resume
mode: single
second 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
entity_id: lock.wallbox_portal_locked_unlocked
state: unlocked
action:
- service: switch.turn_{{ trigger.id }}
target:
entity_id: switch.wallbox_portal_pause_resume
mode: single
Ok, but what’s the aim? Resume/pause is only available if there is car demand. So your first automation will fail right if you trigger the helper switch in absence of demand?
Rather than testing if the charger is unlocked (which typically it won’t be if you are charging in case auto lock is enabled) would it not be easier to test if its charging?
Eg if power>4050 turn off if state = charging?
Ah, probably some differences in how pairing works with the proxy. I’ll check later
I tried your solution but in this way it can’t resume charge
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: numeric_state
entity_id: sensor.wallbox_portal_charging_power
above: 1
action:
- service: switch.turn_{{ trigger.id }}
target:
entity_id: switch.wallbox_portal_pause_resume
mode: single
I think it is pairing related. Running Bluetooth on a Linux host forces one to pair manually as well.
$ bluetoothctl
$ > pair [Wallbox mac address]
It seems pairing on esphome is still an open issue.
Did not suggest you should use that sensor, as that for sure won’t work.
Instead try:
sensor.wallbox_portal_status_description
That’s the one I use, it has various states including: “charging”, “paused”, “waiting for car demand” and a couple of others.
In your case, test if it’s paused in case of a trigger on, and if it’s charging in case of a trigger off.
That’s too bad indeed. Looking at this conceptually though, would it not be possible to run this entirely on an esphome driven esp32?
Interesting idea, I’ll think about it!
I reached the conclusion that re-implementing it as a ESPHome component is essentially just re-building the bluetooth_proxy that seems pretty solid otherwise. Instead I’ll look into submitting a patch for bluetooth_proxy to handle pairing.
Seems Home-Assistant OS pairs with everything around it automatically (crazy?) while Home-Assistant in Docker requires manual pairing (e.g. bluetoothctl pair [Wallbox BT mac]).
Yes, indeed, it picked up my front door lock as a beacon and several other devices. Quite aggressive in a way.
As for the pairing patch, curious to see the outcome. I have a couple of other devices where this is a bottleneck so perhaps your solution will pave the way there as well. The Weber igrill (bbq thermometer) doesn’t work with the proxy either because of encryption, there is an esphome solution though which works flawlessly.
Got it working over bluetooth_proxy, quite a small change but it might be a difficult push upstream if it screws up other devices…
Is the change at the level of the esp or in home assistant?
This seems work
alias: Wallbox overload
description: ""
trigger:
- platform: numeric_state
entity_id: sensor.power
above: 4050
- platform: numeric_state
entity_id: sensor.power
below: 1000
condition: []
action:
- choose:
- conditions:
- condition: state
entity_id: sensor.wallbox_portal_status_description
state: Charging
- condition: numeric_state
entity_id: sensor.power
above: 4050
sequence:
- service: switch.turn_off
data: {}
target:
entity_id: switch.wallbox_portal_pause_resume
- choose:
- conditions:
- condition: state
entity_id: sensor.wallbox_portal_status_description
state: Paused
- condition: numeric_state
entity_id: sensor.power
below: 1000
sequence:
- service: switch.turn_on
data: {}
target:
entity_id: switch.wallbox_portal_pause_resume
mode: single
Sometimes it fails due to slow reception of the on/off command, it would be much better to be able to send commands locally…
Yes, you can also add a trigger ID to the two triggers and trigger the choice on that basis.
As for the update speed, yes that’s annoying - my experience is that typically the on or off trigger are actually quite responsive (looking at impact on power consumption) but the subsequent status update of the switch is very slow. Local would be great, eagerly awaiting the results of @jagheterfredrik with respect to the bluetooth proxy.
Is this trigger right?
id: switch.turn_on.switch.wallbox_portal_pause_resume
No, it’s like this:
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: []
action:
- choose:
- conditions:
- condition: state
entity_id: sensor.wallbox_portal_status_description
state: Charging
- condition: trigger
id: "off"
sequence:
- service: switch.turn_off
data: {}
target:
entity_id: switch.wallbox_portal_pause_resume
- choose:
- conditions:
- condition: state
entity_id: sensor.wallbox_portal_status_description
state: Paused
- condition: trigger
id: "on"
sequence:
- service: switch.turn_on
data: {}
target:
entity_id: switch.wallbox_portal_pause_resume
mode: single
You now also put the automation in single mode. Meaning if an off is triggered whilst it’s still processing the on trigger it will simply stop.
Recommend to use “queued” and add some delays/wait to allow for the switch to update.
You can do the same for the on trigger to avoid rapid on/off behavior, like this:
- platform: numeric_state
entity_id: sensor.power
below: 1000
id: "on"
for:
hours: 0
minutes: 2
seconds: 0