I finally made the plunge yesterday and brought my Rasberry Pi online and disconnected my old controller. The Pi is now doing all the functions of the controller and presenting a web interface for monitoring control. It was quite the learning experience.
In this post <link> I described the architecture I chose for the new device; I extended that to handle scheduled events such as turning the pool light on for an hour at 8PM to attract bats. Bats are fun to watch when they swoop over the pool catching bugs. Eventually I'll have a number of events because I intend to hook my drip watering system up to the network as well as a number of lights around the house.
I also added the three cloud services I update data to: Pachube (legacy Xively), the new Xively <link>, emoncms <link>, and ThingSpeak <link>. They fit right in the architecture without changing much at all. Over time I expect to extend it a bit more and have a tablet based application that can control the house like a remote control. The hooks are all there to add things over time.
Wow, was there a lot to think about. I had to make the processes restart after a power failure, which meant taking on the init process of linux. I upgraded the init process to use upstart. This piece of code is much friendlier than the older init process, but was a scary piece of work. See, if I screwed that one up I would have to start all over because it would have made my little Pi fail to boot up. So, I backed up the operating system image before I started and several times during the process. Fortunately, I did it right and the system came right up and worked. Now, all the processes start on boot up and are restarted whenever they die. This makes it cool because I can make a few changes, kill the old process, and the new one takes off and does whatever job I added to it.
I also added an update process for dyndns. When you get a controller like this working, it just makes sense to put it on the internet so it can be monitored from anywhere. Services like dyndns make this possible for us regular folk that have normal consumer DSL service. Our ip addresses change from time to time and we have to keep the internet name servers up to date. To do this, I had to take on the mysteries of the cron process. What a pain in the behind that was. No, the documentation out there is correct, but it's so easy to make a mistake, and so hard to find it that I spent almost a day messing around with that piece alone.
But I got it working. Here's a block diagram of the process architecture as it exists right this minute:
![]()
Notice how the cloud update services Xively, ThingSpeak, and emoncms just read from the database to update over the internet. Using this technique, I can try out other cloud services without making any changes at all to the ones that already exist. The event handler communicates with the House Monitor directly, it doesn't need to mess with any other processes to do its job. The Web Server has interfaces to the controls and database to keep the internet away. I'm trying to keep my neighbors from playing with my garage doors.
It's strange to imagine that a little arduino 2560 did most of this stuff for a couple of years. When you think about it though, the arduino was written in c++ and hand tailored to handle stuff over a long period of development. I only added the things I knew it could handle. Now, I can add capabilities that the arduino just couldn't do, which also means that I can off load some of the work that is handled automatically by other network devices if I need to in the future.
One of the great things I haven't experimented with yet is the web interface. I can easily edit new pages off the one I have now to show graphs, pictures, etc. This could get to be fun and offer a platform for other folks to get ideas from (that I would then steal and put in mine).
Later today I hope to massively update my page on the House Controller (see the tabs at the top of the page) so that I can share the code and ideas that are currently running. It'll be a bit bittersweet though, since I put so much time into the care and feeding of the old controller. But, I'm sure I'll find a use for the parts in some future expansion of the system.
You can see the web page here <link> be kind though, it's a Raspberry Pi, not a giant web server.
In this post <link> I described the architecture I chose for the new device; I extended that to handle scheduled events such as turning the pool light on for an hour at 8PM to attract bats. Bats are fun to watch when they swoop over the pool catching bugs. Eventually I'll have a number of events because I intend to hook my drip watering system up to the network as well as a number of lights around the house.
I also added the three cloud services I update data to: Pachube (legacy Xively), the new Xively <link>, emoncms <link>, and ThingSpeak <link>. They fit right in the architecture without changing much at all. Over time I expect to extend it a bit more and have a tablet based application that can control the house like a remote control. The hooks are all there to add things over time.
Wow, was there a lot to think about. I had to make the processes restart after a power failure, which meant taking on the init process of linux. I upgraded the init process to use upstart. This piece of code is much friendlier than the older init process, but was a scary piece of work. See, if I screwed that one up I would have to start all over because it would have made my little Pi fail to boot up. So, I backed up the operating system image before I started and several times during the process. Fortunately, I did it right and the system came right up and worked. Now, all the processes start on boot up and are restarted whenever they die. This makes it cool because I can make a few changes, kill the old process, and the new one takes off and does whatever job I added to it.
I also added an update process for dyndns. When you get a controller like this working, it just makes sense to put it on the internet so it can be monitored from anywhere. Services like dyndns make this possible for us regular folk that have normal consumer DSL service. Our ip addresses change from time to time and we have to keep the internet name servers up to date. To do this, I had to take on the mysteries of the cron process. What a pain in the behind that was. No, the documentation out there is correct, but it's so easy to make a mistake, and so hard to find it that I spent almost a day messing around with that piece alone.
But I got it working. Here's a block diagram of the process architecture as it exists right this minute:
Notice how the cloud update services Xively, ThingSpeak, and emoncms just read from the database to update over the internet. Using this technique, I can try out other cloud services without making any changes at all to the ones that already exist. The event handler communicates with the House Monitor directly, it doesn't need to mess with any other processes to do its job. The Web Server has interfaces to the controls and database to keep the internet away. I'm trying to keep my neighbors from playing with my garage doors.
It's strange to imagine that a little arduino 2560 did most of this stuff for a couple of years. When you think about it though, the arduino was written in c++ and hand tailored to handle stuff over a long period of development. I only added the things I knew it could handle. Now, I can add capabilities that the arduino just couldn't do, which also means that I can off load some of the work that is handled automatically by other network devices if I need to in the future.
One of the great things I haven't experimented with yet is the web interface. I can easily edit new pages off the one I have now to show graphs, pictures, etc. This could get to be fun and offer a platform for other folks to get ideas from (that I would then steal and put in mine).
Later today I hope to massively update my page on the House Controller (see the tabs at the top of the page) so that I can share the code and ideas that are currently running. It'll be a bit bittersweet though, since I put so much time into the care and feeding of the old controller. But, I'm sure I'll find a use for the parts in some future expansion of the system.
You can see the web page here <link> be kind though, it's a Raspberry Pi, not a giant web server.