Homie/MQTT BLE Binding

In my home I have a few devices that are out-of-BLE-range of my OH-Pi.

Thus, I am planning on developing a little Python service that connects to BLE devices based on a mac list and exposes all of their characteristics via homie, so they can be auto-discovered and added via OH all over the network. Of course the characteristics can then be written via MQTT/Homie.

Before starting/during development I wanted to user this topic to communicate feature proposals or general discussions.

Maybe there even is exactly such a service I completely missed…

reelyActive Smart Spaces Revisited might be a service that does what you are after, or at least it can be something to build upon.

thanks, but it seems like reelyActive is more for broadcast-based tracking, not low-level-characteristic access.

Also, it does not encorporate Homie.

What I have so far:
A Service that can connect to several devices based on their MACs, and auto-reconnect once connection is lost if configured so.
The service exposes all BLE Services and characteristics via Homie and makes them settable, forwarding all writes to the BLE characteristic, reconnecting to the device if needed.

That should be sufficient to control my eqiva eq3 thermostats via Openhab through a second raspberry pi running the service.

If anyone is intereseted in the code I can upload it to github.

I would be very interested in a service that handles ble over mqtt. I’m currently working on enhancing the bluetooth binding and handling ble over mqtt is on my planned feature list. I wanted to have the bluetooth binding be able to handle ble devices over mqtt. There would two key parts of the design:

  1. A the script on a remote device that handles communication between mqtt and the ble devices.
  2. A virtual bluetooth adapter in the binding that interfaces openhab with the remote devices through

Does this sound like something you would like helping me implement?

what exactly do you want to do? if you only want to write to characteristics over mqtt I am almost done.

Reading from characteristics/handling notifications would be a bit more work, but still doable for sure.

Ugh, I wrote that post late last night on my mobile phone and didn’t double check what I wrote. :slightly_frowning_face:
But yes, on the remote device side it would need to handle read/write/notifications for characteristics, report device discovery, service discovery and also advertisement packets (if possible, although just RSSI and manufacturer data would suffice).

It needs enough functionality to create a new type of bluetooth adapter in the bluetooth binding that would appear to operate just like any of the other supported adapters (bluez and bluegiga atm, although dbus might be in the works as well).

The reason for integrating into the bluetooth binding instead of just staying as mqtt homie device is that the bluetooth binding already supports an array of devices with their own bindings, if we build that extra virtual bluetooth adapter within the bluetooth binding then all the supported bluetooth devices and future supported bluetooth bindings could operate over mqtt without any of the deivce bindings being any the wiser.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.