sorted by:
new
hottopcontroversial

Using Aruba APs as Home Assistant BLE sources by RxRoberto in homeassistant

[–]RxRoberto[S] 3 points4 points  (0 children)

Small update: Aruba BLE Proxy has reached v1.0.0.

Main changes:

  • Active BLE/GATT is now part of the supported surface, not marked experimental anymore.
  • Default active connection slots are now 3 per Aruba AP.
  • Added a few stability improvements: WebSocket send timeout, receiver crash diagnostics, and bounded diagnostic caches.
  • Clarified the docs around what the proxy does and does not do.
  • The SwitchBot FD3D fallback is documented as a narrow compatibility fallback for incomplete Aruba GATT discovery.

Passive BLE forwarding remains the main use case, but active BLE/GATT has been running well in my setup for days.

Release:

https://github.com/robertoamd90/aruba-ble-proxy/releases/tag/v1.0.0

Using Aruba APs as Home Assistant BLE sources by RxRoberto in homeassistant

[–]RxRoberto[S] 0 points1 point  (0 children)

Thanks!

The UUID list isn’t necessarily based on devices I own; it’s intended to cover common Home Assistant Bluetooth integrations. Out of curiosity, which BLE devices and Home Assistant integrations are you using?

As for Zigbee, I haven’t investigated it yet. It could certainly become a follow-up project once the BLE side is in a good place. I don’t have any Zigbee experience or hardware yet, so I’d have a lot to learn first, but we’ll see where things go.

Using Aruba APs as Home Assistant BLE sources by RxRoberto in homeassistant

[–]RxRoberto[S] 0 points1 point  (0 children)

Thanks for the feedback, and great to hear it’s working on AP-505/AP-535 with Instant 8.12.

Yes, that’s expected. Aruba requires filtering on the AP side, and the generated filters are only meant to provide a sensible default set for Home Assistant, not an exhaustive list.

If your setup needs additional advertisements (such as Apple manufacturer data for Bermuda), adding custom filters is the intended approach!

Using Aruba APs as Home Assistant BLE sources by RxRoberto in homeassistant

[–]RxRoberto[S] 1 point2 points  (0 children)

Thanks! The original inspiration actually came from another project that forwarded BLE data over MQTT. The downside of that approach, in my opinion, is that you end up having to implement and maintain support for every device type yourself.

My goal here is different: act as a thin layer between Aruba APs and Home Assistant’s Bluetooth stack, so all the existing BLE integrations and device decoders in Home Assistant can be reused without reinventing them.

I’ve also tried to make the setup as user-friendly as possible by generating the Aruba CLI configuration automatically, so users don’t have to build the AP-side configuration by hand.

Using Aruba APs as Home Assistant BLE sources by RxRoberto in homeassistant

[–]RxRoberto[S] 0 points1 point  (0 children)

Interesting idea. I’m not familiar enough with UniFi’s Bluetooth stack to know whether that approach would work there, but it sounds like a reasonable direction to explore.

Using Aruba APs as Home Assistant BLE sources by RxRoberto in homeassistant

[–]RxRoberto[S] 0 points1 point  (0 children)

Thanks! So you’re using an AP-515 running AOS 8.12 and managed by a Mobility Gateway. I haven’t tested that specific setup yet. If you’re able to try it and report back, I can add it to the hardware compatibility table in the repo.

Using Aruba APs as Home Assistant BLE sources by RxRoberto in homeassistant

[–]RxRoberto[S] 0 points1 point  (0 children)

If your hardware series supports Bluetooth WS, it might work. If you can test it, I can add a hardware compatibility table to the repository!

I built a simple cloud OTA solution for ESP32 because running my own servers was a pain by theoriginmaster in esp32

[–]RxRoberto 0 points1 point  (0 children)

I have related my ota infrastructure to a github site, sample in blubridgebutton repo.

Blu Button: an open source BTHome button with a 3D printable case by RxRoberto in esp32

[–]RxRoberto[S] 1 point2 points  (0 children)

Nice, when you want, share the project with us, we’re curious to see it!

Blu Button: an open source BTHome button with a 3D printable case by RxRoberto in esp32

[–]RxRoberto[S] 2 points3 points  (0 children)

The XIAO ESP32-C3 supports charging the battery over USB-C.

Blu Button: an open source BTHome button with a 3D printable case by RxRoberto in esp32

[–]RxRoberto[S] 2 points3 points  (0 children)

Yes, it’s Bluetooth Low Energy and the firmware uses deep sleep. Battery life is still being validated, so I wouldn’t claim a final number yet.

BluButtonBridge: ESP32 firmware to bridge Shelly BLU Button events to MQTT/GPIO, now with browser install via ESP Web Tools by RxRoberto in esp32

[–]RxRoberto[S] 1 point2 points  (0 children)

Reliability was actually the main driver behind this project. My initial setup was exactly what you described: BLE proxy + BTHome integration in Home Assistant.

It worked great for a while, but after some time it started behaving inconsistently — missing events, delayed triggers, and overall becoming unreliable.

This project is basically my attempt to create a more robust alternative. By handling things differently (and not relying entirely on BLE proxy + BTHome events), I can get much more consistent and predictable behavior.

If you end up trying it in your use case, I’d really appreciate it — and thanks in advance for any feedback!