Smart home project using RPI's

BobS0327

Active Member
I'm currently working on a smart home project. My current thinking for this project is to use a cluster of Raspberry Pi's to distribute the various sub functions of the project. For instance, one Pi would just handle lighting control, another Pi would handle energy management and another Pi would handle home security.
 
The whole configuration would be akin to using blade servers in the corporate world. That is, each Pi would be “hot swappable”. If a particular Pi failed, it could immediately be removed and one of the other functioning Pi's would take over it's processing responsibilities until the Pi was repaired and placed back in service. IOW, I want 24/7 uptime for my whole smart home system. Right now, I have a one centralized controller that handles everything. If this controller fails, I lose all automation functionality and home security/fire protection. So, the reason for decentralizing all these functions is to minimize/eliminate any type of outage.
 
As far as electrical power backup is concerned, I now have redundant UPS's in place and an Automatic Standby Generator for the house. The UPS's would power the Pi's until the ASG powers up and goes online. Which is about 30 to 45 seconds after a power outage.
 
I'm considering using Linux Pacemaker High Availability (HA) OS with the Pi's http://clusterlabs.org/wiki/Pacemaker
 
I'm just wondering if anybody has done anything similar to this planned project and if so, would be willing to share some insight.
 
Been playing with the RPi2's from the RPi's and have two running 24/7.  It's been over a year now and I haven't worn them out. One is doing automation and the other is doing weather stuff.
 
That said still consider the RPi2 an inexpensive tinker toy for play and experimenting. 
 
I have read somewhere though about clustering hundreds of these devices.
 
Zipato sells modular automation / security Arm CPU cloud based automation / security devices. 
 
I am not sure how popular or how well they did in 2015.
 
They are introducing a new product called ZipaTILE and have posted it for pre purchase.
 
It looks a bit nicer than the Almond Plus.
 
It appears to be an all in one unit and a bit different than the ZipaBox stuff (or ZipaMini)
 
400x400.png
 
Been playing with the RPi2's from the RPi's and have two running 24/7.  It's been over a year now and I haven't worn them out. One is doing automation and the other is doing weather stuff.
 
I just started using RPi as a test platform for my upbserver.  It's running 24/7  automatically performing tests on the app. I have a remote windows client sending UPB commands about every 1 1/2 seconds to the server.  Commands such as turning lights off/on, dimming/brightening lights, getting the status of devices.  The commands are targeting all 19 of my interior/exterior devices.  Unfortunately, I can only do this "stress testing" about an hour or two a day.  I have to do it when my better half isn't home.  Lights constantly changing in and outside the house has a VERY LOW WAF.  The Pi has proven to be a very stable platform.  Wish I could say the same for my upbserver app.  It still needs a lot of "stress testing". LOL.
 
I have read somewhere though about clustering hundreds of these devices.
Yea, I read a few articles on the same.  One Boise U. doctoral candidate did build a 32 node Pi cluster configuration using the Beowolf OS as part of his thesis.  I can imagine what a Pi cluster looks like when all the nodes are doing some sort of parallel processing.  It probably looks like a psychedelic light show.
 
 
Zipato sells modular automation / security Arm CPU cloud based automation / security devices
I wasn't aware of Zipato until you mentioned it.  I personally think they have a great idea/product.  It looks like they "stole" my idea. LOL.  I hope they are successful in the US.
 
Just a thought on your testing Bob... Why not send commands from the Pi to non-existant UPB ID's, but capture and log them from a second PIM.  You'd see that the traffic is sending and being received in the way you want, but you wouldn't have physical devices turning on and off.
 
@Bob,
 
Curious if you are going to compile C or utilize Mono dot net UPB stuff with the RPi2's. 
 
While I do much with the OmniPro 2 (much = basics of automating stuff) I utilize the addition PIMs and status to automate more stuff via software and concurrently playing with remote UPB.
 
IE:  The Cumulus Weather station software on the RPi2 is talking to one serial port with a connection to the Davis console.  Concurrently testing a second serial and third connection on the same RPi2 to an HAI UPB PIM and a CM11A running software remotely connecting to the mothership using mono and Homeseer.
 
