Low Power Wireless Sensor and Gateway using Node-RED

I have been working on low power wireless sensor development in the past five years and would like to share some design experience with Node-RED. The wireless sensors are ultra low power. For example, the temperature sensor SVT100-T, it can send out temperature values every 10 seconds continuously and the battery life can easily last 3-4 years. The wireless vibration sensor SVT100-A working in batch mode consumes less than 0.5mA in average when taking measurements and sending out data. The battery is only half AA size (14250 battery) with 1200mAh capacity.

We want to visualize the data quickly and Node-RED fits the purpose really well. Node-RED also provides the flexibility to expand the functions and modify the flows based on users requirements. During the Node-RED development, many thanks to the help from this forum.

The wireless protocol we choose is BLE 5.0 (Bluetooth Low Energy). Many articles on the internet are outdated about BLE range. BLE5.0 can reach 1km in range in low speed mode. At 1Mbps, it can reach 300m in open space with a chip antenna. At the beginning, we used WIFI (ESP8266, ESP32) but the power consumption of WIFI is way too high for the applications. Zigbee's speed is low compared to BLE 5.0. BLE 5.0 provides relative high speed wireless transmission with very low power consumption. There are may BLE chip vendors right now. One popular BLE 5.0 chip is from Nordic Semiconductor: nrf52840. Actually, for simple task such as temperature measurement, one can just use the cheaper version nrf52832. The development kit nrf52840 DK can be purchased from Digikey or Mouser. You can download the SDK from Nordic if interested.

Multiple wireless sensors can connect to the gateway GU200. The gateway uses Raspberry Pi 3B+ or Raspberry Pi 4. We have been using Raspberry Pi 3B and Pi 3 Compute Module 3 (CM3) for industrial applications and they work well. That's why we choose Raspberry Pi 3B+ or 4 for the gateway. Why don't we use Pi 3B or CM3 for the gateway? This is because we put InfluxDB in the gateway for data storage and export. InfluxDB consumes quite some resources, especially during data input and query. When there are more than four vibration sensors sending data to GU200 at the same time, only Raspberry Pi 4 can handle it well. This why we limit the number of sensors in a group to be less than 4. We also have to limit the number points to be less than 100,000 in a query.

The following is the architecture plot of the low power wireless system.

Sensor data are transmitted to the gateway via BLE 5.0 protocol. Then the data are saved in the gateway. At the same time, the data are transferred via MQTT protocol to user's private cloud. User can also set up their own server with InfluxDB and Grafana.

The sensors and gateway are pretty reliable in our applications. Here is a picture of the sensor in action. You can see that the environment is pretty hostile.

I will focus more on the Node-RED side instead of BLE 5.0 interface between the sensors and gateway, since that part does not belong here (complicated with heavy C programming). Inside GU200, there is NRF52840 chip that interfaces with Raspberry Pi 3B+/4 with UART interface. Currently, the UART interface runs at speed of 232,400. We may bump up the speed later on after extensive testing. Because there will be more low power wireless sensors such as wireless distance sensors and strain gauges developed, the wireless incoming data length may vary. We have to customize the serial node to handle the variable data length. I will talk more about this later on. The following is a screen shot of the front panel of the dashboard.

Once data are in, they are divided based on types and drawn in the dashboard. They are saved into InfluxDB at the same time. Data can be queried and displayed again. We did not choose Grafana for the data review since we want to flexibility of more control. So we used database query and plotly to show the history data instead. Here is a screen shot of the history data:

The data query from InfluxDB can also be exported to a user's computer in CSV format. We found that the CSV node from Node-RED is little bit slow, so we write our our CSV format conversion, which only does the job of converting InfluxDB query payload to CSV format. Then you can save the payload into a file. Here is the function in case that somebody needs it.

