Getting started with SPI & analog input in NodeJS using Raspberry Pi and MCP3008

RaspberryPi_B+_GPIO_SPI_MCP3008_breadboard_mikael-levenAlthough Raspberry Pi does not support reading analog values out-of-the-box it is quite easy to add this capability. All you need is a ADC (Analog to Digital Converter). Basically a ADC converts a analog value (between 0V – 3,3V on Raspi) and into a stream of digital “bits” (serial communication). This guide will focus on how to read analog data through the MCP3008 using NodeJS on Raspberry Pi 2. MCP3008 is a ADC that uses SPI for serial communication. Although this guide focuses specifically on MCP3008 the approach would be much the same regardless of which type of SPI device you want to connect.

One challenge when trying to read analog data through an ADC via SPI in NodeJS is the lack of code examples. Most of the guides focuses on using Python, and since I consider NodeJS to be a great companion to a Raspi my intention is to fill this information gap with this guide.

If you do not care about understanding the basics of SPI and the details of how MCP3008 (and other similar components) work, you can skip directly to the code and download my Raspberry Pi MCP3008 module and look at the example code.

The basics of SPI

SPI uses a clock signal (CLK) and two data lanes (input & output). The data wires is called MOSI (Master Out – Slave In) and MISO (Master In – Slave Out). The clock is telling the device when to send data (and determines the speed of how often this is done, i.e. the frequency). There is also a chip select which is used for the master to tell which slave device should listen and respond on the data channels (not all devices need this tough). For now we can leave the clock signal aside, just knowing it is needed. Also, the MCP3008 do require a chip select so just leave it that it is needed and let’s not dig into why and how it works. If you need a more thorough explanation and more details on how SPI works I recommend to Google it.

Why is it important to understand the basics of SPI when all you want to do is write some code and read some values? Each type of device has it’s own particular behavior or “communication protocol”, for example which bytes that trigger a read command, and because of this it is helpful to understand the differences and get the basic knowledge needed to apply the same principles on other device types.

The data part of SPI works so that the master will send out a byte (or multiple bytes) and will expect one byte back (for each byte sent). If the master sends out three bytes this will tell the slave to perform a specific action, and then the master will listen for three bytes of data sent back from the slave. This behavior can be observed in my Troubleshooting SPI on Raspberry Pi using NodeJS guide.

Knowing this we can head on and look to the specific behavior for the MCP 3008.

The specifics for MCP3008

When using a MCP3008 as a ADC you need to know four things. First of all the device has a maximum operating frequency of ~1Mhz, and depending on the framework you are using you might have to change the SPI frequency to match the device (a lower frequency will work but each reading will take longer time). Secondly you need to know that the device has 8 analog input channels. Then you need to know MCP3008 has a 10-bit resolution, which means a single byte (8 bits) is not enough to store the maximum value (1023). Finally you need to know MCP3008 will expect three bytes for each command (transfer).

When you send a command it should contain these three bytes:


Trigger is to tell the device that you (the master) expect to receive data. The second byte, mode, tells what data you want (MCP3008 supports two different modes and eight channels). The last byte is just junk (or a placeholder for the response data). The trigger should always be a 0x01 (decimal ‘1’) and the same goes for the junk byte. The mode byte should tell which channel to read (which I leave out for now).

The response of each transfer will contain the following:


First we have a junk byte, this is simply ignored. Then we have the Most Signifiant Byte (the “leftovers” when the first 8 bits is filled) and then we have the Least Significant Byte (the “least valuable” 8 bits of the totalt 10 bit value).

Sending the following three bytes would tell the ADC to begin reading data on channel 0 in normal mode.

0x01 0x80 0x01

And as a response we could have got these three bytes:

0x00 0x03 0xFF

In this example we got the highest possible value (1023 @ 10 bit). If we look at the bits of the MSB and the LSB they would look like this:

JNK = 0x00 = 00000000 (0)
MSB = 0x03 = 00000011 (3)
LSB = 0xFF = 11111111 (255)

The junk-byte and the first 6 bits of MSB is always ignored, and we are left with 10 bits (2+8).

00000000 00000011 11111111

With some bit shifting we can combine these two separate bytes into one 10-bit decimal value (actually it is 16 bits, or two bytes, but with a maximum value of 1023).

VALUE = (MSB << 8) + LSB = 1023

Wiring the MCP3008 to your Raspberry Pi

RaspberryPi_B+_GPIO_SPI_MCP3008_breadboard_mikael-levenBefore we can begin reading any data from your ADC you first have to wire the MCP3008 to the SPI pins on your Raspberry Pi (this example uses pin numbering for version 2 and B+).

