This weekend I had some fun with the SiriProxy project. It is a neat little hack that allows you to intercept Siri commands on your iphone and handle them locally when applicable. The github project does a great job of helping you get up and running, but chances are there will be a few steps that are slightly off and will require some finesse. Don’t be intimidated, just read through the snippets and google when necessary. You can get it going, I promise.
Super short overview of steps (c’mon, read the docs from the siriproxy link above!):
- setup dns masq, either on yer linux/mac box, or on dd-wrt
- install the RVM (this might take a while if you aren’t familiar with it)
- install siriproxy following their steps, and realize halfway thru that they have some of them out of order, read more docs and swear a bit, but then realize it wasn’t that bad
- generate a siriproxy certificate, email it to your phone and click to install (no jailbreak needed!)
- launch the proxy, fiddle with your wifi and dns until the test phrase “test siri proxy” actually works
- download one of the available plugins and begin to learn ruby!
I already have a local linux fileserver on the network, so it was an easy decision for me to utilize that as the home for this thing. I began setting up DNS Masquerading (to allow you to reroute the Siri calls to our proxy without having to jailbreak your phone), but then quickly remembered: I am running dd-wrt on my router. This means that I have dns masquerading built in, so I was able to simply add the necessary arguments to the ‘optional’ field, and everything was magically being sent to the right place.
I already have about 10 lamps around my home plugged into Insteon modules, and I was given some great advice to try out Perceptive Automation’s Indigo server to tie them all together. This has been great in of itself, because it allows me to create “Action Groups” to combine tasks together. For example, I have simple things like “bedroom off” that turns off all of the lights in my room when I’m ready for sleep, or “Movie Time”, that turns off some of the living room lights, and dims others to an appropriate level for watching television. Combine this with a great (and free!) iOS application and I thought my home automation needs were completely met. That is, until I realized I could just use my voice.
More googling showed me that my awesome Indigo server allowed me to access it via REST’ish commands, even with the cheapest license! I knew I liked these guys. I checked out their guide on doing so, and saw that I could definitely hack together a quick proof of concept for this project.
Given that I’ve never touched Ruby before, I wanted to see how some others were approaching it. Luckily, github came to the rescue again. I found hoopty3‘s plugin that he had written for the ISY99i, which used a very similar methodology as I would need. Honestly, at this point all I had to really do was take the same approach and change the URL structure to match my needs. Dead simple.
All in all, it was about 4-5 hours of playing around.. most of which was me trying to wrap my head around Ruby and how to approach it. I’m still not there yet, but I have some good ideas on what to do next. The biggest problem for me is that I typically have multiple lamps in a room. This means that I can’t simply say “dim the lights” and make a single call. Instead, I’m going to have to write out a small configuration file that lets ruby know which lamps are in each room, and then poll them to see if they are currently on, and if so, dim them appropriately. This doesn’t really sound too bad, I’m just worried that making a “separate database” (outside of Indigo) to store this information is going to lead to confusion down the road, and I’m concerned that having ruby check the various levels for the room before taking action is going to take too long. Admittedly, we’re talking about seconds here, but hey, I want immediate response!
This was definitely fun and worth a shot if you’re looking for something to try out. It’s not 100% accurate, as there are many moving parts that can cause this to fail, but it’s pretty darned good and gives you awesome geek cred.
Points of failure I’ve encountered so far:
- Sometimes Siri bypasses your proxy and talks to the real server and gets stuck there. I’ve found that if I lock my phone and then re-open it, and THEN try to access Siri, it will go back to my server again. But if you just keep asking it, it maintains its persistent connection to the real deal.
- Sometimes your DHCP might not be setup how you think it is. Meaning, it points you to someone else first, and you have to make sure you are only talking to the host running dns masq.
- Sometimes the SiriProxy app just crashes. If I dive into this one more I’ll need to make a watchdog service.
- It’s hard to think up all the possible ways you might ask it to turn the lights on. The English language provides a LOT of flexibility in this regard, and creating the regex to capture the various syntaxes is kinda quirky. But, oddly fun.