Archive for category Data Acquisition
$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.
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:
- Gas, Smoke
- Tilt, Acceleration
- 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.
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.
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.
- 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
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.
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.
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