Some questions for those that know how to build BLE sensors.

Question

I have a RPi based Hub/Gateway platform that, in a nutshell, includes a configurable rule engine so that users can build out a lot of typical IoT edge infrastructure without doing any programming. One of its major differentiators is that it comes with built-in support for a range of sensors so users basically just pick the sensors and sensor values they want to access using the Rule Engine Configuration Utility. Currently it supports about a dozen or so BLE and ANT sensors (a list is below). Once support is added for a new sensor it just becomes part of the supported sensor library from that point forward, meaning each new release should have an ever growing library of supported sensors. Adding support for a new sensor is a day or two's effort typically.

All of that said, when I started this a few years ago I envisioned a lot more generic sensors coming to the market which so far hasn't happened. Most off the shelf sensors are more meant more for prototyping than building actual systems or applications (e.g. the SensorTag, Thingy:52, etc.). Beyond that many sensors on the market are tied to their own proprietary systems or products and so it's not always easy to get all their characteristic and control/configuration information.

Ideally I'd like to support as many sensors / sensor types as possible. Hopefully (and importantly) the sensors would also be as low-cost as possible. That would make for a completely unique offering where users could really create their IoT edge infrastructure quickly and with minimal technical expertise required. So my questions for those who know about building sensors are -

How hard is it to build a simple BLE sensor from scratch? Take for instance the Garmin Tempe ANT sensor which simply reports the current temperature, if you wanted to replicate that as a BLE sensor how hard would that be?
Once you did that how hard would it be to build similar single purpose sensors to do other things, e.g. monitor for gasses, proximity, light, movement, etc.
How cheap could these types of sensors it be built at scale would you think?
Have I maybe missed a range of sensors already available that might fit the bill?
Are there any companies out there that might be open to building a line of sensors if they had a hub to support them?

Any input/observations would be appreciated and if I can answer any questions about my platform let me know (some info and links are below). Note that the main website doesn't reference a lot of new beta functionality, specifically new MQTT support. Info about that (and where it can be downloaded) can be found in a hackster.io project linked below. It'll be incorporated into the main website soon. In the interim, if you want to download the current version be sure to download it from the beta page as the version on the main website does not include any of the MQTT functionality. Anyway, thanks in advance for any replies...

Main Website

Youtube Channel

New Hackster.io MQTT project

Currently Supported Sensors:

Texas Instruments SensorTag
Nordic Thingy:52
Dialog Semiconductor DA14585
NXP RapidIoT
Sensirion Smart Gadget
Phoenix Sensors WEPS04
Vernier GDX-TMP
Generic HRM (BLE)
Generic HRM (ANT)
Garmin Tempe (ANT)

Compatible 3rd party MQTT Brokers (tested so far):

MS Azure PowerBi
IBM Watson IoT
Amazon AWS IoT
ThingsBoard.io
Ubidots
Cayenne
AdaFruit IO
BeeBotte
AllThingsTalk
Tago.io
Tinamous

aswinvenu · Accepted Answer

Hi, Great work! For building BLE enabled sensors: There are nearly a dozen of companies which make BLE solutions and there are hundreds of products (BLE enabled SoC and MCUs ) out in market. Nordic Semiconductor, Texas Instruments, Silicon Labs, Espressif andST Micro are some of them. Most all of the sensor ICs has digital communication channels like I2C, SPI or UART. Some of them will have direct analog output. If you have a BLE+MCU solution, The same MCU which hosts and controls the stack of the BLE can be used to communicate to these sensors. Let's look at BLE + MCU solutions . nRF52840 from nordic semiconductor has a BLE + Cortex M4 CPU and a handful of peripherals like I2C, SPI, UART etc. You can easily develop what ever you want on these kind of platforms. Like this there are many chips.( http://www.nordicsemi.com/-/media/Software-and-other-downloads/Product-Briefs/nRF52840-product-brief.pdf?la=en&hash=CE0F… ) esp32 from espressif - https://www.espressif.com/en/products/hardware/esp32/overview Bluegecko series of BLE solutions from Silicon Labs : https://www.silabs.com/products/wireless/bluetooth/blue-gecko-bluetooth-smart-socs CC2642 from TI : CC2642R SimpleLink Bluetooth Low Energy wireless MCU | TI.com BlueNRG series from STM : https://www.st.com/en/wireless-transceivers-mcus-and-modules/bluetooth-bluetooth-low-energy.html#overview All of these companies has cheap development/demonstration boards with lot of sensors enabled. Thunderbird Sense 2 is one of my favorite : https://www.silabs.com/products/development-tools/thunderboard/thunderboard-sense-two-kit This small piece of PCB has a handfull of sensors integrated to it. This will give you an idea of how to develop your own designs. Texas Instruments (TI) has sensor tag : CC2650 SensorTag User's Guide - Texas Instruments Wiki (CC2650 based solution) Please let me know if you want any help. Regards, Aswin

travellingkiwi · Answer

I started with mostly zWave devices on my OpenHab system. But they're terrible. I would struggle to recommend zWave to anyone for any reason apart from to increase your blood pressure maybe.

I've also tried no-name Wifi devices. They're almost as bad. Except I can monitor that a bit better.

What works for me is ESP32's with sensors attached. They're cheap, easy to program and will interface to almost anything (I try to stick to BME280's for example for Temp, Pressure and Humidity). Because you have complete control, you can fix things that annoy you rather than just kicking yourself for spending 3x the price on a half baked commercial solution that fails more often than it works. And using Mosquito (MQTT) for the comms means you only have to worry at the system end about 1 type of connectivity. And how you format the messages that are sent.

BLE? Wouldn't really touch it. Low Energy, great. Reliability - I have yet to find a reliable BlueTooth device (Although they're better than they were 15 years ago, they still struggle and debugging is not a pleasant experience).

H

Jan Cumps · Answer

The SensorTag can give you an idea of complexity. Both HW and SW are published. I see your platform supports it. You could make a simplified one with less sensors.

Jan Cumps · Answer

talatomniot wrote:

.... I saw that TI responded to your post so I'll have a look at that. Thanks!

They responded. Here's the location with the software:

BLE-STACK Bluetooth Low Energy software stack | TI.com