My friend Bill Cloyd runs a non-profit company in Lexington, Kentucky called Newtons Attic. The company focuses on Engineering and Physics education for kids. Billy runs day camps, week camps and after school camps for primary school kids. In these camps/classes the kids build robots, catapults, cross-bows, Rube Goldberg machines, fly drones etc. uising the tools in the machine shop at the Newtons Attic Campus. This is the perfect place for budding engineers and scientists. In addition to this he does road shows with his crazy machines.
One of the machines (called G-Force) is 120′ long track with a spring activated car. One end of the track curves up to the sky. This is an excellent platform for teaching kids about Newtons Laws. Here are a couple of pictures:
When high-school physics classes visit Newtons Attic they take “data” using stop watches etc and then try to match their observations to the predictions that result from Newtons Law. I always felt that this process would greatly benefit from some automation. I have launched into a project to build an electronic system that can attach to the car and collect and transmit the kinematic data from the car. For those of you who have forgotten kinematic data is position, velocity and acceleration.
To do this I am building a system around the new Cypress PSoC4-BLE chip. The system will have the following “sensors”
1. A Linear Encoder attached to a wheel running along the track
2. A 3-Axis Accelerometer
3. A 3-Axis Gyro
4. A 3-Axir Magnetometer
5. A Spansion (now Cypress) SPI Flash to record the data
6. An Air Pressure Sensor and a Relative Humidity Sensor (which I will use to calculate the Air Density)
The PSoC4-BLE will collect the data from these sensor and broadcast the data to any BLE Enabled device (iPhone, Android Phone).
The last part of the system will be a Swift App (running on iPhone) and a Java App (running on Android) to collect and display the data.
In the next bunch of posts you will be able to follow me through the Schematic Design, Board Design, Firmware Development, Board Manufacturing and App development process.
In the previous two Bus Pirate posts, I introduced the Bus Pirate and talked about the V3 version from Sparkfun, and I showed how to use the V3 version from Seeedstudio to read and write I2C commands into a Cypress FRAM.
Bus Pirate V4 is a complete redesign of the hardware. It combines the PIC microcontroller and FTDI USB/Serial bridge into a single chip (a PIC 24FJ256GB106). Mr. Lesnet also added 3.3v and 5.0v on board regulated voltages, and an onboard eeprom for extra storage. You can read more on the Dangerous Prototypes web page.
I also ordered the acrylic case (which is cool) as well as the V4 cable (which sucks compared to the V3 cable because the grabbers don’t match the cable color and are signals are unlabeled).
On the back of the board you can clearly see the right way to put a silkscreen on a board. Clear, sensible, legible.
The first thing that I did was “?” to see what was new on the menu.
The next thing that I tried was putting the BP into I2C mode. This was similar to V3 with the exception that now there is a hardware driven I2c and it is capable of 1MHz operation. The other thing that has been added is a programmable onboard power supply. You can select either 3.3v or 5.0v by using the “e” command. The power supply can be turned on/off using “w” (off) and “W” (on).
Here is a screenshot of the schematic for selectable regulated pullup.
I was interested in trying the Bus Pirate I2C sniffer. To do this I used the onboard I2C bridge in the “KitProg” on the CY8CKIT042 and used the Cypress Bridge Control Panel (part of PSoC Programmer) to issue I2C commands to the FRAM on my test setup (which is the same as in the previous posts). In the example below I first issue a “Write, location 0x00, data 9,8,7,6,5,4,3,2,1” In other words fill up the first 9 locations in the FRAM with 9..1.
The second command issues a “write, location 0x00, Read the next 5 bytes (each “x” reads 1 byte)”.
In the 2nd part of the Bridge Control Panel you can see the actual commands that happened on the bus and the ACKs (“+”) and responses from the FRAM.
In the screenshot below you can see that the sniffer perfectly “sniffs” the first command. That is pretty cool… and a very useful function.
In the second case, you can see that the BP sniffer can see the write command perfectly and can read the first byte response from the FRAM perfectly, but does not read the other bytes correctly. Specifically it reads 0x10, 0x1c and 0x30 instead of 0x08, 0x07, and 0x06.
To debug this problem I plugged in my Tektronix MSO2024B logic analyzer to see if there was some problem with the I2C transactions. However, you can see from the screenshot below that the scope can read transactions perfectly. So, what is going on? I don’t know. But, at this point it seems clear that the sniffer is a bit flaky. At this point that is going to be a problem for another day.
In the previous post, I introduced Bus Pirate V3 – specifically the Sparkfun version. After digging through things a little bit I decided to order the SeeedStudio V3 Bus Pirate. This version has exactly the same firmware, pinout etc as the Sparkfun version. However, there are a few good improvements in the SeeedStudio version.
First, the silkscreen on the SeeedStudio board is WAY better. There is no good excuse for having a bad silkscreen on your board. When you compare the two boards you can easily see the labels that clearly document the pins.
Second, the cable that you can get from SeeedStudio has beautiful heat shrink labels on the end of the cable. And, more importantly the colors match the pins on the board. In the picture the below the SparkFun cable colors are correct because I uncrimped the cable and fixed it as I described in the previous post.
And lastly, the SeeedStudio version is compatible with their acrylic case which is inexpensive and works well. It is just two pieces of acrylic that have been laser cut to fit the BP. Nice.
For my project I have:
An FM24V10 FRAM from mounted onto a PSoC 4000 development kit from Cypress
When you attach a terminal program – like Putty – to the usb serial port of the Bus Pirate, you are given a command prompt (press enter to get the prompt). The first prompt that you get is “HiZ” which indicates that all of the pins of the BP are in high impedance mode. Then, I issue the “m” command which tells the BP that I want to switch the mode. I select “4” to put the BP into I2C mode. I then select “4” to pick 400khz. Notice that the BP says “~400kz” which almost certainly means that the I2C is implemented with bit banging. Then I turn on the I2C pullup resistors using the “P” (capital P) which are on the BP board. In order for them to work you need to attach the “VPU” pin to either 3.3v or 5.0v. The last command that I issue is a macro, all the macros are enclosed in parenthesis. The macro that I issue is “(1)” which searches the I2C address space (addresses 1-127) and makes a list of all of the devices that respond.
In my setup there are 4 I2C devices
Devices
Device
7-bit address
8-bit read
8-bit write
FRAM
0x50
0xA1
0xA1
ADXL345
0x53
0xA7
0xA6
BMP180
0x77
0xEF
0xEE
HTU21
0x40
0x81
0x80
In order to write to the FRAM you need to issue:
An I2C Start – in BP that means “[“
The 7-bit I2C address of the FRAM (0x50) and the write bit “0”. AKA 0xA0
The two byte address of where you want to start writing data in the FRAM 0x00 and 0x00
The data – in this case 9,8,7,6,5,4,3,2,1 (which means that locations 0-8 will contain 9..1)
An I2C stop – in BP that means “]”
After issuing this sequence “[0xa0 0 0 9 8 7 6 5 4 3 2 1]” you can see the commands that are actually issueed on the I2C bus as well as the slave FRAM responding with “ACK”.
The second example which you can see in the above screen shot is to read from the FRAM. In order to do this you need to issue the following I2C commands
An I2C Start – “[“
The 7-bit I2C address of the FRAM (0x50) and the write bit “0”. AKA 0xA0 (left shift the 0x50 and or it with the read 0x00)
The two by address of where you would like to read 0x00 and 0x00
An I2C Stop – “]”
An I2C Start (aka Restart) – “[“
The 7-bit I2C address of the FRAM (0x50) and the read bit “1”. AKA 0xA1 (left shift the 0x50 and or it with the read 0x01)
5 reads
After issuing this sequence “[0xa0 0 0][0xa1 r:5]” you can see the commands that are actually issued on the I2C bus as well as the slave FRAM responding with the data in the FRAM and the “ACKs”.
In the next post I will introduce the V4 Bus Pirate.
One of the common open source development tools is called the Bus Pirate. It is a low cost ($35) serial terminal based program that can issue commands to many (and mostly serial) busses including UART, SPI, 1-2-3 wire and I2C. Bus Pirate was developed by Ian Lesnet of Dangerous Prototypes.
I am currently working on a project for a friend of mine (more to come on this topic) that will read data from 3 different I2C sensors, record the data into a nonvolatile RAM and simultaneously broadcast it over a BLE Radio. As such, I had a need to make sure that I understood the way that these sensors behave.
The bus pirate has had 4 major revisions and many subrevisions. The current “stable” version is V3, however, there is a fairly new version V4 which has many improvements and should soon displace V3.
I started by plugging the BP into a USB port, where it proceeded to enumerate as something my computer had never seen before. Great. I looked around a bit and figured out that the designer had used a FTDI USB to Serial bridge chip as part of the design. This chip required a custom driver which I found on FTDIs driver website. This requirement was also documented in the Bus Pirate 101 tutorial. It is kind of too bad that FTDI hasn’t gotten their driver to be understood by Windows without intervention. Just one more good reason to use the Cypress USB Serial Chip.
After sorting out the driver situation I attached to the Bus Pirate using my favorite terminal program – Putty. You can see (by looking at the Device Manager) that the BP enumerated as COM5 on my computer.
The first thing that I tried (without having yet looked at the instructions was “?” which nicely gave a list of the commands (as you can see in the screenshot below).
I then tried “v” which shows the states of the 10 pins. Cool. My first though was “which wire on this cable is pin 1?” Then I looked at the screen and realized “wow… look at that, the wires on the cable are the same color as the labels on the screen”. I though that was pretty damn civilized. I had a variable voltage sitting right next to the kit (just a POT on another devkit that I was working on) so I plugged it into the “YW” (aka Yellow) wire. After pressing v again it happily reported 0.00v (two decimal places even). Hmmm… what in the world is going on. Time for the fluke. Crazy, the voltage is right, I wonder what isnt working. I then guessed that the cable was plugged in backwards, but that wasnt it (the cable is keyed). Then I wondered if there was something wrong with the cable, so I disconnected it and just connected directly to the pin (which is unlabeled on the silkscreen – that sucks). I found the pinout on the schematic on Dangerous Prototypes. Then I realized, the cable is BACKWARDS from the real pinout. That really really sucks.
When I looked at the comments on the Sparkfun page there is quite the little discussion about this topic. Included is a suggestion to un-crimp the cable, flip it over, and recrimp. I tried this suggestion and it worked out, until I broke part of the plastic holding the cable together. After getting the voltage source connected to pin 4 I was able to see changes in the value being read correctly by the analog to digital convertor in the BP. Cool.
The other comment which caught my attention on the Sparkfun page was a request from Ian Lesnet to please buy from the SeeedStudio website. This motivated me to purchase another V3 and a V4 from SeeedStudio. I the next post Ill talk more about my experience with SeeedStudio V3 and V4.
In the previous post I described the “thing” side of an Axeda IOT implementation. That “thing” was a simple potentiometer, read by an ADC in an NXP1124 ARM MBED development kit. The value was then encoded into a JSON message and posted to the Axeda cloud over an ethernet/IP connection.
In this post I will describe the Internet (Cloud) side of their system. Start by opening http://toolbox.axeda.com and clicking on the little wireless router icon next to the “Your Devices”
You will then have a screen that has the following panels
1. Data Items. A list of the variables that have been added to your Axeda instance. With links to add, edit and view the data.
2. AMMP Info. A panel where you can send JSON formatted messages to the server to simulate client behavior.
3. MBED Widget. A graphical representation of one of the data items in a cutesy picture format.
On the data item panel you can
1. See the current value of your data
2. Manual edit the data (by clicking on the pen/pad icon)
3. View a table of the data (by clicking on the alarm clock icon)
4. View a graph of the data (by clicking on the graph icon)
Main “Data Items” PanelTable of DataRealtime Graph of Data
In my next post I will summarize my experience using Axeda and outline some next possible steps.
For my next installation I decided to try automating the garage door opener. To do this I purchased:
ZFM-80US Fixture Switch Module
Ecolink Garage Door Tilt Sensor
On at least one site it was stated that you should install a camera to monitor the garage door – specifically that you should look before you close the door. Ill leave that for another day. In my previous posts I described the installation of automated lights in my barn. I decided rather than try to sort out range extenders that I would install another HomeTroller something else that I plan to come back to.
The ZFM-80 is a cool little module. It has connections for:
(L)ine and (N)eutral (to power the switch)
The two connections for the internal relay
Two connections for an external switch (you can connect a button to the switch to manually trigger the relay
The front of the switch has a status LED and a button that can serve to trigger the relay or to start pairing mode.
In my garage it was inconvenient to install the switch near the current garage door opener button so I decided to install it near the garage door opener power which was on the ceiling above the garage door opener. To do this I cut in an “old work” electric box. Whoever thought this type of box up was a clever person. If you have not used an old work box, start by cutting a hole in the drywall, then tighten the screws on the box which draws down two plastic clamps to hold the box in place. In order to make the switch work you need to provide it line voltage, in my case I put a wire between the plug next to my box and my box. I then attached the switch to two wires running the garage door by cutting the wires in half and shorting the relay connections to the wires.
The installation looks like this:
After that my son 10 year old son buttoned up the wires, box etc.
Nicholas installing garage door switch
The last step is to bind the switch to your network. To do this:
1. Press the button on the Zstick (1 time). The blue light will start flashing at about 1Hz
2. Press the button on the Zwave fixture switch module. The Zstick will bind with the fixture module. The Zstick will blink rapidly for about 3 seconds, then go back to 1Hz blink rate. Press the button on the Zstick to end binding mode and then re-insert the Zstick into your HomeTroller.
3. Go the Plug-ins->Z-wave->Controller management. Then click the yellow arrow on next to the interface. Then select “import Node Info from Controller and Scan Devices”. This will import the binding information from the Zstick
After I completed the installation of the switch I then installed the tilt sensor. This is a simple battery powered device that send out a Zwave status each time it is “tiled” (either up or down). It does this with a little mercury? switch that contacts (or doesn’t) when the switch is rotate about 90 degrees. The sensor also reports its battery status. The documentation says that the battery will last up to 4-6 years. The physical installation is simple, just attach it to the top of your garage door with the sticky tape and two screws.
To connect this device to the network
1. Click the Zstick binding button
2. Insert the battery into the Tilt Sensor
3. The Zstick will flash quickly when it binds.
4. Click the Zstick button to take it out of binding mode and re-insert it into the RPi
5. Go the Plug-ins->Z-wave->Controller management. Then click the yellow arrow on next to the interface. Then select “import Node Info from Controller and Scan Devices”. This will import the binding information from the Zstick
The only trick that I found with this part of the installation is that the cover must be firmly on the tilt sensor or the LED will not go out and it wont work correctly.
Once you have completed the two binding you will should have a device management screen that looks like this:
Notice that my tilt sensor is node-4. When I did the original import, the system got confused and I couldn’t figure out how to fix it. So, I deleted everything and re-imported the network configuration.
The last thing that you need to do to make this installation work correctly is to create an “event” to run the garage door. The problem is that when you “click” the switch it will toggle the relay. In order to operate the garage door you need to toggle it “on” to activate the opener, then you need to toggle it back to “off” in order to re-enable the door. To do this:
1. Go to the “View->Events” menu.
2. Click the green plus to add an event.
3. Name the event
3. Select If “This event is manually triggered”
4. Then “control a device”
5. Select your switch and set it to “on”
6. Click the green “plus” to add another step
7. Select “Then wait” and enter a few seconds (in my case I picked 5″
8. Click the green “plus” to add another step
9. Then “control a device”
10. Select your switch and set it to “off”
You should end up with an even that looks like this:
You can now run the even by pressing the “>” play button thing. I would like to be able to run this event from a simpler interface, but I don’t know how… for now anyway. Stay tuned.
If you want to control your system from an iPhone you will need to enable the HSTouch Server on your Hometrolller (it is on by default). You can do this from Plug-Ins->Manager. If HSTouch Server is disabled then you should renable it.
After you have an account you need to add your license (from the back of the HomeTroller) to your account. This will provide the connection between the HomeTroller (in your house on your private network) and the HomeSeer server (on the internet)
Then you need install the Apple iOS HSTouch application from the App Store
After installing the application you need to configure your account and password. To do this go to the settings menu on your iPhone and select “HSTouch”. If you dont configure the account and password the HSTouch will just crash with no explanation.
After you have configured your account and password, run the HStouch App. First select “My HomeSeer”, then “Devices”
Then select the location – in my case “ground” and “barn”
Then select “Barn Inside Lights”. Then you are able to turn them on or off.
That is it. The interface is kind of clunky, but it is functional.
In the previous posts I installed the HomeTroller and the Zwave switch. In order to do anything you now need to read the network information out of the Zstick into the HomeTroller. In order to accomplish this first:
Select “Plug-ins->Zwave->Controller Management”
Then click the yellow arrow to open the interface menu.
Then select “Import Node Info from the Controller and Scan Devices”. This will read the binding information out of the Zstick and initialize all of the required HomeTroller databases.
After clicking start, you will get a screen that shows the status of your import process.
I am now able to control the lights from the web server interface. First select “View->Device Status”
Then click on the correct “node” tab. Then click on the light bulb.
You will then be able to turn it “on” or “off”
Another method is to use the “View->Device Management” screen. You will be able to turn on or off the lights from the right side of the table.
The last thing that you can do to make things a little bit simpler is to assign a sensible name and location to the switches. You do this by clicking on the current name (looks like a hyperlink). It will then show up with its new name and location.
In the next post I will describe attaching the HomeTroller to the internet and using the iOS app to control the switches.
Axeda is one of several (at least a half dozen) companies that sprung up to service the “Cloud” side of the IOT boom. They were successful enough to have been purchased in August by a company called “PTC” (for some reason it isn’t easy from their website to figure out what the letters P.T.C stand for), presumably for a big pile of money. Axeda is focused on the Cloud part of the business, including tools to store, analyze and control IOT machine data.
Axeda offers several embedded development kits including ones for ARM MBED, TI, Freescale, Inventek and Raspberry Pi. The kits aren’t so much hardware as they are a set of libraries to allow you to use those platforms to interface with the Axeda Developers Cloud. In order for any of these kits to work you need to have:
A physical layer (ethernet or wifi)
A network layer (tcp/ip)
A protocol layer (http)
An application layers (json formatted data)
In this article, we will be focusing on the ARM MBED kit.
The architecture of the Axeda + MBED solution is as follows:
The ARM MBED kit is build with an NXP LPC-1768 ARM based microcontroller. MBED is a cloud based development environment for building embedded firmware for ARM based microcontrollers. The MBED kit is then attached to an expansion board that was designed by ARM that has two potentiometers, an ethernet port, temperature sensors etc.
In order to transfer data from the development kit to the Axeda cloud, you need to format your data in a JSON message and transmit it using HTTP to the Axeda server. This seems complicated, but it is really pretty simple. JSON stands for JavaScript Object Notation and is just a text based, human-readable format that is an alternative to XML.
A simple example that encodes two name value pairs (potval and temperature):
To transmit this to the Axeda cloud, you just embed the JSON into an HTTP POST to the correct web page (which has your Axeda Serial number. Here is the snipped of code from MBED that formats my example message. Notice that there are two data variables, one called oil_level and one called oil_level2:
The first section initializes the two ports for the potentiometers, sets up the LED output and makes a few buffers. The blued out section of code is my serial number.
The next section of code starts the ethernet interface and gets an IP address. Notice that these are library routines that are provided by the ARM MBED compiler.
Then the last section of code reads the potentiometers, and then if they have changed enough, transmit the values to the Axeda cloud over a TCP/IP socket.
In part 2, I will show how to look at your data in the Axeda cloud.
In the previous posts, I gave an introduction to Zwave, described the overall system architecture, and demonstrated the installation of the HomeTroller Zee. In this post, I will describe the installation of the GE Zwave lightswitch and its connection to the Zwave network. The GE switch is made by a company called Jasco – which claims to be a privately owned company that “develops cutting-edge consumer products” for GE.
First, the lightswitch box. It contains well written instructions in three languages and the switch. The picture below shows two switches (so that I can show the front and the back of the switch in the same picture).
The next step, and the most important thing for me to do today is fervently avoid getting shocked while doing the installation. You would think that an electrical engineer would have enough sense not to install the switch without first turning off the breaker, but I always figure that I can get away without doing it HOT, a plan that invariably misfires. So, today I will start by turning of the breaker – something that I recommend you do as well.
In my barn there is a group of three light switches on the “narrow” form factor. For my installation I will replace all three switches as I could only find (at Lowes) a cover plate with 3 wide holes. The switch on the left will be the barn lights (the one that gets left on my by son all the time). The other two I will replace (for now) with dumb switches that cost $2.
The next step is to install the Zwave switch. The original light switch has three connections, one bare copper ground, one “hot” wire from the line, and one wire going to the lights. The Zwave switch has four terminals, three of them are the same as the original switch and one is the added “neutral”. In order for the switch to operate it requires power and neutral to run the Zwave microcontroller – hence the need for the neutral. I created the new neutral connection wire by wire-nutting a new wire to the inside of the box attached to the pre-existing neutrals. I used a multi meter (with the power still on) to find the “hot” line side of the light switch. This was confusing as you can see from the picture the switch was installed upside down (your can faintly see the “off” label in the wrong place).
Once you have the switch wired, reassemble your box and turn the breaker back on. You should see the status LED glowing blue.
The next step is to pair the Zstick with the light switch. There is a battery in the Zstick that needs to be charged in order for this step to work. After I unboxed the HomeTroller, I plugged the ZStick into a USB port for about an hour to charge the battery. In order to launch the pairing process, start by pressing the button on the Zstick (it will then start blinking at about 1 Hz). Then press the top of the light switch (like you are turning it on). The light on the Zstick will then blink rapidly for about 3 seconds, then go back to blinking at 1 Hz. The rapid blinking indicates a successful pairing. Once you have them paired, press the Zstick button once to end pairing mode. If you had multiple devices (for instance if you were an installer) you could do more pairing before going out of pairing mode.
The next post will describe the process of reading the information from the Zstick into the HomeTroller.
This whole home automation space is crazy. It is fractured into many many different and incompatible “standards”. I have heard (though not verified myself) that many of the Zigbee radios used for home automation are not compatible and there are cases where the central hub has multiple radios to deal with the differences in the networking stacks. Other physical standards, like WiFi, have standard physical layers (802.11) and standard network layers (TCP/IP) but lack standardization higher up in the application layer.
So, Zwave. There are literally hundreds of compatible devices. And, as best I can tell, it can handle most anything that you would want or need to do home automation. I personally think that it is really cool that I can buy Zwave devices at Lowe’s in Georgetown, Kentucky. You can also buy them at Amazon, Staples and many other online places. That is pretty awesome. Zwave also seems to be one of the least expensive radio standards; you can buy modules in low quantities from Digikey for $5. The least expensive WiFi modules are something like $15 in low volume.
But it is really annoying that Sigma tries to squash the low volume market by raping their would-be customers for development kits and software licenses.
On the hub/host side of Zwave there is OpenZwave, an open source project to provide host side control of Zwave networks. The groups seems to be pretty active and I think that I will try out some of their stuff.
Like any good engineer, the first thing I did after unboxing the HomeTroller was to take it apart. In this case, I had two motives. First, I wanted to make a backup of the SD Card that runs the Raspberry Pi. Second, I am always interested in what can be learned by looking inside. In this case, you have fairly normal Rasberry Pi with a nicely executed case. The case was held together with 4 screws on the back. It included a cover for the SD card (in the lower left of the photo). The interesting thing – to me anyway – was the clear plastic LED guides. You can see them in the upper right. Their function is to redirect the light of the LEDs to come through the top of the case so as to be visible on the outside.
Included in the case is an 8 GB SD Card which holds Linux + the Hometroller software. I checked on the Homeseer web site on the Support->downloads->current downloads page and was not able to find the HomeTroller Raspberry Pi image. I found it curious that there is also a Support->downloads->older downloads which contained current software – specifically drivers.
All that being said, it is good to make a backup of the SD Card before you start. For this task (on my Windows 8.1 PC) I used the Win32 Disk Imager, which can be downloaded from their Sourceforge website. If you have a Mac or a Linux computer, you can find the instructions for this process on the Raspberry Pi website. The process is straight forward. First, insert the SD Card and figure out which drive letter it was assigned using the Windows explorer. Then enter the destination file (in my case hometroller.img on the desktop), select the “copy” check box, then press read. A few minutes later, you will have a binary image file of the card which can be restored to your SD card (or another one) using the reverse process.
After you have completed the backup process, reassemble the whole thing and plug in the power and an ethernet cable. The RPi will then boot and join your network using DHCP to get its IP address. After a couple of minutes, you will be able to access the webserver running on the RPi. To find your HomeTroller, go website http://find.homeseer.com and it will search your network. In this case, you can see that I have two of them plugged in.
Click on IP address and your browser will open up a web page on the HomeTroller to setup the accounts and passwords.
The next step is to setup your HomeTroller. To do this, go to Tools->setup. Then:
1. Enter your license information (your ID and Password is on the back of the RPi)
2. Setup the physical location and timezone.
3. If you are going to use WiFi, click on the network (1) tab and configure the SSID etc (2). In my case, I am using a USB WiPi Wifi dongle. I plugged in the dongle while the RPi was alive (specifically while I was typing this tutorial) and the RPi immediately went offline. After the system rebooted, I went to the tools->setup page, clicked the network tab, then entered my WiFi networking parameters (SSID, Security type and network key). Then I shutdown the RPi using Tools->System->shutdown. Once the RPi was shutdown, I removed the ethernet cable and then unplugged/replugged the power. After two more minutes, the RPi came back online attached to Wifi. However, just to make things interesting, it had a new IP address – because it had a new mac address, so the DHCP server assigned it a new address, so you will need to go to the find website again.
The last thing that I did after configuring my HomeTroller was clean out the bogus example devices. You can do this by going to view->device management.
Lastly, click “Test Device 2 (can be deleted) and then delete it.
In the next post, I will describe the process of installing and attaching the light switch to the network.
I live out in the country near Lexington, Kentucky. A few years ago my wife told me that I either needed to build a barn to store bicycles, or get a divorce. So, I built a barn – well, actually, I had a barn built. The barn has been great, except for one major pain in the neck. Invariably I look out the window at bed time and find that my son has left the damn lights on. It is incredibly annoying to go outside in the dead of winter, or even summer, in your pajamas to turn out the lights.
The barn from my window… in the dark with the lights on
After rejecting the Adrian Peterson method (wake up the kid, beat him, and then send him outside to turn off the lights), I settled on the another answer: connecting the barn lights to the Internet. I considered a number of different alternatives, but after talking with a friend of mine, Eric Ryherd at Express Controls, he convinced me to implement a Zwave home automation system.
Zwave is a proprietary 900ish MHz radio system (radio, protocol, etc), low bandwidth (100kb/s) that was designed for home automation. The “ish” is a result of the 900 MHz band not being regulated the same way in all countries. As a result, there are three different radios configurations to cover the world. Zwave has a number of attributes which make it excellent for home automation including:
Long battery life (>6 months)
Low latency
A true, simple mesh network
A single dictatorial company (Sigma Designs) controlling the protocol and certification (resulting in strong standardization)
Range in excess of 100 feet
Easy client-to-server binding
The flip side is that:
A single dictatorial company controls the standard and the silicon (resulting in insanely expensive development kits, restrictive license agreements etc)
Multiple radios required to work around the world
The other interesting thing about Zwave is that Lowe’s has made Zwave part of their Iris home automation system. This means that you can purchase some Zwave stuff at almost any of their locations – including Georgetown, Kentucky.
A GE 45609 Z-Wave Wireless Lighting Control On/Off Switch from Amazon ($40.86)
The HomeTroller Zee is a Raspberry Pi based system. The Raspberry Pi comes pre-installed with Linux, the ZStick device drivers, and the Zwave management webserver.
Included in the package is:
In order to bridge between the Zwave world and the Internet world the kit includes an Aeotec Zstick 2. This device has two functions:
It is a battery powered installation device. You can walk around with the device, press the button to start the pairing process, press the target device pairing button, which will result in the target and the stick being paired i.e. the target device is now part of the Zwave network. Then, when you plug the Zstick into the Raspberry Pi USB port, you can then upload all of the paired devices into your Zwave network configuration.
It is a USB dongle that provides the Raspberry Pi with a Zwave radio interface.
For my implementation, the overall system architecture looks like this:
The barn lights are connected to the GE switch (via normal 120v house wiring). The GE Switch communicates to the ZStick via Zwave radio. The Zstick communicates to the RPi via a USB->Uart connection. The RPi talks to the internet via Wifi (routers etc.)
In the next post I will describe the HomeTroller Zee installation.
