« Back to home

The Sensaura Project

The reason things have been quiet on this site for the past few months is because I have been working on putting together a new project called Sensaura - a scalable and extensible platform for building and deploying wireless sensors. This post provides and introduction to the goals of the project and links to the resources I've set up for it so far.

Some Background

I've noticed that many of the projects I've been working on over the past few years have a number of similar properties; most of them were small, battery powered devices sending data back over some sort of wireless connection.

I've been playing with different types of hardware with each of them - AVR, ARM or 8051 processors and a mix of NRF24L01, Bluetooth or WiFi as the network connection. The end result is a big mix of different protocols, support scripts and development tools needed to maintain them.

Sensor Network Configuration

I have managed to get everything to feed into a MQTT server so I have some level of consistancy. At the moment my rules engine is a set of Python scripts listening on various topics and generating new messages to trigger notifications and events.

The architecture as a whole is working but is hardly the cleanest solution - about 6 months ago I started sketching out a design for a more holistic solution that would be easier to extend and manage; this became the seed of the new project.

Project Goals

There were three specific problems I wanted to solve with the project - sensor hardware, a networking protocol and a rules engine for responding to and processing the data. Each of these problems is addressed by a separate component of the project.

Hardware - SensNode

I wanted a common hardware form factor that separated the three main components of remote sensor:

  1. The CPU that provides the smarts for the sensor and the networking interface that allows it to communicate with a network controller. Importantly the board should be processor agnostic and allow for different CPUs to be used depending on the target application.
  2. A power supply that can be monitored and controlled by the processor. This allows the use of USB, batteries or even solar power to be used without having to redesign the entire sensor.
  3. The sensors or actuators themselves.

Separating these tasks into individual boards allows for a mix and match approach to building up remote sensors or actuators without limiting you to a specific platform or processor.

SensNode Configurations

The specification for the form factor and the expansion header pin out is available on the project site. The form factor is designed to be small enough to be easily deployable but large enough to comfortably make the modules by hand without depending on fabricated boards. It is also breadboard friendly, using 0.1" (2.54mm) pitch headers that are spaced to allow an entire module to be inserted into a breadboard.

Networking - SensNet

One of the messier parts of deploying remote sensors is choosing how to communicate with them. I have used Bluetooth, Bluetooth LE, WiFi (802.11) and NRF24L01 based solutions in various projects in the past. Each of these has there pros and cons:

  • Bluetooth classic is easy to use on the sensor side (a simple serial interface is usually all that's required) and the modules tend to be fairly cheap. The downside is that Bluetooth APIs are not very consistant across platforms and it requires an always on connection. There is also a limit of the number of Bluetooth devices that can be connected at the same time.
  • Bluetooth LE is much nicer for sensor applications - there is no need to pair and maintain a permanent connection and the GATT attribute based protocol allows changes to values or state to be sent as they occur. Bluetooth LE modules tend to be more expensive though and many of them have an integrated CPU and require vendor specific development tools to be used.
  • WiFi connections are easy to use on the client side and devices like the ESP8266 are very cheap and easy to use. The power requirements can be an issue for battery powered devices though.

For the network implementation in Sensaura I have chosen to use a NRF24L01 based solution with a network protocol based on the Bluetooth LE GATT protocol. Each sensor exposes a set of attributes that can be read and written from the client.

SensNode Breakout

The NRF24L01 module is built in to all processor modules and networking support will be included in the API making it as easy as possible to develop wireless sensors. The image above is a simple breakout board that allows prototyping with the SensNode form factor and existing development boards as I spoke about in my last post.

Data Management - SensHub

Having sensors all over the place collecting data is great but unless there is an easy way to do something or to respond to that data. My solution to this so far has been to feed everything into a MQTT server and process the messages there.

This is a solution that has worked well for me and a model that I intend to keep - what I do want to do is make it easier to add new rules and integrations and be able to manage them all in the same place.

The solution I have for this is SensHub - an extensible service that connects to a MQTT server and allows messages to be processed through scripts or plugins. By still using MQTT as the primary transport it allows for external scripts and tools to respond to messages as well - making the migration process easier and allowing for maximum flexibility.

Sensaura Mockup

The image above shows a mockup for an early iteration of the SensHub web interface that I started implementing in Python. The intent is to not only allows you to manage sensors and build rules to respond to events but to provide a convenient place to display notifications related to the events occuring, set up dashboards to display the live data coming in from the sensors as well as managing notes and other information related to the data you are monitoring.

Project Status

With all of the features outlined above a full Sensaura based solution would look something like this:

TODO: Sensaura Architecture

Getting to this stage is still a long way off unfortunately - at the moment I am still working on migrating code from earlier projects into the Sensaura repositories and prototyping hardware designs.

Due the the large scope of the project I've decided to do all the development in public in the hopes of attracting the interest of potential contributers. Initial progress is likely to be slow and it will probably be a while before anything approaching a beta release is available.

Next Steps

For now I will be continuing with my code migration and testing and verifying the designs I already have and updating the project site accordingly.

At some stage I will have to sit down and come up with a reasonable roadmap that takes into account the time and resources I can devote to the project but will start delivering usable components as soon as possible. The SensHub component is the most likely candidate for the first beta release - it is not strongly tied to the hardware side and would be useful as tool all by itself.

In the meantime I would appreciate any feedback you might have - most of the pages on the project site have comments enabled and there is a Slack team for the project as well (you can get an invitation through this form). I'm looking forward to seeing you there.