Generic BLE subscribe/write


#1

Hi,
I’ve just built OpenMQTTGateway and blown it into an ESP32.
What I would really like to do is to write to a BLE device, and hear it’s notifications.
Is this on the plan? i.e. for generic BLE devices, not just for specific ones with specifically coded ‘drivers’ for each?
s


#2

Hi, what is the use case you are thinking about ?


#3

so, I have 10 BLE radiator valves. Not all of these are in range of my Rpi3…
So they have a characteristic which can be written, and one which gives notifications (think of it is relatively simple serial communications).
As I understand it, when you find a BLE device, you can then discover the services and characteristics, and whether they are read, write, notify, etc.
What I had imagined was that for ANY BLE device we find, we’d publish a topic to say we have it (openMQTTGateway does this…). Maybe then we’d push something to the gateway to say we’re interested in it, and at that point, the gateway would connect and examine it’s parameters, publishing information about the services and characteristics.

In my device’s case, I would then want to write to a characteristic, and to hear the responses via the notifications.
Also, in my case, I’d want it to connect only when it needed to send a message, and then stay connected for, say, 10s, in case more messages are to be sent (or to wait for the notification?).

With this type of generic setup, there would be no need for OpenMQTTGateway to understand specific devices; it would be a true gateway between protocols only.

I’d like to place maybe 3 gateways around the house to cover all the BLE devices, and then use Node-Red to deal with actually talking to the devices over MQTT…
Maybe something like https://github.com/shmuelzon/esp32-ble2mqtt ?

s


#4

This is interesting. Thanks for the idea, i will take a look


#5

I’m prototyping an MQTT representation for generic BLE in Node-Red at the moment, It may take a while, but I’ll try to post progress when I have some structure which is usable.


#6

This project https://github.com/seidler2547/ble-mqtt-bridge looks nice and waorks well, maybe some developer will be able to port this from python to arduino?


#7

It’s true that I’m biased, but what’s the problem with the esp32-ble2mqtt project? It was developed for this exact use-case, except for the part of disconnecting from the BLE peripheral.
There are multiple ways to interact with my devices and I always want to get notifications from their states so my controller will be up-to-date.


#8

it’s one of the projects i’m considering :slight_smile: (I sort of reviewed everything I could find).
I think the ‘aims to be’ put me off giving it a try right away; also I’ve been spoiled with Tasmota’s generic configuration mechanisms; but the esp32 tasmota fork is yet in its infancy.
Looking again, yours seems quite comprehensive, but maybe not as ‘raw’ as I’d like.
Ref the disconnect thing; that may be my lack of understanding of BLEs capabilities - i.e. I don’t know if my devices can have two simultaneous connections. All I do know is that Noble on RPi has problems with number of connections (5-7 breaks it), and that strange things happen with distant devices.
How many BLE devices do you use esp32-ble2mqtt with?


#9

I guess that would be bad wording on my account. Never been very articulate…
What do you mean by ‘raw’? It allows you to read/write/listen for notifications on GATT characteristics. This is regardless of the characteristics themselves, as it’s actually agnostic to them. I does have an additional layer to convert UUIDs to names and parse known characteristics by their type as defined in the BLE GATT spec. You can also add your own definitions in the configuration file. I find that’s simpler to work with than byte arrays.

Most peripherals only support one central at a time but the central can connect to many peripherals. The ESP32 (with the configuration in my project) supports up to 7 peripherals simultaneously but I admit I’ve never had so many connected at one time. My setup usually has 4 devices connected to each ESP32. If the connection drops for some reason, there’s another ESP32 nearby to pick up the slack. Since the ESP’s with an AC to DC converter are pretty cheap (~4 USD combined), I just have a bunch of them spread around.

Anyways, regardless of which solution you choose, I’d be happy for any suggestions you might have to improve the project.