Wire your Raspberry Pi to your MCP3008 accordingly to the following pin numbering (with the Raspi pins to the left and your ADC to the right):

  • Pin 19 (MOSI / #10) -> pin 11 (Din)
  • Pin 21 (MISO / #9) -> pin 12 (Dout)
  • Pin 23 (SCKL / #11) -> pin 13 (CLK)
  • Pin 24 (CD0 / #8) -> pin 10 (CS)
  • Pin 6 (GND) -> pin 14 (AGND) & 9 (DGND)

Now you should have a fully working SPI connection between your Raspi and ADC.

The code

Let’s write some code to read the values from MCP3008. At this stage you should ge seemingly random values (as you yet has no inputs connected generating any actual readings). Run the code below and you should expect and output similar to this:

ch0 = 112

Create a new NodeJS script with the following code (relies on the rpio npm library):

var rpio = require('rpio');


// Prepare TX buffer [trigger byte = 0x01] [channel 0 = 0x80 (128)] [dummy data = 0x01]
var sendBuffer = new Buffer([0x01, (8 + 0 << 4), 0x01]); 

// Send TX buffer to SPI MOSI and recieve RX buffer from MISO
var recieveBuffer = rpio.spiTransfer(sendBuffer, sendBuffer.length); 

// Extract value from output buffer. Ignore first byte (junk). 
var junk = recieveBuffer[0],
    MSB = recieveBuffer[1],
    LSB = recieveBuffer[2];

// Ignore first six bits of MSB, bit shift MSB 8 positions and 
// lastly combine LSB with MSB to get a full 10 bit value
var value = ((MSB & 3) << 8) + LSB; 

console.log('ch' + ((sendBuffer[1] >> 4) - 8), '=', value);

(you can download the source code from 

The screenshot below illustrates how the readings on all eight channels would look if they where polled repeatedly, with no input connected to the ADC, using my MCP3008 SPI Dump utility. What we see is the variation of random numbers that occur when no actual input is available.


Some actual tests

Now wire channel 0 (pin 1 on your ADC) to GND and run your script once again.


Hopefully you should now get a consistent reading close to zero (but probably not absolutely zero).

ch0 = 2

And in SPI Dump the channel 0 connected GND result would have looked like this (still random numbers for all channels but channel 0 where we have an actual input to read):


Now connect channel 0 (pin 1) to +3.3V and run the script yet again.


This time you should get 1023 (which is the maximum value and equivalent to the 3.3V reference voltage).

ch0 = 1023

And in SPI Dump the channel 0 connected to 3.3V would have resulted in a reading like this:


That’s it, now you should be up-and-running with your MCP3008 ADC reading analog values and sending them as digital numbers through SPI to your Raspberry Pi. Happy coding!


spi_exmple.js – Example script reading from channel 0 on MCP3008 using NodeJS
NodeJS SPI Dump for MCP3008 – Simple SPI dump utility for MCP3008 written in NodeJS
rpio npm package – Raspberry Pi GPIO library for NodeJS with support for SPI and I2C
Raspi SPI documentation – Details about the SPI driver on Raspberry Pi





Troubleshooting SPI on Raspberry Pi (in NodeJS)

When starting to use the SPI (Serial Peripheral Interface Bus) on the Raspberry PI, especially using NodeJS, it can be quite frustrating when you do not get any results (or get seemingly random data) without any obvious explanation or helpful error messages. Then this “SPI loopback” trick might come in handy.

Since SPI seems to be more straightforwards using Python in comparison to NodeJS I will focus the example code on NodeJS. The exact same approach should however be equally valid for Python.

Follow these steps to troubleshoot/debug your SPI connection on your Raspi:

1. First of all, make sure SPI is actually enabled

The SPI master driver is disabled by default on Raspian. To enable it, remove the blacklisting for spi-bcm2708 in /etc/modprobe.d/raspi-blacklist.conf, or use $ raspi-config.

If raspi-blacklist.conf looks something like this:

blacklist spi-bcm2708

Change it to (to prevent SPI from being blacklisted):

#blacklist spi-bcm2708

Reboot or load the driver manually with:

$ sudo modprobe spi-bcm2708

When you have followed these steps, or you simply want to check if SPI is enabled, run the following command:

$ ls /dev

The output should contain something like “spidev0.0” if SPI is indeed enabled.



2. Connect SPI in loopback / “debug mode”

SPI is using two data wires, MOSI and MISO. It might not be apparent what these abbreviations actually stand for. MOSI stands for Master Out Slave In (i.e. it is the input on whatever device you are trying to connect to your RasPi) and MISO stands for Master In Slave Out (i.e. the output of the device connected to your Pi, or we could call this “the Raspi Input”). Ok, so now we understand the meaning, but how will this help us debugging? If the MOSI is intended to receive data from your RasPi and the MISO is intended to send data back to your RasPi, we could simply jumper these two pins to get a “loopback” connection. Whatever data that is sent out from the Pi should get received back.



3. The code – test SPI using NodeJS

This example uses the rpio GPIO library for NodeJS. Copy and paste the following code into a new file (or download the gist).

var rpio = require('rpio');

var rxBuffer = rpio.spiTransfer(new Buffer('HELLOSPI'), 8);

for (var i = 0; i <= 7; i++) { 
 process.stdout.write(String.fromCharCode(rxBuffer[i]) + (i == 7 ? '\n' : ' '));

Run your script as sudo:

$ sudo node your-script.js

The result should look like this:

$ sudo node your-script.js
$ _

If you receive an error message make sure you execute node as sudo. Should you get an empty response make sure your loopback jumper wire is properly connected.

When you receive the text “H E L L O S P I” you know SPI is properly configured on your Raspberry Pi. The next step is to connect an SPI enabled device in the other end (instead of the loopback) begin writing your actual program. Good luck!

Raspberry Pi GPIO Card

RPi_B+_GPIO_Card_Mikael-LevenWhenever working with the GPIO ports of your Raspberry Pi you face challenge to remember which pin corresponds to what. E.g. which pins do I use when connecting a SPI device or where do I find the GPIO #17 pin?

To assist this I have put together a printable GPIO Card you easily can fit directly on your GPIO header. Although initially made for the 40 pin GPIO header of the A+, B+ and the version 2 model B boards, you could easily fit it on a version 1 model B rev 2 board as well (simply ignore the last 14 pins).

Check out the printable Raspberry Pi GPIO Card

Your First Raspberry Pi: A Buyer’s Guide

Pi_2_Model_BI found this great post about the choices you need to make when buying your first Raspberry Pi. Although being a great guide when deciding about which model to choose and what complementary hardware you need, it is a bit outdated. I would recommend you read the guide, however with following additions:

Model A vs A+

This is the differences with A+ compared to the initial Model A:

  • More GPIO. The GPIO header has grown to 40 pins, while retaining the same pinout for the first 26 pins as the Model A and B.
  • Micro SD. The old friction-fit SD card socket has been replaced with a much nicer push-push micro SD version.
  • Lower power consumption. By replacing linear regulators with switching ones we’ve reduced power consumption by between 0.5W and 1W.
  • Better audio. The audio circuit incorporates a dedicated low-noise power supply.
  • Smaller, neater form factor. We’ve aligned the USB connector with the board edge, moved composite video onto the 3.5mm jack, and added four squarely-placed mounting holes. Model A+ is approximately 2cm shorter than the Model A.

Recommended for embedded projects and projects which require very low power, and which do not require Ethernet or multiple USB ports.

Mode B vs B+

Model B+ should not be mixed up with the Model B Rev 2 (which is simply a slightly updated Model B rev 1with minor differences). However, the differences between Model B and B+ is on the other significant.

  • More GPIO. The GPIO header has grown to 40 pins, while retaining the same pinout for the first 26 pins as the Model A and B.
  • More USB. We now have 4 USB 2.0 ports, compared to 2 on the Model B, and better hotplug and overcurrent behaviour.
  • Micro SD. The old friction-fit SD card socket has been replaced with a much nicer push-push micro SD version.
  • Lower power consumption. By replacing linear regulators with switching ones we’ve reduced power consumption by between 0.5W and 1W.
  • Better audio. The audio circuit incorporates a dedicated low-noise power supply.
  • Neater form factor. We’ve aligned the USB connectors with the board edge, moved composite video onto the 3.5mm jack, and added four squarely-placed mounting holes.

The Model B+ is perfectly suitable for use in schools: it offers more flexibility for learners than the leaner Model A or A+, which are more useful for embedded projects and projects which require very low power, and has more USB ports than the Model B.

The New Raspberry Pi 2

The Raspberry Pi 2 is the next generation of Model B/B+, and it is not even mentioned in the original post. It basically is a beefed up Model B+ with better CPU and more RAM, making it even more suitable for HTPC, NAS and similar usages.

Because it has an (quad-core) ARMv7 processor, it can run the full range of ARM GNU/Linux distributions, including Snappy Ubuntu Core, as well as Microsoft Windows 10. And due to being more powerful the “Pi 2” will be slightly more power-hungry compared to the Model B+ (up to about 0.5-1w more), and especially compared to the Model A+.

Original post–mac-54134

Hands-on: Getting Started With Internet of Things and Home Automation

iot hubCurious about the Internet of Things and Home Automation and want to dig into it yourself, without knowing where to start?

Following my previous post, What is this (hot topic) ‘Internet of Things’?, an introduction to what Internet of Things (IoT) is all about, this guide will direct you through your first steps of how to get started with IoT and home automation. There is lot’s of great how-to tutorials out there covering various topics, products etc, and I have no attention to write yet another detailed tutorial on any of these subjects. However what I personally find missing is a great overview when you need to get started. And that’s what I aim to cover. What are the options? Which products do you need and what are the alternatives? Is there anything particular you need to know? What skills do you need? There is a lot of those questions that is hard to grasp when you are new to this broad and general subject.

So the goal with this guide is to assist you with your first steps of getting started with IoT, help you choose the appropriate path (for you) and to avoid typical pitfalls for beginners. I will also gather a bunch of useful links to various helpful resources and great tutorials.

I will take you through three important steps in the decision process and try to sort out what is what.

  1. Choose your project type: Of-the-shelve products vs. DIY projects
  2. Select the core technology: How will your units communicate with each other, which protocol/transmission method should they use
  3. Determine what hardware and software you need: Which components is needed and what are they used for

An overview of some of the brands and technologies and their approximate relative positioning. This is by no means a exhaustive collection.

Step 1: Choose your type of project

One of the first things you need to do is to decide what your limitations are, how much time & money you intend to spend and what your end goal with the project is. Basically we can divide projects into any of these two following categories:

1) Consumer friendly with of-the-shelf products, and
2) Do It Yourself-projects with custom hardware builds.

Typically the first category does not require any programming skills, should you make do with the functionality provided out-of-the-box. This (normally) covers features like read temperatures, dim lights, schedule when to turn on/off lights and similar. Should your needs extends to more advanced features than that you will need to assume that (at least some) programming skills is necessary.

The choice of project type is primarily about simplicity vs complexity, time vs cost and limitations vs control/possibilities. It will be a tradeoff whichever you choose. But it is also possible to mix them as you like. Either you start with the of-the-shelf products and then switch over to the DIY-track, when you are ready. Or you let some parts of your system be of-the-shelf and other parts DIY. It’s entirely up to you.

Before going full throttle with a full Internet of Things project, I would recommend starting small and keeping it simple. That is, restrict your scope to only cover a single home automation set-up (to begin with), and keep the number of sensors/actuators to a minimum. And remember; it should be fun!

Consumer-Friendly Of-The-Shelf Products

Consumer friendly of-the-shelf products for home automation (

Consumer friendly of-the-shelf products for home automation (“smart homes”) and Internet of Things

This segment is all about choosing ready-made products which makes it easy to get started and achieve results. However as these are ready-made products, and targeted towards consumers, the price tends to get higher. And you will give up control (more or less) and the number of options will be restricted to what products each supplier and/or technology offers. The key aspects of of-the-shelves products is that they are limited in control and functionality, costs more but requires less time than DIY. And since they are consumer products you should expect quite good esthetics as well.

Do It Yourself (DIY)


DIY hardware for building your own smart home or Internet of Things-oriented device

DIY projects is where it gets really interesting and the possibilities are endless. Oftentimes you could get a somewhat lower cost by doing it yourself. And you have great control and full flexibility to customize to your specific needs. However, those benefits comes at a price; then time you need to spend and the requirement on your skills. I would personally say it’s more rewarding to do it yourself, but in the end it is your time and skills that sets the bar. DIY is about full control, lots of possibilities, lower cost, and with the tradeoff for more time consuming projects and higher complexity. And you will need programming skills, at least of some kind.

Step 2: Choose Your Communication Technology


Overview of brands and manufacturers and their approximate relative positioning

Home automation and IoT is about devices communicating with each other. To enable this they need a mutual communication protocol. Within home automation these can typically be divided inte wired and wireless communication technologies. Wired is of course not as convenient as wireless while being (relatively) much cheaper, however they both have their pros and cons. So lets have a look at some of the most popular options.

Not interested in knowing how each technology works and why I came to the conclusion I did? Ok, then you could skip directly to the summary and conclusion.

Purely Wired Systems

1-Wire is a pure wired system that provides low-speed data signaling over long distances at low cost. Due to the requirement of physical wiring, this technology is (typically) disqualified in consumer-oriented home-automation set-ups. However as a signal bus between a gateway/micro-controller and severals sensors, this is a very cost effective solution. 1-Wire also have support for single wire earth return (requires only one actual physical wire).

Hybrid systems

X10 was initially wired, but today has support for wireless technology as well. X10 is an open protocol. When using the wired option (communication over the power lines) there is some limitations to take into consideration, something effectively making this option less practical.

KNX is a professional grade protocol with wireless support as well as multiple wired options (such as power line, TP cables etc). The fact that this is a professional grade protocol is reflected by the higher price level. For a large and advanced setup KNX offers a lot of possibilities.

Insteon is a proprietary system with both wired (power line) and wireless options. Insteon systems also have support for the X10 protocol which makes this a flexible option. The appliances are consumer-oriented and is of-the-shelves products. Uses mesh-networks.

Standardized Wireless Systems

ZigBee and Z-Wave is two very similar standardized and widely adopted wireless protocols with support for mesh network topology. Since ZigBee is an open standard the electronics can be provided by any supplier, while Z-Wave have their communication circuits produced by Signa Electronics. This means that ZigBee might have a slight advantage when it comes to costs thanks to some supplier competition, while Z-Wave might be slightly more expensive and offer better reliability and compatibility. At least theoretically.

Both ZigBee and Z-WAVE technologies is generally comparable to each other and offers roughly the same key features; wireless, energy efficient, long range (thanks to mesh topology they can cover distances of several hundreds of meters), easy-to-use, no requirement for a gateway* and with acknowledgement of sent commands. Each technology has several hundreds of companies backing them so there is no shortage of compatible units for either camp. Another benefit is the possibility to create your own units (using a Sigma transceiver circuit for Z-Wave or any circuit of your choice following the IEEE 802.15.4 specification, such as the Atmel “ZigBit”, specification for ZigBee). ZigBee can operate both on the unlicensed 2.4 GHz band (worldwide) or the 915 MHz (Americas and Australia) and 868 MHz (Europe) bands, while Z-Wave always operates at 868 Mhz. Generally speaking, a lower bandwidth increases the potential signal distance, giving 2.4 Ghz ZigBee (theoretically) inferior performance compared to the ~900Mhz ZigBee or the 868 Mhz Z-Wave. This would typically mean an indoor range of 10-20m for these devices and about 100m outdoors (theoretically up to 1500m in a very best case scenario with free line-of-sight, maximum power output, perfect conditions etc). Worth mentioning is the benefit of the mesh network topology that compensates for the limitation in effective range (simply explained; each device can forward the signal to the next device, creating a chain of devices where the limitation in range is between each two devices, which should give four units in a straight line indoors at least 30 m of effective range).

Z-Wave is supported by companies like Fibaro and D-Link, two companies with a clear consumer focus, as well as by other companies like Honeywell. ZigBee is supported by brands like Philips, LG and Belkin. Many companies additionally support both technologies, like Samsung, Verizon, Logitech, GE Appliances and Greenwave Systems etc. To learn more about the differences, check out this comparison between ZigBee, Z-Wave, Thread and WeMo.

* You can connect a switch and a light source without the need for a internet connected gateway, this however is quite limited and does not really falls within the home automation category.

Additional Wireless Systems

In addition to the standardized wireless protocols there is also other alternatives, proprietary systems operating in the 433mhz frequency band, like the System Nexa etc. Even tough being proprietary protocols there might be several manufacturers of compatible products, much like the Tellstick Net which can control devices based on System Nexa as well as systems from several other manufacturers. Many of these systems is generally cheaper than more qualified and flexible solutions like ZigBee and Z-wave. However for simpler set-ups, these consumer-oriented and affordable devices might be a good fit (you could pick up a starter kit with a Tellstick Net, three wall plugs and some additional appliances for about $150). These systems have an range of up to 30m (and significantly less with obstacles such as walls etc). There is products like Zipabox Duo that can control both these 433mhz-systems as well as Z-wave systems at the same time. One drawback with the 433 Mhz systems is normally the lack of two-way communication (which means the systems simply fires away a command and hopes it will be received, while the more advanced systems like Z-Wave/ZigBee actually acknowledges a successful transmission). This is something that might be important to consider depending on which type of system you intend to build (a light bulb that stays lit might not be that big of a deal, while a digital lock that remains locked when your kids stands in the cold freezing is whole other story, or when the door sensor missed en opening of the front door during the night and failed to activate your intrusion alarm). The 433Mhz line of products is all about easy-of-use and low cost. A typical use case for this technology is remote controlled lightning and wall sockets and it is within this area you will find the majority of the products.

Other Options

Some manufacturers, like Philips and D-Link, has chosen WiFi as the transmission method for their appliances. As this is a widely used and common technology it does not require any dedicated (and often costly) gateways. One significant drawback is the fact that WiFi is a quite power hungry and is not particularly cheap. And the greatest benefit of WiFi is the higher bandwidth, when compared to the other alternatives, however when building a network of small and cheap sensors and actuators there is seldom a need for any significant amounts of data to be sent over the network.

Bluetooth is a medium data rate and medium power consumption protocol. Not well suited in sensors networks as it requires paring with a master device (one-to-one). Also the higher power consumption makes it less suitable for sensor netowrks.

Bluetooth Low Energy (BLE) is a very low data rate and very low power protocol. These RF chips can run for years on an AA battery and so are used for things like heart rate sensors. BLE is supported by the latest mobile phones and laptops and so a phone or laptop could control the device, for example a LED lamp. BLE could also be used presence-awareness (for example using the iBeacon technology) which could be interesting in a home automation/IoT set-up.

For DIY projects you also have the option to build your own wireless communication system based on nRF24L01P (or any other cheap wireless transceiver) as well as creating your own multi-technology gateway (why not support Wifi, Z-Wave and ZigBee in the same box?).

Summary and Conclusion

Ok, so there is a lot of options (and the list above is by no means exhaustive), so we need to come to some sort of conclusion and narrow down the options.

I would rule out X10, even tough it is old and proven as well as having both wired and wireless support, mostly because it feels a bit outdated. KNX gets ruled out due to the unmotivated higher cost (and in some regards the lack of consumer focus). 1-Wire gets ruled out because it is solely wired (even though it still earns its place when it comes to short range connectivity between sensors and gateways, especially in DIY projects).

Personally I would look at either ZigBee or Z-Wave, if I was looking for a more capable and flexible system, or something similar to System Nexa (a low priced, simple and consumer oriented proprietary system in the 433Mhz frequence band) if I was looking for a simpler set-up. Insteon could also be an option, however it is neither as cheap as “System Nexa” nor as flexible and widely supported as ZigBee/Z-Wave (but might make sense if you fancy the one-supplier-has-it-all approach).

Since there is gateways supporting both 433Mhz and Z-Wave (like Zipabox Duo and Telldus Znet Lite) this would be a very good solution for beginners as you could start in a small scale. A first step would be to simply remote controlling some parts of your lightning using cheap 433Mhz products (like remote controls and wall sockets). Then you could add the gateway to make the set-up a bit smarter as well as adding the ability to control the devices from a smartphone (and now you can attach sensors, like a thermometer). Then, when you feel up for the task you can bring it to the next level and begin interconnecting each device with one another (make devices react on each other and possibly perform statistical analysis on the aggregated data). At this stage you could also bring more advanced Z-Wave products into the mix.

Step 3: Choosing Hardware/Products For Your Build

If you intend to stay with of-the-shelve products, and not even build your own gateway* or low-cost HTPC, you could skip directly to step 3b. Do you intend to build a DIY-project, or is generally interested in learning about the cheap single-board computers and micro-controllers, or intend to (at some stage) build your own gateway, NAS, HTPC, TOR Proxy etc, then the step 3a is for you.

* Even if you aim for a of-the-shelf project, you can in some cases significantly reduce the initial cost of the gateway by building your own single-board computer based gateway using relatively cheap hardware (say $90-100 instead of $300-550).

Step 3a: Singe-Board Computer vs Micro-Controller Unit

If you opt for a DIY project you need to choose a “maker platform” (hardware) to base your build upon. To simplify things a bit we could categorize these DIY maker platforms as either a A) single-board computer (SBC) or a B) micro-controller unit (MCU). In either case we are talking about quite small and powerful solutions, both of which are relatively cheap and power conservative. The actual choice of a single-board computer or a micro-controller unit depends on what type of project your are building and what your specific needs are.

Single-Board Computers


Raspberry Pi single-board computer

If you need to run a full computer operating system (could be Android, Rasbian, Windows 10 or Ubuntu, it depends on the board) you should go for a single-board computer like the Raspberry Pi (or any of the many alternatives). The same goes if you need other computer-like functionality, such as; running a GUI, install custom software, need some significant processing power, or if you simply have the need for a specific programming language/platform (such as NodeJS). The downside with these boards is the cost and less options for GPIO. The upside is greater flexibility and more power, and quite frankly, you will get a hell of a lot for your money. Take the Orange Pi single-board computer, a beefed up Raspberry Pi, sports the following features; 1 GB of RAM, wifi, gigabit ethernet, quad core processor running at 1,6 Ghz, SATA-support etc. All this in packade small enough to fit in your palm, and with a cost of about $39. Personally, I think that is amazing! Best of all, these computers typically draw 5 watts of power (or less), something I find pretty darn good (as it would require twelve of these to even draw as much power as one typical lightbulb).

Most SBCs is not as powerful as the Orange PI. A typical limitation is the LAN which often is 10/100 Mbit. And in most cases there is only a SD card reader for storage, no S-ATA connectivity. And USB is often limited to a few ports, which only supports the USB 2.0 standard. Also WiFi is by no means attached by default (though not that expensive to add via USB). So you need to pay special attention to what your explicit connectivity needs is. Performance of the LAN would under normal circumstances not pose a problem, the lack of WiFi could on the other hand be a significant limitation. The same goes for the performance and number of physical USB ports. Adding a lot of peripherals requires a more powerful power unit for the SBC, and the CPU will be a bottleneck when trying to squeeze maximum performance out of the USB 2.0 standard.

A SBC is, kind-of, also a MCU. Like an MCU a SBC will normally have GPIO and much of the same abillities, just with more power and additional options. So a SBC would make a good simple development board, especially if you want to write your program/sketch in a specific language (Arduino “sketches” is written i C, while SBC’s typically can run any programming language you want). There are good libraries for Python, LUA and NodeJS, and even .NET/C#.

Micro-Controller Units

Arduino Uno micro-controller

The micro-controllers could be divided into two sub-groups. First we have the standard classic Arduino-type medium sized development boards, which have a bunch of GPIOS (inputs and outputs, I will come back to that later) and with support for common “shields” (add-ons) that extends the base platform with additional functionality such as PWM controller, Wifi, ethernet, SD card reader etc.

Trinket micro-controller

Then we have the smaller sized (“tiny”) development boards (which often have very limited number of GPIO’s and comes with a significantly smaller package and lowered power consumption).

There is also various other models of these MCU developments boards (such as the “mega” with far more GPIO pins), however in most cases either the standard sized Aurduino or the “tinys” would do just fine for your project. Also worth mentioning is the many brands of Arduino boards (thanks to open-source hardware), as well as the phenomenon with Ardunio-compatible boards (not actually Ardunio per see, but compatible with Ardunino shields). Additionally there is development boards that is not really compatible with Ardunio itself (such as with the shields), while still being compatible with the Ardunio IDE (the development environment). Neither of these options is crucial for this guide so we leave them out to keep things simple.

When single-board computers more or less are full-fledged computers (albeit not as powerful as your everyday laptop), the micro-controllers on the other hand typically are small dedicated devices with a specific purpose of controlling physically connected hardware. Instead of running an operating system and additional software, MCU’s are equipped with a small optimized “bootloader” (think of it as an micro-OS) and a single dedicated program (think of it as a command/script on your computer). For Arduino these programs are called “sketches” and are programmed through a PC via USB using the Arduino IDE (which can be used to program any Arduino-compatible MCU).

One common limitation is the lack data communication capabilities (such as wifi and LAN), which effectively makes these devices unable to single-handed communicate over a local network or the internet, unless they are extended with a network “shield” (LAN or wifi). It would also be possible to connect to a host PC to add networking capabilities, however this would probably take away most of the benefits of these low-cost low-power devices. Although MCUs typically are dependent on a host computer for programming, there is some extra powerful models with the possibility to “program over the air” thanks to on-board network capabilities, such as the Arduino Yun (which basically is a standard Arduino with an built-in wifi-module/”shield”), the Arduino Zero (with LAN) and the Adafruit Huzzah (which is a very tiny, cheap and capable wifi micro-controller). MCU’s also lack any real processing power. This makes them suitable for reacting to sensors and controlling other hardware, but not suitable to analyze data.

There is also additional wireless communication circuits like the NRF24L01 (custom wireless communication) or generic wifi-circuits that could be attached to any MCU to add network capabilities, though we leave them out-of-scope at this stage for simplicities sake.

Most MCU’s are programmed using C (Arduino “sketches”), while there is other options (such as the very convenient WiFi-enabled tiny MCU ESP8266 with LUA support through NodeMCU).

Shared Feature – GPIO

Common features between both single-board computers and micro-controller units is the GPIO (General Purpose Input Output) pins. Basically what GPIO is about is reading or controlling the physical state of a pin on the board. Digitally this could be either switching a LED diode on or off (output), or check wether a button is triggered or not (input). On analogue ports this could be reading the intensity of resistance from a thermal sensor (input), or adjusting the intensity of a light bulb (output). Each pin can often be configured as either input or output, but never both at the same time.

There is also more advanced techniques for digital IO, such as; PWM (Pulse Width Modulation) which is a way to switch on and of a signal multiple times in a short time and thus be able to control the perceived intensity (think of it as a “dimmer”) of a LED or to control the RPM of a engine, I2C which is a serial bus interface enabling multiple units/sensors to connect using the same shared wires (similar to 1-Wire, with I2C having greater speed and requires additional wires), to even more advanced digital interfaces like UART and SPI (different to I2C in being full-duplex/two-way synchronous serial communication, typically in a master-slave arrangement).

One common key difference between SBCs and MCUs is that SBCs (typically) only support digital input/output while MCUs tend to support both analogue and digital input/output. MCUs also typically have a greater focus on input/output and therefore have a greater number of GPIO pins.

A Short Recap

Examples of

Examples of “maker” and IoT hardware

Single-board computers: when you need an full OS, a GUI or other computer-like functionality. Suitable for building a NAS, a HTPC, a small web browsing PC, a Tor-proxy or why not building your own internet connected IoT gateway.

Micro-controller unit: when you need a cheap, power efficient solution w/o OS and significant computing power. Suitable for most hardware-builds like robots, home automation etc.

Offline MCU: when you can keep the board connected to a PC at all times, or when you do not need to send data back to another device. Suitable for building a automatic plant watering system or a robot.

Online MCU: when you need to send data back to another device/network or when you want the convenience to be able to program the board through a network (w/o the need for a direct USB PC connection). Suitable for building a remote unit reporting sensor data to a database/IoT-framework.

Step 3b: The Products You Need

What You Need For a Of-The-Shelve Type Project

Choosing the appropriate components for your of-the-shelf system:

In every home automation system you will need some sort of gateway, the “heart” of the system. Depending on technology this could be products like Fibaro Home Center 2, Zipato Zipabox, Tellstick Net, Digi XBee or Nexa Gateway.

Then you needs some sensors and/or actuators. This could be temperature sensors, water moisture sensor, wall outlets, branching outlets, dimmers, pumps, engine/stepper motors etc.

Finally you will probably want some sort of software/application to control your devices. In simple scenarios this would be an app to control your lights, but it could also bee considerably more advanced than that. When you go for an of-the-shelve set-up the manufacturer typically provide you with the software needed, and this should be sufficient for your first project (many even provide the ability to control devices through your smartphone).

What You Need For a DIY Type Project


You will need some sort of gateway, the “heart” of your system. The gateway will have two responsibilities; 1) send data back and forth to the internet, and 2) communicate with your sensors and actuators.

You will probably want to base this gateway on a single-board computer, such as the Raspberry Pi (check out this buyers guide to choose your first “Pi”). Depending on your chosen communication technology you will need to extend the Raspberry Pi with additional hardware (could be wifi USB dongle, RazBerry or XBee for example)


“Visual programming” in Node-RED

Node-RED, which is based on NodeJS, is a great way to get started with Raspberry Pi as it lets you “visually code” your solutions. (The Raspberry Pi will support Python out-of-the-box if you prefer this, but then you will have to do without Node-RED). And to make things even easier, there is a ready made image called The Thingbox, which is great for beginners as it is a complete installation of Rasbian (the OS for the Raspberry Pi) along with NodeJS and Node-RED. Everything you need to get started (software wise) as simple as download, install and you are done.


Easy-to-use web based Ubidots

Even tough not necessary, I would also recommend connecting things to an online IoT framework as it will make it a lot easier to control eg. using your smartphone. Here we have Ubidots which is really simple to use (and is supported in Node-RED). And like icing on the cake; there is a pedagogical and simple-to-follow tutorial on how to combine Raspberry Pi, Node-RED and Ubidots. Just follow a few steps and your are done. It can’t be much easier than that.

So, what you need up to this point is basically only:

  1. A Raspberry Pi
  2. The Thingbox image
  3. An Ubidots account
  4. To follow the Ubidots + Node-RED tutorial

Then you need some sensors and/or actuators. This could be temperature sensors, water moisture sensors, relays, wall outlets, branching outlets, dimmers, LED’s, pumps, engine/stepper motors etc. This could be either of-the-shelf products based on Z-wave or ZigBee, or stand-alone hardware sensors like DHT22 Temperature and Humidity Sensor as well as simple buttons and LEDs.

Finally you will probably want some sort of software/application to control your devices. As we already have Ubidots in our setup you already have some means of controlling your devices. And with their API it is easy to extend with your own custom software to control and or visualize your devices data.

In addition to the Thingbox-solution (with Node-RED and Ubidots), there is lots of other great options. Python is natively supported by Raspberry Pi out-of-the-box, for NodeJS there is many great libraries for simple GPIO control, for netDuino you have a .NET library, and the Jonny-Five is a great NodeJS library which supports multiple development boards like Raspberry Pi, Arduino many more.

Next Step: Choosing Sensors & Actuators and How to Begin With Hardware Development

Now that you have have decided on the core parts of your system it is time to getting into the real action. That is start getting values from sensors and make things happen at (or around) your home. The next post will show a birds eye view on the different type of sensors and actuators that you could use and what they could be used for.

Additionally a brief introduction to cover the basics of hardware development will be part of the next post (for those interested in general, or specifically opted for a DIY project). Like in this post I will not get into the details how to actually do these projects, but rather point you into the right direction to get started as well as to mention some typical pitfalls for beginners.

Inspiration – To Give You an Idea How to Get Started

In the meantime, the following is some inspiration on different projects you could get your hands on if interested in hardware development.

Raspberry Pi Hacks

12 Raspberry Pi projects:
RetroPie nintendo clone:
A robot (nuff said):
Good looking case:–Sq2EsLGj–/c_fit,fl_progressive,q_80,w_636/714162336531572655.jpg
Handheld Raspberry Pi:
Onion Pi (Tor proxy):
Altoids tin computer:
Raspbery Pi Cluster:

Arduino hacks

A robot:
Another type of robot:
Quad copter (“drone”):
Flamethrowing(!) Jack-O’-Lantern:
Automated greenhouse:
DIY home security system:
20 cool Ardunio projects:

Added a reference to Your First Raspberry Pi: A Buyer’s Guide.

Serverdrift co-location för Raspberry Pi!

Jag brukar inte göra reklam för produkter på bloggen. Däremot skriver jag gärna om saker jag gillar. Och det här är ett initiativ jag verkligen gillar!

FS Data erbjuder gratis co-location av Raspberry Pi!

Raspberry Pi är en liten, enkel och billig dator som passar utmärkt för experiment och mindre krävande tillämpningar. Tanken på att kunna skapa en “single purpose”-lösning baserad på billig hårdvara och öppen mjukvara känns helt rätt. Därför är det extra kul när FS Data visar sitt engagemang och erbjuder gratis drift av små enkla Raspberry Pi-servrar för alla dom som varken har en fet budget eller tillgång till snabbt och stabilt bredband i hemmet. Möjligheterna är många och jag tror att initiavet kan bidra till nya kreativa tillämpningar.

Keep up the good work FS Data!