function ConvertToCSV(objArray) {
    var array = typeof objArray != 'object' ? JSON.parse(objArray) : objArray;
    var str = '';
    for (var i = 0; i < array.length; i++) {
        var line = '';
        for (var index in array[i]) {
            if (line != '') line += ','
            line += array[i][index];
        str += line + '\r\n';
    return str;

To call the function, one can simply take the database query as the input to the function:


I would like to share a little bit more about the reason choosing BLE over other low power wireless protocols. For a comparison of wireless low power technologies in terms of range, power consumption and speed, Digikey has a very good article: Comparing Low-Power Wireless Technologies. It was written in 2017 but still valid in some key parameters. I list some of them here:

  • ANT(+): 30 m
  • 5 GHz Wi-Fi: 50 m
  • ZigBee/RF4CE: 100 m
  • BLE (Bluetooth low energy): 100 m
  • 2.4 GHz Wi-Fi: 150 m
  • BLE 5.0 extended range capability: 200 to 400 m
  • ANT+: 20 Kbits/s (in burst mode – see below), 10 Kbits/s
  • ZigBee – 250 Kbits/s (at 2.4 GHz), 200 Kbits/s
  • BLE – 1 Mbit/s, 305 Kbits/s
  • BLE 5.0 high throughput: 2 Mbits/s, 1.4 Mbits/s
  • Wi-Fi: 11 Mbits/s (lowest power 802.11b mode), 6 Mbits/s
  • ANT: Negligible
  • Wi-Fi: 1.5 milliseconds (ms)
  • BLE: 2.5 ms
  • ZigBee: 20 ms
    Therefore, for industrial IOT, it is a natural choice to pick BLE 5.0 due to its extremely low power, long range and high throughput. For low data rate applications, I would recommend to use LoRa, which consumes little power and transmits a very long range. For home automation, I may recommend Zigbee, which forms a mesh network.

Now back to the design of the wireless system, the hardware is rather straightforward. The following is the diagram for the gateway:

Note that it is important to have a RTC (Real Time Clock) for (RPI) Raspberry Pi system, since if there is no network connection, the clock of RPI may reset, which cause the chart display at Node-RED behave weirdly. It may show only a few dots of data instead of the full chart as below:


We added some analysis functions to the gateway GU200. Some of the functions are very easy to implement with Node-RED's node such as the smooth node, which has the maximum, minimum, mean, standard-deviation, high-pass filter and low-pass filter built-in. A common parameter for vibration monitoring is the RMS, which is not included in the smooth node. But it is easy to calculate the RMS from the data anyway.

1 Like

What are the cost of these devices? I didn't see anything on the web page.

1 Like

If you think you can add RMS to the smooth node then a Pull-Request would be welcome. My only concern is that the way the smooth node works is based on messages arriving - so if they don't arrive at regular intervals does that affect the calculation ?

We hope that serious customers contact us for a formal quote. I will PM you the price :grinning:

Yes I can do that. The smooth node has standard deviation already. The RMS can be done similar to the calculation of standard deviation.


Great. thanks.

The gateway can also export data into CSV format. The CSV node from Node-RED is a little bit slow when there are lots of data, and it could cause the "disconnection" error. We added a CSV format conversion function. The function codes are also provided in the top of this post. The function is very simple but relative efficient:

function ConvertToCSV(objArray) {
    var array = typeof objArray != 'object' ? JSON.parse(objArray) : objArray;
    var str = '';
    for (var i = 0; i < array.length; i++) {
        var line = '';
        for (var index in array[i]) {
            if (line != '') line += ','
            line += array[i][index];
        str += line + '\r\n';
    return str;

I have finished adding the "rms"(root mean square) to the smooth node. Please see the screen shots.
Corresponding plotting:

It behaves a lot different from "std"(standard deviation):

I don't see an option to "create a new pull request" for the "smooth" node at github. Please advise on how to update. Thanks.

1 Like

Since the original post passed the editable date, I will share some news here:

We have been working on the power consumption of the sensors in the past two months. We managed to lower the power consumption of the sensors dramatically, thanks to some professional power analysis tools such as a power analyzer or power profiler. The codes are optimized to make the power consumption minimal. The idle state of our new vibration sensor (including a high precision temperature sensor to measure the surface temperature and a high precision 3-axis accelerometer) current consumption is only at 2.3uA, as show in the picture below:

In the new design, with a 1000mAh battery, the temperature sensor can last for more than 18 years. This is a big improvement compared to 3-4 years running time mentioned at the top of the post. Of course most batteries will be obsolete after 10 years. So we just put 10 years in the battery estimate :grin:

With the much lower power consumption, we will be releasing new sensors with new features for machine condition monitoring. We can integrate high sampling rate accelerometers for continuous monitoring now.

We also have some exciting development on the gateway side using Node Red Dashboard. The new design allows more flexible sensor management.


Bluetooth may well make sense from a commercial perspective, at least as long as meshing isn't needed. However, from experience, for amateurs, it is a nightmare. cheap devices rarely work well, the protocols seem to need post-grad quantum physics and maths degrees to make sense of and all too often, devices are only partially compatible with others. The horrid tangle of BT patents and licensing doesn't help either.

Of course, it is a while since I tried anything serious with BT from an IoT perspective so perhaps things have improved a lot, but I still note that a lot of so-called BT devices such as mice and headsets come with their own dongles rather than relying on PC BT.

PS: Sorry, not getting at your solution, just making sure that there is perspective.

As long they help by providing Node-RED nodes for their sensors then all should be good…

1 Like

I am with you. The protocol is just very complicated. We had a team working on BLE since 2017 and the result was bad. The architecture was wrong and the codes were messy. The lowest power consumption they got was around 100uA and the sensors kept on resetting. Learning from previous failure, we rebuilt everything from ground at the beginning of 2020. Now we have very reliable sensors and they talk to the gateway powered by Node-RED seamlessly.

BTW, if you have JS experience, then it actually helps a lot coding BLE. Because it is completely event driven and the events are asynchronous. With this in mind, it just takes time to write good BLE applications.

Yeah I am big fan of Node-RED and the Node-RED dashboard.
The dashboard saves us lots of time bringing the product to the market.

With the time saved, we can spend more time on the low power design and the reliability of the sensors.

I do wish you the best and I recognise that BLE certainly does have some strengths in certain circumstances. Just sad that commercial IP interests seem to have intervened from the start and made a bit of a mess of things.

Ah, well time is the thing that is most in short supply!

For home automation, I'm more than happy with Wi-Fi actually, cheap (thanks to Expressif) and pretty effective (thanks at least in part to Ubiquiti).

Just getting into Zigbee and pretty impressed over all, certainly good enough for most battery sensors around the house and reasonably cheap for commercial sensors/controls as long as you shop around (thanks Ikea!). Be nice to get a Zigbee equivalent of the ESP chips though. Wasn't so impressed that it took over 3 hours to update the firmware on one of my Ikea buttons yesterday!

Don't let my negativity put you off though and thanks for sharing.

1 Like


You should have a look at some of the work they are doing with Tasmota on the ESP32 for BLE. I have one ESP32 per floor in my house running Tasmota and a heap of Xiaomi BLE wireless humidity/temp sensors scattered around.

Very impressed with the battery life (seems to be about 6 months or so on a AAA) and they pass the WAF as they have a local LCD display etc.

I am amazed at the number of devices each ESP32 picks up around the house and the distances involved.



You can also utilize LORAWAN that have good battery life and good building penetration and distance.

But each of these RF solutions have there own strengths.

Each has its own strengths. ESP series are good for makers. They are easy to use. when power is not a problem, then it can be used for industrial applications too.

As to Zigbee, its power consumption is in between WiFi and BLE. There are lots of applications with Zigbee in office environments.

For industrial IOTs and consumer wearables, BLE is everywhere. There is a huge demand for BLE. To give you an example, wind turbine blades are hard to access. It is impractical to change batteries once a year or even every two years. If the battery lasts 5-10 years, then the problem is solved.

1 Like

LoRa is another story. Much lower speed, much higher power consumption during transmission, but much longer distance. LoRaWAN is ideal for long distance low rate communication. So they have different purposes.

So LoRa can be used for gateways or sensors that only need to send out result regularly.

Perhaps things have improved then :slight_smile:

Last time I tried to play with BLE, I would be bombarded with signals from phones passing in the street 2 floors below but couldn't get a signal from on my desk! :rofl: