Setup for MakerFaire 2015

At the Tinaja Labs booth, called The Sense of Things, I had a full IoT system (Internet of Things) in place. Front to back I started with wireless sensors, to a Raspberry Pi that collected sensor data, to a Beaglebone Black running Node-Red (as a signal routing application), to newly introduced inexpensive wi-fi modules (the ESP8266), and finally to old-school X-10 light switches.

I’ve always described my setup as a home automation system that is built on a wireless sensor network.  I first heard about the concept of the Internet of Things (IoT) in 2009.  Home automation and wireless sensor networks are now included in the overarching concept of IoT and includes M2M (machine to machine) and industrial applications like manufacturing systems.  IoT describes all the things that can be connected through internet technologies with sensors on one end, actuators on the other end and coordination software in the middle.

Overview of the IoT system

Download the OS image here. Read instructions here and learn about how to burn an OS image to a MicroSD card using WinDiskImager32.  More info about setting up a MicroSD card here.

The system in place includes examples of typical components of an IoT system.  On one end I had wireless sensors (based on XBee Series 1 radios), in the middle I had connecting and coordination system software (Node-Red), and on the other end I had charting and analysis (Graphite/Grafana) and actuation (wi-fi based LED control).  Pretty much, that covers the basic areas of home automation.

Code for this setup is on Github at:  TinajaLabs/makerfaire2015

Sensor PCB with XBee

the MS-1 PCB

My MS-1; a Multi-Sensor PCB w XBee.

I designed this PCB a few years ago and it still works great.  I deployed these in every room of our home.  It has a 3.3V regulator, an XBee Radio, a temperature sensor (tmp36), a light sensor (CdS cell), and headers for 2 more sensors (mostly I’ve hooked up a hall effect sensor and an FSR, force sensitive sensor).  I also included a rail to rail buffer chip to create a clean separation between the sensors.  In hind-sight I probably didn’t need that.

The sensor board schematic and the PCB layout:

MS-1 PCB Layout

MS-1 Schematic


Using XCTU, a configuration tool (available for Windows, Mac, or Linux) from Digi, I configured the XBee Series 1 radio end points like this:

AP=2
CE=0
MY=
ID=1111 (same for all radios in your system)
CH=0C (same for all radios in your system)

Wi-fi Capacitive Touch Button

Download the OS image here. Read instructions here and learn about how to burn an OS image to a MicroSD card using WinDiskImager32.  More info about setting up a MicroSD card here.

This is a new sensor setup, breadboarded, that uses a capacitive touch switch (Standalone Toggle Capacitive Touch Sensor Breakout – AT42QT1012) and an ESP8266 wi-fi PCB.  The capacitive switch responds to touch and toggles a high/low voltage  on the GPIO01 pin of the ESP8266.  The ESP8266 is programmed to send the switch’s state over wi-fi to a web service on the Node-Red software.  More about that in the Node-Red section below.
django-tagging 0.3.1 or greater

 CapSwitch-esp8266_bb

Here’s the Fritzing breadboard of the capacitive switch hooked up to an ESP8266. Find the code I used code on Github.

The Gateway “Stack”

The picture below shows what I call my gateway rack (constructed from a CD caddy and CD sized pieces of colored Plexiglas from Tap Plastics).  All of the functionality could probably be included on any one of these devices, but for the sake of experimentation and separation of functions, I set up 3 micro-computers:

  1. Raspberry Pi B+ (on red Plexiglass):  Has a GPIO board from Ciseco called the Slice of Pi that supports an xbee coordinator configured radio.  It is running  Raspbian OS and a python script that collects the serial data being collected by the XBee radio.  The metric data is collected, bundled up and formatted, and sent to a Node-Red TCP Socket module.  It also has an application named mochad-0.1.16 that provides X-10 device connectivity.
  2. Beaglebone Black (on blue Plexiglass): Running Debian Wheezy and installed with Node-Red (requires Node.js; should already be installed on Wheezy)
  3. Odroid C-1 (on orange Plexiglas): Running Ubuntu 14.04.2 LTS with Graphite and Grafana installed to provide a data store and data charting for all the sensor data.

20150802_135321

When loading up an OS on these gateway devices, the basic process is to load an image file onto a MicroSD card that stands in as the computer’s bootable hard disk.  I prefer using Win32 Disk Imager and I found ApplePi-Baker to be useful on Mac OS X.  There’s a great overview of different methods here:  http://elinux.org/RPi_Easy_SD_Card_Setup

Sensor Gateway

Download the OS image here. Read instructions here and learn about how to burn an OS image to a MicroSD card using WinDiskImager32.  More info about setting up a MicroSD card here.

The Raspberry Pi sensor gateway has a GPIO PCB from Ciseco, the Slice of Pi, that supports an xbee radio.  This XBee radio is configured to be the coordinator radio for all my XBee Sensor PCBs (described above).  There is a python script, sensorgate2.py, that reads the data being received from the XBee radio via a serial port.  Sample code on Github.

Using a software configuration tool from Digi (manufacturer of XBee radios) called X-CTU, and an XBee FTDI device (from AdaFruit, or Sparkfun – FTDI friend needed), you can set the configuration of the XBee modules.  Here are the critical settings for my setup:

AP=2
CE=1
MY=1234
ID=1111 (same for all radios in your system)
CH=0C (same for all radios in your system)

To start the python script whenever the Raspi boots up, you’ll need an init script.  Find a sample on Github.

Once you place this file in /etc/init.d, run this command:

# update-rc.d tinaja_sensor defaults

Once this is set up, the python script will start-up at boot-time, or you can manually start and stop the script when you make changes like this:

# service tinaja_sensor stop
# service tinaja_sensor start

Node-Red Gateway

This gateway was built using a BeagleBone Black, Revision B.  It is running the OS, BeagleBoard.org BeagleBone Debian.

Download the OS image here. Read instructions here and learn about how to burn an OS image to a MicroSD card using WinDiskImager32.  More info about setting up a MicroSD card here.

Download the OS image hereRead instructions here and learn about how to burn an OS image to a MicroSD card using WinDiskImager32.  More info about setting up a MicroSD card here.

Node-Red is a web based application with a drag-and-drop user interface that makes it possible to build data flows by dragging various components on to the design surface (http web services, tcp socket listeners, MQTT, functional blocks, format converters, etc.) and connecting them with rubber-band connectors that direct the “flow” of data between components. node-red-sample1

This gateway device is responsible for managing the connectivity and the logical flow between the sensors and actuators.  All of the sensors in my home direct their metric data to a web service or a simple TCP Socket which are listening within Node-Red.   From Node-Red, the data can be directed to various destinations such as a data store, a chart, an actuator such as a relay, a light switch, an alerting system, or even a controller for central heating and cooling.  These definitions are called flows and are store on disk in JSON format.

Node-Red is built on Node.js (based on Javascript) and the BeagleBone Debian Image comes with that pre-installed.  The best way to get Node-Red installed is to follow the instructions for BeagleBone Black on the Node-Red web site:  http://nodered.org/docs/hardware/beagleboneblack.html

If you’d like to use a Raspberry Pi instead of BeagleBone Black you can look at a specialized distro called TheThingBox – http://thethingbox.io/.  It is an OS image pre-loaded with Node-Red.

Node-Red Flows

A Node-Red flow is a definition of a collection of nodes modules which are strung together in Node-Red.  You can read about flows on the Node-RED site here.  and see a sampling of available nodes and flows on the Node-RED web site.  You can find some of my flows on Github.

Charting and Analytics Server

This device is an Odroid C1 running Ubuntu 14.04.  It’s basically a Raspberry Pi clone with a quad core CPU and 1G of RAM.  It can run from a MicroSD as the other micro-computers or, it can run significantly faster ( and significantly more expensively) on an eMMC memory card.  You can purchase these devices in the US from a company called Ameridroid.com.

I have utilized this server to host our data storage and to provide our charting and analysis services.  For that I use Graphite, a python based Django web application which includes a TCP socket listener, named Carbon, for all the data input and a round robin database (RRD) known as Whisper.  Graphite at its core is a capable charting application but it looks kind of dry.  To see cool looking charts with an easy to design web interface I use Grafana.

Graphite

graphite-chart

Graphite Chart Style

Grafana Chart Style

Graphite is a comprehensive application and it has a bunch of moving parts.  The basic process of setting this up is to install Graphite the various supporting components:

  • Carbon, the TCP Socket listener for all the data
  • Whisper – the round robin database
  • Graphite – the web application runs in Apache and has these prerequisites:

You can read the Graphite install instructions here.

Grafana

grafana-chart3

Grafana Chart Style

Next comes Grafana.  It is a fork of a component that comes with an application known as ELK (Elasticsearch, Logstash. Kibana).  I’ll let you figure out from which component it is derived.

When I originally installed Grafana it was with version 1.8 and it required the addition of Elasticsearch and Java.  Version 2.x does not have the Elasticsearch/Java requirement so I would recommend 2.x.  You can read about installing Grafana here.  The simple approach requires 3 commands:

# wget https://grafanarel.s3.amazonaws.com/builds/grafana_2.1.2_amd64.deb
# sudo apt-get install adduser libfontconfig
# sudo dpkg -i grafana_2.1.2.deb

Wifi Controlled Light (LED)

This setup uses an ESP8266 wi-fi device as a web server which is waiting for a URL web service request that toggles an LED on/off.  Of course the LED stands in for a relay or anything you’d like to switch on and off. You can find the code I used here.esp8266_LED_Controller

Here’s the Fritzing breadboard diagram.

What’s Next?

From here going forward, I’ve got some more projects to work on. One is to have all the system events logged and to have a voice system that announces the events; kitchen light on, garage door opened, and so on.  It’s a precursor  to a voice control system.  I’d like to set up a wall switch replacement that contains environmental sensors (temp, humidity, light, presence) and capacitor touch switches for a simple control surface.  I’d also like to manage conditioned air to each room in the house based on metrics received from the wall plate sensors in each room.  In other words it would look like a dozen very inexpensive thermostats distributed all around the house and controlling the air conditioning on a room to room basis.

If you get here and find this article meaningful but find something I could improve upon, please let me know.  Thanks.

The new Nest Learning Thermostat – $250

A friend sent me a link to this article  about the new Nest Thermostat and I got very excited; went to the site to put in my order… rrrrP!  (that’s the sound of me hitting the brakes)

$250?  Why does cool have to cost so much?

I have been building my own home wireless sensor network for the last 2 years. Temperature, light, hall effect, gas detection, FSRs, the Tweet-a-watt, etc. using XBee modules and a wifi gateway that uses an open source OS (OpenWRT) and Python scripts to send data to web services (like Pachube.com, ThingSpeak, Open.Sen.se).  I’ve been studying home energy automation for a couple of years now and I’m beginning to understand the various aspects of what it takes to put together components to collect and communicate meaningful, actionable information.

The Nest Learning Thermostat has some cool features.  It learns… and that’s fantastic.  As I understand it, you can set the thermostat up or down at different times and it will remember what you set and build a schedule that repeats your preferences. That’s very cool. It has a motion detector to sense the presence of people in the house and turns the system down/off. That’s cool, too. But there are some serious issues that I see over and over in this field.

First off this device costs too much. It should be priced at somewhere below $50 for the thermostat. That would put it at a price point to get it into the homes of many more people. The more consumers use it, the more we can reduce our dependence, as a nation, on foreign sources of energy. That’s a national, heck, a global goal, right?

Next, I don’t see any way to help consumers understand meaningful and detailed results of the savings they create by using the thermostat. They might see an overall drop in their gas or electric bill, but how much can be attributed to the thermostat as opposed to the incandescent bulbs they replaced with CFLs, or by the shading of a porch, or by being more diligent in turning off the entertainment system (including the STB) and vampire loads.

Also, the designers have created a thermostat in a very traditional form. IOW, they’re not “thinking different”. The learning aspect is interesting, but I’d rather just go to my android app, or the web site and just start with a default profile for my region, house size, etc, and adjust to taste. Otherwise, I’ll not look at it again unless there is an exception to the rules, like going on a long weekend vacation.

