Bluetooth Low Energy (BLE), Noble, and RPi3


Hi All,

I've been doing a lot of investigation into BluetoothLE and JS/Node Red.
Noble seems to be library of choice, maybe with Noble-Device on top.
However, it strikes me that some features of BluetoothLE communications are machine-global aspects. E.g. scanning can be turned off by another (node-red-node/process), so preventing your node from working.
Discovery aspects and connections are also probably system wide.

There are a number of Node-Red nodes which use Noble (the one I'm looking at is node-red-contrib-eq3-bluetooth), and I personally intend to expand my list of BLE devices in use for home automation (temp/humidity, heating control, beacons, tags, etc.).

I've been through hoops to allow for accessing multiple devices, dealing with connect/disconnect/missconnect/distant devices which appear on scan but don't connect, and the noble bug which stops scanning when a device is discovered.

Before I embark on reworking the mentioned node to suit my nefarious purposes, I was wondering if anyone had thoughts on BluetoothLE in general with respect to NR; whether we should agree some common concept of some global structure in NR, a kind of agreed way of using Noble (and if it is the library of choice) in node-red nodes so that the nodes can 'play nicely' together; or whether this is even required?

Answers on postcards attached to this thread :).



I dislike it intensely! I find it overly complex and less than totally reliable.

I build sensor platforms using ESP8266 or ESP32 so that I can use WiFi connectivity instead of BT. May require more power (all mine are mains powered anyway) but it means that I can send data direct to an MQTT broker. This simplifies the interfaces greatly.


kind of agree; but my 10 BLE radiator valves cost me <£200 total; compared to equivalent (closed protocol anyway) wifi valves @~£50 each, economy won the day and pushed me this way.
BLE on Linux does seem very complex and immature.

One route I'm investigating is using a BluetoothLE to MQTT gateway - ESP32 is ideal for this, and gives a much more raw and controlled environment for doing the BLE work.

I'm looking into what the MQTT structure could be by prototyping such a gateway in NR, and then may look to adding it to a ESP32 port of sonoff tasmota. One concern I have is I've got a limited range of BLE devices (one type, which has a single notify characteristic which 'returns' data, and a single write characteristic to send data to it), so little experience of other real world scenarios; so in order to anticipate what may be required of such a generic interface, I will need some input.
There are a couple of ESP32 based BLE to MQTT gateway projects, but one (OpenMQTTGateway) only gets rssi (to detect range & presence); the other requires configuration for known services & characteristics - I want mine to work for ANY BLE device without further configuration (and to have a usable web UI on it, hence the tasmota base).

My current thoughts are to basically implement the important Noble calls over MQTT, on the basis that then it should cover most generic usage, but with a focus on managing the connection(s) in the ESP32 (one of the issues I've had in Noble is connection management; things like the maximum number of open connections limit, failure to connect to distant devices, etc. I've found my best policy is to connect only for as long as I need a connection - dropping 10s after the last message, and to poll devices in a staggered way to minimise demand on the number of connections).



Interesting, do you have a link to those? I'm using a Drayton Wiser system, the TRV's are currently £40 though I got some at a reduced price. The TRV's themselves work over Zigbee but the connect to the controller which, in turn, works over WiFi.

Also interesting. I recently got an M5stack as my first foray into the world of the ESP32. So I'd be interested in trying a setup like that. I have currently no idea about how to interface BTLE though. I imagine you'd need someone with a wireless analyser (at least an oscilloscope) to try and make sense of the signals being exchanged with the TRV.


I bought the TRVs here:
eq-3 bluetooth TRVs
also have two of these on order; the TRV does NOT expose ambient temp (for commercial reasons, apparently).

It does expose: Valve position. Program for each day. Target temp. Window open detection (but not telling it there is a window open?) - Basically everything in the eq-3 LCD interface can be done over BLE.

I'm currently researching BLE to MQTT gateway implementations; seeing what 'works' for people in terms of the MQTT structure.
This python project seems to be closest to the kind of thing I want to do; general BLE over MQTT (where the gateway does not need to know about the devices or their structure). So I may prototype that in NR, then see if I can implement in ESP32.

Talking to BLE is not on the face of it complex; what's evil is covering edge cases, and and deciding HOW you want to talk; e.g. connect/disconnect, or permanent connection (does this block others from connecting?); dealing with distant/intermittent devices, etc. - It's actually easy to make something work; just a lot less easy to make it work reliably and repeatably.


Good price, ridiculous overselling though. 0.1% relative humidity! It might show that visually but it is pretty impossible to actually have that accuracy outside a lab I think. Depending on the actual sensor and its mounting, you will be lucky to get +/- 5% accuracy. I can't imagine that, for the price, it is an expensive sensor. Still, likely to be good enough and certainly a neat package.


I considered a bare board - the nordic chip has temp sensor built in; but I'v far too many projects on at the moment!. just needed some easy/portable way of logging the room temp (without getting out my DS1820s & ESP8266 :slight_smile: ). It's all down to price; I could have made something for half the cost, but added 8 hours of my time!..

arrived this morning; really easy to read as the temp and humidity data is in the BLE advertisment:

As I progress with my BLE thoughts, I'll publish a BLE to MQTT flow, hopefully an ESP project which does exactly the same, and flows for the data extract....


Julian, the SHT35 from Sensirion has +- 1.5% accuracy. I have an old SHT75 here with a spec of +- 1.8%. I tested it against a saturated salt solution and it was still within 2%.
For general use I am currently using a Wemos D1 mini with SHT30 Shield (+- 3%) total cost about
£4 from AliExpress.


I occasionally run sensors side-by-side to test them. I use both BME/BMP-280's and SI2071's both of which have about the same accuracy. I will normally see around a 2% difference in output values. DHT11/22 devices are generally at least 10-20% out both from each other and from the better sensors (and they drift over time).

I've also tried the Wemos shield and it certainly didn't give an accurate figure. It appears to be affected by the temperature of the microprocessor. The sensor on my shield is an AOSONG AM2302 which is the same as a DHT22.

But that is only part of the story. Sensing humidity is notoriously difficult to do well. The outputs are sensitive to temperature differences and you will see significant differences due to housings, positions and air flow.

In no way can you realistically get relative humidity readings within a few % without great care and professional kit.

This can have a significant impact given that the recommended relative humidity levels for occupancy run between 40-60%. Rooms that are regularly >60% humidity tend to build up mold and mildew. Mold in particular is a significant health hazard if not controlled. Rooms regularly below 40% can, I believe, cause some people skin problems but can also damage furniture. High humidity generally seems to be considered the greater problem, especially in regard to health.

So sensors that are 10% or more out or badly placed could cause real issues.