MQTT <-> BLE gateway binding

Tags: #<Tag:0x00007fc8fb6ded88> #<Tag:0x00007fc8fb6dec98>

I’m quite new to openHAB so please excuse my rookie questions. Over the last days I have developed a little python project that provides a generic platform-independent and bidirectional gateway between a MQTT broker and BLE devices. This way, the integration of BLE devices into openHAB can be done using simple MQTT commands. I currently use it on my Raspberry 3 to control a Lixada SU-750 BLE bulb and to trigger notifications (using my Xiaomi Mi Band 1). However, as the gateway is designed generically it can be used for various applications, simply by using the correct MAC address and the UUID of the respective characteristic you are interested in. It also supports BLE notifications (for example heart rate monitoring or something similar). If you want to give it a try or see some usage examples, please look into my Github repository:

The reason I created this thread is that, in my opinion, the next logical step would be to develop a openHAB binding that makes use of my gateway to (auto)detect BLE devices and allows the user to control them directly, without the need to use custom MQTT commands (whenever possible). My idea for this is to create a binding that includes some sort of library for standardized BLE characteristics (e.g. Heart Rate Monitor) and thus directly allows to support every BLE device that follows the standard. For proprietary characteristics (e.g. step count on Xiaomi Mi Band) one could simply add some sort of mapping between the proprietary UUID of the characteristic and the functionality that is needed to make use of it. This way the binding would allow to increase the support for various BLE devices over time, without the need to implement a dedicated binding for each and every new BLE device.

To cut a long story short, do you think that such a binding has a chance to be officially accepted into the openHAB repository (given that the quality standards are fulfilled) or is the fact that it would rely on additional software (in this case my MQTT-BLE gateway) a red flag for accepting the binding?


Interesting. I have some ble temperature sensors I pull data off via the advertising data. I use mqtt as the transport. So in openHAB2 this is a version1 binding, i.e. No discovery.

I’ll keep an eye on your project as it may be usable for my devices. It depends how you communicate with the ble devices.

I think it may be intersting for you that in the some people are already working on BLE support directly in Eclipse Smarthome. You can follow the discussion in this github issue:

1 Like

My gateway relies on pygatt, which can be set up to use either BlueZ(Linux) or Bluegiga’s BGAPI (BLED112).

Thank you very much! This is exactly what I was looking for (not sure why I could not find it on my own).
If I understand it correctly, I could implement a specific binding for my MQTT-BLE gateway (after the BLE Binding is implemented), which integrates seamlessly into the architecture proposed by @Kai
In addition, I could add support for e.g. my BLE Led bulb and the Xiaomi Mi Band 1 as specific BLE device bundles.

I’m not sure I understand. I thing once the BLE binding is implemented, then BLE devices can be fully processed in ESH/OH so there should not be a need for such a gateway. What would likely be needed is an add-on binding to process specific messages from devices (ie to implement a thing handler for the devices).

The reason why I created a MQTT-BLE gateway is that, in my experience, the range of BLE devices is rather limited. Thus, I have to have several devices that are able to communicate via BLE in order to cover all of my house. My plan was to use several Raspberry Pi Zero W and connect all of them via MQTT to my central openHAB server.

As far as I understand, such a connection cannot be done using DBus.

1 Like

In this case you would likely still want to use the BLE to MQTT gateway and use the MQTT binding in OH. I don’t think it would make sense to have a MQTT implementation of a BLE bridge in the BLE binding.

But using the MQTT binding in OH would mean that you have to create a specific binding for each BLE device (using the MQTT binding) or integrate every BLE device by hand into openHAB (as I do it now).

My idea was to reuse the “add-on binding to process specific messages” in the BLE binding in order to support devices that are either controlled locally via DBus or remotely using MQTT.

So you want to send the scan packets across MQTT and not do any processing in your gateway? I see your point - although I’m still not sure it makes sense to incorporate an MQTT gateway into the BLE binding. Does your gateway handle all the connected mode functions as well or is it just looking at the beacons?

My gateway is able to scan for devices (response is the MAC addresses of all available devices including their UUIDs), subscribe/notify/write/read characteristics by their UUID. Basically the gateway is not meant to do any processing, just to forward read/writes/notifies via MQTT.

I created a small image to clearify what I would like to do:

I really like to idea of using Pi Zeros and MQTT to extend the BLE range. I was thinking about integrating a Nuimo into my openHAB environment but my openHAB server is located too far away from my living room. With this solution it could work and I can try to connect the Nuimo without full BLE support in openHAB.

Wouldn’t each ble device have very different ways of pulling data?

My ones (bluemaestro) you read from the advertising data. You couldn’t subscribe to the uuids.

Another tag I’d bought you had to send a password to it then the subscribed values would work.

I have a single pi with python scripts that send values from the devices to openHAB via Mqtt. It is quite removed from my openHAB server (i.e. Out of Bluetooth range). There could be a use for a binding that would discover remote sensors that use mqtt as a transport if they all went to the same mqtt server and used a common reporting format.

The actual collection and interaction code would be on the remote devices.

Yes, this is why a handler is required for each device. In the same way as any other device in openhab, we have a thing handler to handle the interaction.

Maybe one day Bluetooth will have some standards, but unfortunately this isn’t the case at the moment.