RPI2 (located on the second floor) ==> mono upb.exe server=ip of mothership (located in basement)  -> here the mothership devices / links appear as directly connected.  The UPE configuration file resides on the mothership.  What I send / receive I see on the other UPB PIMs and software (windows or linux).
 
i have issues with some stuff where if I just utilize all Linux then I am fine.  If I do Wintel to Linux or Linux to Wintel I sometimes have issues; but its just nomenclature.
 
Unrelated and previously mentioned noticed that the Almond + web sockets API was released.  With that you can turn the tiny Arm based device in to a multiple protocol controller of sorts (which will talk Zigbee, Z-Wave and Wireless + a serial PIM).
 
JonW said:
Just a thought on your testing Bob... Why not send commands from the Pi to non-existant UPB ID's, but capture and log them from a second PIM.  You'd see that the traffic is sending and being received in the way you want, but you wouldn't have physical devices turning on and off.
Thanx for the tip.  It'll also have a positive effect on my electric bill.
 
Curious if you are going to compile C or utilize Mono dot net UPB stuff with the RPi2's.
 
 I was  a "Big Iron" systems programmer using C  for more than 25 years. So, I would definitely use C (and C++) for some RPI2 coding.  Probably use it where sheer performance is needed or possibly to work on the kernel level.
 
I prefer the higher level languages such as C# or Java for doing GUI work etc.  It's just easier for me to write apps in Java or C# when performance isn't an issue.  BTW,  I initially started writing upbserver in C# but soon realized that serial port event handling is not (yet) supported in Mono.  Thus, the switch to Java.
 
Pete,  what's your "mothership"?  I assume it's a server of some sort to process upb commands. Can you elaborate on what exactly it is and how you use it.  I'm assuming that you might use it for some sort of lighting automation.
 
I don't have anything HA right now that's DIRECTLY related to a RPi, but the purchase of RPi led me to learn some Python. I've previously taken classes in C and C++, but never a full time programmer. So, while not WELL versed in software development I'm not afraid to try some things either.
 
Having said that, I recently wrote a Python program that will ping all of my network cameras every 5 seconds. If any camera doesn't respond 5 consecutive times, it will SSH into my POE switch and reboot the respective camera port. I haven't fully deployed this yet as I'm still trying to tweak a few things, but I've tested it a bit and it does work :) I also have it email [actually text] me if a camera is rebooted. Next up will be to read in a config file, or query the user for the device IPs and respective network interfaces to build the config file.
 
I do have some other things in mind for the RPi's and I've been working with a friend [software developer] on that project...
 
Yea, Python seems to be a really popular language.  I've seen it used quite a bit with RPI projects.  I've never really dabbled with Python but it seems as though I'm destined to use it with RPI since it seems to be the de facto standard for Pi projects.
 
I'd like to hear more about your project.  Also, your  network cameras program  sounds very interesting. 
 
I'm currently working on a RPI smart home project.  It's really a long term project since I want to get away from the boring "ho hum" home automation that's been done for the last twenty years or so.  IMHO, we have about a gazillion different ways to control/automate lighting.  I want to to do more than just turn a light on/off with my android.  I'd like to use proximity sensors etc.  to anticipate where an individual is going and turn the lighting on to light his path to his destination.  Also, possibly monitor energy usage per switch.
 
I guess I've grown tired of the status quo home automation such as triggering lighting, turning thermostats on/off etc.  There are a lot of good solutions on the market today for that type of home automation.  The last thing the market needs is another "whiz bang" HA solution.  I want to do something beyond HA.  I have a very vague idea of what I want to accomplish. My concept is very dynamic since I'm always encountering new and creative ideas from others that I can possibly use in one way or another.  Ultimately, my goal is to create a unique complete smart home  eco system using single board computers such as the RPI. Possibly display it at a 2017 Maker Faire.
 
To quote Captain Kirk, StarShip Enterprise, "Go where no man has gone before" in HA.
 
Pete,  what's your "mothership"?
 
It is Homeseer 3 running on Ubuntu 14.04 64 bit.  Homeseer talks UPB (along with other stuff). 
 
