I have just found this sensor on Kickstarter. It supports local access and MQTT so seems perfect for openHAB.

It is a small usb powered air quality sensor.

I am a backer but otherwise not affiliated with the creators

Can you disable the cloud based options?

According to the docs when you enable MQTT the cloud is disabled automatically

Hi all,

I am one of the founders of bluSensor. I am here to answer all your questions and collect feature requests. So if you are missing any feature, just comment here.

Some answers to questions we’ve got:

Local networks
We’ve got many questions about local networks: the sensor will also connect to any local MQTT broker in your LAN. No internet required! For example, you can simply set up a mosquitto broker on your raspberry. The sensor also supports Bluetooth Low Energy and the GATT protocol is open. So you could also connect the sensor via BLE!

We’ve started writing some docs about all different APIs the sensor supports.


We also want to support mDNS and CoAP for easy integration into OpenHAB (auto-detect, etc). However, we do not have a release date yet for this.

The sensor can only connect to one cloud at a time. HomeKit and BLE will work in parallel.

Open APIs
Generally, the sensor’s interfaces are all open and can be integrated into any system. Ranging from smart home systems like OpenHAB to iOS/Android apps that you want to write. Our mission is to make the most flexible sensor.

We would love to hear what you think!


Most all homes are much larger than the range of BLE and it is not a mesh network protocol. Is it really useful in a real world smart home? Not many people set up a smart home in a birdhouse.

Actually BLE does support a mesh profile that would allow sensors like blu to operate in a Bluetooth mesh network. Whether the bluSensor supports it, I do not know. BlueZ used in Linux does support the mesh profile, but again I am unsure on how the practical implementations function.

Interestingly enough someone like Philips Hue are adding BLE to their lights in addition to ZigBee, and there are lots of sensors that now work with Bluetooth. It would not be inconceivable that those devices actually supports the mesh protocol and could then form the bases of an entire smart home.

Lots of investments are made in consumer devices that support BLE, and if the money goes there by consumers and R&D it could be the protocol of the future. The idea is not that dumb, start with a small investment that works with your phone, add to that, then later upgrade with a central controller.

Starting with the central controller is not necessarily intuitive for the average consumer. “Why do I need this box that does not do anything? I just want fancy lights and a lock that opens when I come home”. A while later, they want to open the door for a friend while on vacation and the central hub now is a good idea.

Our bluSensor AIQ supports BLE 4.2 (no mesh) and Wi-Fi (also Wi-Fi mesh theoretically).

We made AIQ to support both because we wanted to make a sensor that will work stand-alone and on the go as well as in a smart home. The user has the choice to use what will fit for his use-case.

Our next generation hygrometer, bluSensor AIR2, will support Bluetooth 5 and BLE mesh (but no Wi-Fi)
This new device will also have a long-range Bluetooth chipset (up to +19dBM) which will have a very good indoor coverage (about 100 m indoors and 500 m outdoors). This might make mesh obsolete for some homes (not all, of course). Moreover, this will run on a coin-cell battery when run as a mesh “edge node”. Mesh “networking nodes” will never run on a battery.

So it is not a true mesh but really point-to multipoint, possibly permitting edge nodes to route back to the root "networking node(s). The consumer vendors have abused the mesh networking term for point to multipoint systems. In a true mesh system all nodes can be identical hardware.

The hardware is 100% identical. Only difference is the power consumption.