Similarly, the designers are stuck with the concept that we need a thermostat on the wall and that we would ever want to get up off the couch and go look at it. Why spend the effort in a device that shouldn’t even require a UI. IOW, the phone app or web page should be the preferred UI.

A “think different” approach might have a temperature sensor and a motion detector in each room and these very cheap components can inform the HVAC controls how to adjust for optimum comfort vs cost. The display and controls don’t need to be on a wall in the hallway… That’s as old as the the round Honeywell thermostats people were referencing in the comments on the Wired Magazine article.

I also believe that the display devices that you get with most home automation system, perhaps in the style of elaborate refrigerator magnets with displays, are destined, too soon, for garage sales and Goodwill stores. Let’s extend the devices that we already have for control surfaces, like tablets, smart phones, game consoles. For those who don’t have smart phones in their homes, how about something like a cheap android phone form (w/o the phone functions), music players, remote controls, wifi tether devices; any devices that can support apps.

I believe profit is deserved by all who work but how much is enough? If you look at Chris Anderson’s approach describing how to make a profit on your products (), you would sell at 2.3 times the cost of parts; and that’s a good profit margin. If I did my math right, it looks like the BOM costs about $108.

I suppose they might be adding in some of the costs of running a free web service that stores all the data so clients can see the ongoing history of their thermostat settings correlated to the temperature of their house and the local weather.

Lastly, my impression is that the design isn’t finished. Design doesn’t stop until you’ve optimized the functionality, the design, and the cost. In this era of programmable microcontrollers, arduino shields, MEMS sensors, surface mount components, standard protocols, inexpensive cloud based web services, the Internet of Things… we need to delight consumers by making the products attractive, pervasive, and affiordable…  for everybody.

http://nest.com

http://www.wired.com/gadgetlab/2011/10/nest_thermostat

http://blog.ponoko.com/2010/11/16/ten-rules-for-maker-businesses-by-wireds-chris-anderson/

WSN: Sensors

Sensors are the front line components in a wireless sensor network.  They move a response from the physical realm into the electrical realm.  Each sensor responds to some environmental events and generates a voltage or a digital signal or something that can be measured.  There’s a great list of sensors on Wikipedia (hours o’ fun).  I am constantly surprised by the seemingly endless list of sensors.

To list some things that can be sensed:

  • Temperature
  • Gas, Smoke
  • Light
  • Tilt, Acceleration
  • Proximity
  • Sound
  • Distance
  • Air pressure

Most sensors are what are defined as Passive.  Passive sensors react to some environmental stimulus and put out a signal.  Active sensors inject something into the environment and then respond to the effects created by the active aspect.  Radar is a classic example of an Active Sensor.

Because we’re talking about “wireless” sensors, it’s hard to talk about wiring up the sensors without talking about the radios that make them wireless.  We’ll focus on XBee radios but there are others that I’ll describe on the Radios post.  On many sites on the internet sensors are shown as hooked up to a microprocessor (which then connects to a radio).  I have found that for the sensors I have built so far, none have needed to use a microprocessor.  Instead, I’ve connected the sensors directly to an analog input of an XBee.  It seems you would need a microprocessor when you need to apply some kind of up front logic to a sensor’s readings.

Voltage Divider

When trying to figure out how to wire up sensors, it helps to have a basic knowledge of electronics.  The most prevalent setup in sensor networks seems to be what is called the voltage divider (see the diagram below).  There’s a lot of theory about voltage dividers but the basic idea is that you have a voltage at the top (Yin), you have 2 resisters connected inline (R1, R2) to a ground, and you have a voltage out (Vout) where the 2 resisters are joined.  The output voltage (Vout) is some value relative to the ratio of R1 and R2.

voltage divider

voltage divider

As an example, you can imagine that R1 is a sensor that varies its resistance with temperature.  If Vin is 5VDC then the Vout is going to vary dependent on the variable resistance of R1.  Vout would be connected to an input on an XBee (to send wirelessly over a radio) or connected to a microprocessor (like an Arduino) for special handling.