The Homeseer 3 minime version runs on the RPi2.
 
Many things to consider when working on the Pi. You can pretty much work with any language you want. If you want to do native development you might consider working with a mounted NFS/CIFS where you can put your tools. Or you can go the QEMU router and do your dev work on a faster machine and then drop your code directly on the actual Pi.

I like to use many different languages on the Pi depending what I'm doing (Perl, Python, Bash for scripting and cron stuff - usually). Node.js/node-red for web, and intermediate network work (great for talking to other web services) and then Python or C/C++ for performance. I really don't like Java but I do need to re-learn it. I do have to spend some time with C# (for HomeSeer). And despite the diminutive size of the Pi it's a real Unix server with some horsepower behind it. Don't be afraid to put more than one thing on it.

Next month I'll be doing a Smart Home presentation at TCF (March 19th, Ewing Township, NJ) where I expect to have MQTT, Misterhouse (Perl), various scripts and Node-Red running on the Raspberry Pi. And if I can get the Cell phone bridge working I may also have access to my SmartThings setup at my home. I still have a lot of work to make this all work on the road.
 
Here been playing with 1-Wire for a very long time.
 
Historically I have utilized serial connected 1-wire devices.
 
You can turn the RPi2 in to a 1-wire hub of sorts tapping using the GPIO ports on it or connect a serial / USB 1-wire hub to it.
 
These days Linux by default includes drives for established 1-wire type of transport.
 
Here have been playing with the GPIO pins on the RPi2 and i2C and am amazed what you can do with it.
 
Concurrently have also been doing similiar with a small microrouter which utilizes a slower CPU with less memory to tinker with and utilizes a base OS called OpenWRT (which uses Lua applications and a LuCi web server) using stuff I have learned from the RPi2 and the OpenWRT folks. 
 
This kind of takes an automation box to the size of your thumb which personally here I like.  (2" X 2" is still too big for me)
 
Last week on the Homeseer forum someone wrote a short script to be able to read the GPIO connected 1-wire devices.  I have added the pieces now to a script that I had reading the standard connected USB/Serial 1-wire devices.  Combining these two scripts I can generate Homeseer variable devices.  I can do all sorts of things with these devices as I have done similiar with Homeseer 2 over the years.
 
My approach to writing Java code for the Rpi is to use a Windows 10 machine with an Eclipse IDE installed.  I build the app on the Windows box and then export a Jar file which is copied over to the RPI using Bitvise SSH server.  The Jar file is then executed on the RPI for testing purposes.
 
I've also realized that I can do the same for .Net (c#) code.  Essentially build it on a "muscle" Windows desktop and copy the binary over to the RPI which would run the binary atop of Mono.
 
I'll definitely have to check out the QEMU router.  Looks like that may be real handy for my C,  C++  and other language applications.
 
One wire is definitely interesting for the RPI.  I like the idea that you can connect a lot of DS18B20 sensors in parallel on one wire.  Also, the price is right for these sensors. around $3 each.  I've been accustomed to pay $60 each for sensors attached to security controllers etc.
 
I've always wanted to go to the TCF but for one reason or another, it never happened.  Maybe this year is the year I'll be able to make it.  I'm about a three hour drive away.  If I do make it, I'll definitely check out your smart home presentation.
 
Well the good new is that I now have control of the SmartThings devices. I only have one outlet setup so far but I can monitor the other devices.
 
Now I'm also attempting to publish data to some simulated devices. That isn't going so well. I publish value X on Device A and Y on B. But I see Y on A and X on B. I haven't figured this out yet. I'm pretty much done for today/
 
Even better news, I've got a ton of stuff working with SmartThings. I just added 3 replacement smokes. I think next the Vera is about to be retired :). Tomorrow I sit down with my friend and we start working on the cell modem he has (commercial, expensive). I have the material for the introduction of MQTT, SmartThings, Misterhouse, and several devices we'll be working with. I hope to have MQTT setup with HomeSeer3 (perhaps on the Pi, we'll see). A nice mish-mash of a working mess. Totally impractical and yet curiously tempting. ;-)
 
Back
Top