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.
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.
https://github.com/bendikwa/esphome-igrill/
This patch will turn on encryption when making active connections in order to co…mply with just-works BLE encryption. It would be interesting to get some input on this as I'm not sure how it affect other active devices that I assume works today?
# What does this implement/fix?
It seems that the current implementation does not correctly enable encryption and therefore fail to talk to devices that require it.
## Types of changes
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [X] Other
**Related issue or feature (if applicable):**
- https://github.com/dbuezas/eq3btsmart/issues/4
- https://github.com/bendikwa/esphome-igrill/blob/main/components/igrill/igrill.cpp#L34
## Test Environment
- [ ] ESP32
- [X] ESP32 IDF
- [ ] ESP8266
- [ ] RP2040
## Example entry for `config.yaml`:
https://esphome.github.io/bluetooth-proxies/
## Checklist:
- [X] The code change is tested and works locally.
- [X] Tests have been added to verify that the new code works (under `tests/` folder).
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated in [esphome-docs](https://github.com/esphome/esphome-docs).
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.
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"
hours: 0
minutes: 2
seconds: 0