There’s a cool page that shows lots of different circuit layouts for various sensors on the Wiring site (Wiring is kind of like Arduino).  On this page you can select circuit types from a popup and some of the selections with display circuits.

Another great resource to get started is on Adafruit Industries’ Tutorial on Sensors which gives an overview of various sensors and how to wire them up.

The Sensors:

  • Tweet-a-Watt: The Tweet-a-Watt, originally created by Limor Fried (aka: Adafruit) is a modified Kill A Watt with an embedded XBee radio.
  • Temperature Sensor: It is relatively easy to hook up a temperature sensor to an XBee radio.
  • Gas Sensor: Hooking up a gas sensor to an XBee radio.
  • FSR Sensor (Force Sensitive Resistor): Very easy to hook up even if a bit challenging to hook up physically.  The FSR responds to pressure applied to its disk and simply changes the resistance based on the amount of pressure.

Next Tutorial Post: Tweet-a-Watt
Next Group Post: Radio XBee

Wireless Sensor Networks

This is going to be a base post (I’ll make it sticky) to hold the outline of tutorials related to various aspect of wireless sensor networks.  From the sensors and radios, to a gateway,  to web services, data logging and eventually, charting and analysis.  Look at this overview of Wireless Sensor Networks on Wikipedia.

Our interest is in developing a wireless sensor network platform that is inexpensive and simple to use.  There is a sweet spot between super high tech and older outdated technology where we believe there exists a meaningful set of technologies that will fit our goals.

XBee, Wifi, Sensors

XBee, Wifi, Sensors

What we’ve discovered is that we can use radios, like the xBee radios from Digi, with up to 4 sensors hooked up to each one, as our remote sensor boards.  We have also discovered that we can transform a wifi router into a tiny, low powered computer running an embedded, open source, operating system called OpenWRT.  Many wifi routers have a serial port available on the main pcb inside the device to which we can hook up a coordinating xBee radio; the counterpart to the ones on each sensor board.  Then we install a scripting language, Python, into the Linux operating system.  Finally, we install python scripts which can be used to collect the data being transmitted from the sensor boards and send that data to web services like Cosm (formerly Pachube), ThingSpeak, Open.sen.se, Paraimpu, etc.

So we have wireless sensor boards sending sensor data to a radio wired into the serial  port of a wifi router.  The wifi router has been re-flashed with an open source embedded Linux operating system, OpenWRT, and to that we’ve added Python as an easy to use scripting language.  We have then added various scripts to bundle the incoming data and send it to the internet for further processing, charting, and so forth.

It is an inexpensive, flexible, easy to use, wireless sensor network platform.

In this ongoing quest to learn more about sensor networks I’ll add links to the Resources Page.

Tutorials:

Here’s a list of notes we’ll be updating with information about how to build you’re own wireless sensor network.

  • WSN: Sensors: this is where is all begins.  The sensor responds to some environmental events and generates a voltage or a digital signal.  I’ll be going over a few sensor types that I’ve built; Tweet-a-watt, Temperature, Gas (example of indoor air quality), and a Force Sensitive Resistor (FSR) as an example of Elder Care.
  • Radio: XBee – Radios allow us to create the wireless part of sensor networks.  The XBee radio is very accessible to beginners even if configuration is a bit challenging.  I’ll describe the various aspects of XBee radios that I’ve used.
  • Gateway: Wifi Router – in the original design for the Tweet-a-watt the output from the sensor’s transmitter sent data to an XBee receiver hooked into a PC (via FTDI-USB).  The approach I describe uses a low powered (about 4 watts) Asus wi-fi router in place of a PC.  I’ll describe using OpenWRT as a replacement OS and adding a USB memory stick to extend the storage memory of the device.  I’ll also show how I added python with web service calls in order to send data to the internet.
  • Client facing site: a site for users to register their gateway devices and manage the sensors associated with each.  Also the place to look at the charts and subsequent analysis for the sensor data.  This is an MVC web application written in C# and ASP.NET using Visual Studio 2010 Express and SQL Server 2008 Express.

Next: WSN: Sensors