October 16, 2013 · api arduino automation cmus google hacks nodejs programming python raspberrypi rcswitch

Remote Home

or: how I've decided to move all the switches into my tablet.

I've been exploring the possibilities of creating a home automation system using Raspberry Pi. It seems a great experience to do something like that on your own, not just buy special equipment (which is rather expensive). Since I've got now three R-Pis, I've decided to commit another one for a bigger project. One is already used as a web, NAS and print server, and I didn't want to risk any disruptions on the machine caused by other equipment. My another Pi, with project alias SecurityPi, will be performing several tasks.

I've already created the Google Calendar API alarm clock for a non-convenient way of getting me out of bed (and, by chance, found a great command-line music player called cmus), so why not take it to another level and automate a bit my household? I've started implementing PiFace Digital into my project, making it respond to door/windows state, yet, it's not a perfect solution. Then I've come across an interesting automation project - heimcontrol.js.

Heimcontrol.js

Heimcontrol is an "awesome home automation with Raspberry PI and Arduino using Node.js, MongoDB, HTML5 and Websockets". The menu is really nice and themeable, with few very useful plugins to communicate with R-Pi and Arduino (connected to Raspberry with USB cable) from the web browser level. The feature that caught my eye, was the ability to use remote controlled mains sockets, or, in fact, any 433MHz controlled equipment. I've got few RC outlet sockets at home, so I've decided to give them a try with my R-Pi. The remote control from the set operates on HS2260 controller, which is problematic to use with the heimcontrol library (if you click on the link, you might guess why). Heimcontrol uses a so-called Tristate-Codes to communicate with a utility. Those are sent to the remote from Arduino using rc-switch library, that, yup, doesn't seem to be working with the chip I've got in hand. I've tried every single possible code combination, code alteration, every single way of sending the signal to the sockets, and I cannot do it! The transmitter seems to be sending something (the LED blinks), but the signal seems to get lost in the ether. It might be because the outlet sockets are in no way settable (no switches, dips, rotaries), as if they were hard-coded.  The GPIO plugin doesn't allow to control I2C port, so"¦

Bad luck. For now, I'm putting heimcontrol.js on the side.

I2C experience

Just about when I was starting to lose hope, I've found a solution, not a perfect one, but doable. Tony from OddWires used with his project the same outlets, yet, he just decided to do it with wires. Fair enough, I've decided to do something similar. But, wait"¦ There are 10 pins on the remote, and only 8 GPIO ports on the Raspberry, and I still will be needing some of them for other things"¦ Then I've realised I could use the MCP23017 chip to low-costly expand my GPIO with 16 additional ports! With no time to lose, I've started breadboarding. The chip itself can be operated from Raspberry Pi using the i2c port - only two pins (plus power) used.

All I needed now was a simple way to communicate with the chip. I've googled for solution and found a Python library (with a simplistic web interface using Apache's mod_wsgi and JSON), written by Nathan Chantrell. The program syntax is a bit confusing:

mcp23017.py -b <bank> -o <output> -s <high></high></output></bank>

but once you implement it in scripts and get used to the MCP23017 usage and GPA numbering (here's a great tutorial on the chip), it's all fine. For testing, I've altered the wsgi code, so it would be of better use with the remote control, as the original program triggered a port on or of, without returning to it's original state. Apart from cosmetic changes, I've added lines that would disable the triggered port, as if the switch on the remote was pressed:

write to the IO expander bus.write_byte_data(address,register,value) sleep(0.25) bus.write_byte_data(address,register,0)

The rather hideous, yet responsive and usable, front-end looks like that:

wsgi

This is just a testing application. On my github you can find the full code. I'm working on a prettier and more elaborate, heimcontrol.js inspired node.js web application that would implement the MCP23017 controls.

As for the chip itself, I've connected the expander as follows:

mcpbreadboard

And here is a schematic: MCP23017 schematic.

I didn't really want a breadboard lying somewhere, and breadboard isn't a good idea for a long-term project, so I've decided to solder the chip into a Slice of Pi I've bought some time ago and used for testing (there is a version designed especially for the MCP23017 chip, but I don't have it in hand, so I had to improvise).

I've soldered the slice, a bit messy and slapdash, but it will be hidden from view, and if I had to, I will solder another one:

slice of mcp23017

The Remote Control

To use the remote control with my newly built Slice of MPC23017, I had to do some more soldering. Each switch received a wire, that I've grouped into ON and OFF bulks. Not to confuse myself, I've connected the ON wires to GPB 0 - 4 of the expander, and OFF buttons to GPA 0 - 4 ports. This makes coding easier. Additionally, the remote gets powered directly from Raspberry and although it's said to be operating with 12V power supply, it works fine with only 3.3V Raspberry delivers:

remote full remote control

For now, I've got only two sockets connected, one to a night lamp, and the other one to my Yamaha AV Receiver. I've decided to make my Raspberry Pi switch the receiver on/off for one practical reason. I'm using the Google Calendar API alarm clock, and I just didn't want the receiver to be working whole night. Instead, I've created two simple scripts (or command lines) that I've put into crontab. Now, the Raspberry Pi switches the receiver just before the alarm clock goes off, and back off half an hour later. This saves me energy and keeps my mind calm, as I don't have to be worried about any unfortunate power failures and short circuits.

The Future

For now, the application has no hands and legs, is ugly and I have to click a lot to switch anything on/off. As I've mentioned, I'm working on a pretty and responsive web application crafted using node.js. To be honest, I've fallen in love with Node, it's simplicity and versatility, and that's the main reason I've chosen it as a programming environment.

remote pi

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket

Contact