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?
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 ). 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.
I have also bought an eQ-3 device which I can currently control using the node node-red-contrib-eq3-bluetooth. There are indeed some glitches with respect to BLE which need to be fixed (see the issues I have reported in my janvda/node-red-eq3 github repository)
... I am wondering if we can't fix those issues without requiring additional hardware and complete redesign.
Maybe we need to make distinction between the following 2 use cases:
[use case 1] The only BLE devices we want to connect to are eQ-3 devices and we only want to connect to them via Node-RED.
[use case 2] Besides connecting to eQ-3 devices we want to connect to other BLE devices as well from the same device where node-red is running.
I think that first use case 1 needs to be addressed, as we already have issues with BLE when we only need to connect to one BLE device ( = eQ3 device). Once this is addressed we can further expand the use cases to connecting to multiple eQ3 devices and even to other types of BLE devices (= use case 2).
I understand that use case 2 might require a complete redesign of the solution compared to use case 1 but in order to come to a good for solution for use case 2, we must at least be able to come with a good solution for the very simple case (= use case 1 - starting with only one eQ3 device).
I am certainly willingly to contribute to this exercise.
Jan.
Hi janvda,
I have an additional use case;
A single RPi3 does not have the range to cover all 10 of my eQ-3, so I was looking into a kind of BLE bridge. I looked at the esp32, and at the time, the SDK was not stable enough for me (using the projects I tried).
Ideally, I'd like BLE over IP, and for a general NR node to take BLE either local or over IP....
Also, the temp/humidity sensors mentioned above are fairly simplistic, and easy to bring into the fold (you only need to hear the advertisments to get all the info you need), but I'm thinking a general BLE to IP would be best. Maybe the way to go would be to have a BLE bridge which would run on an ESP32, but where the same code could run on the RPI3 (preferably inside node/NR, but this brings forth the issues of multiple processes accessing BLE in Linux). Then the NR node need only deal with BLE over IP...
thoughts?
s
p.s. there is an original repo for node-red-contrib-eq3 where some discussion has taken place; but the originator no longer has a EQ3 to test against, let alone 10 :).
I understand that a single RPi3 doesn't have the range to cover all 10 of your eQ-3 devices.
... but you could of course consider multiple RPi3s each of them connecting to a subset of your 10 eQ-3 devices.
I am also not sure if you can run same code on ESP32 as on RPI3 - it seems to me that they have quite a different OS/architecture.
I would also expect that you will get more issues with BLE when using ESP32 compared to RPI3 as I think that the bluetooth libraries/support for RPI3 are far more mature than those for ESP32.
That said, I am having issues (from time to time) on RPI3 when using node-red-contrib-eq3 and only connecting to a single eQ-3 device. So my interest at this stage is to get it working properly for one device and then consider expanding it to multiple eQ-3 devices.
I admit that I also don't fully understand what the issues are with multiple processes accessing BLE in linux. Is there not a solution for that without requiring extra hardware ?
). It's all down to price; I could have made something for half the cost, but added 8 hours of my time!..
