Saturday night we stayed at the Stephen Foster Folk Culture Center State Park in White Springs, FL. This was an amazing experience. The roads are small, so I was a bit nervous driving our big rig in the small, twisty turny roads. It was worth it though. Our site was fairly secluded, and the foliage so dense that it was like it was fenced. We were a bit sad that we only had one night here.
On our way to Tampa we stopped about half way at Meaher State Park in Alabama. It’s located across the bay from Mobile. We arrived here Sunday afternoon, then I worked from here for the week.
It’s a very nice park with a lot of space between sites. We also stayed here Saturday night on our return back from Tampa.
For over ten years now, it has been a dream of ours to be able to live and work in our RV from all over America. I’m delighted to say that the dream has finally become a reality.
Shelley and I have been living in an RV for about 12 years now, but the combination of finances, technology, and family responsibilities have limited our ability to be away from the Austin area. As a programmer, I can basically do my job anywhere as long as I have a good internet connection. But many RV parks have terrible Wifi, even if they advertise that they have it. And cellular plans with broad coverage and high data limits have been pretty expensive. But the cost of cellular plans continue to drop, and coverage areas are continuing to expand. So this past year I think things finally reached a point where we can afford to get good coverage just about anywhere in the US.
Our plan is to travel on weekends, then work Monday through Friday wherever we happen to be. Also, since this is going to be an ongoing thing, we’re not going to be driving long days when we travel. It’s one thing to put in a long driving day for an annual vacation or such, but totally different when we’re doing it every weekend. Driving and seeing new places is a lot of fun when it’s only a few hours a day. It stops being fun when those drives are over about 4 hours or so. So we’re trying to limit our driving to about 4 hours per day.
We started gradually, testing out the idea of working using just cellular connections by making short trips to nearby state parks without Wifi: McKinney Falls, about 30 minutes away, and then Inks Lake, less than an hour away. These worked out just great.
So now we’re in the process of testing being away for a whole month. We’re traveling to Tampa, FL to spend a couple weeks visiting with our daughter Jackie. Sticking with our “4 hours per day” plan, we’re planning on driving from Austin to Meaher State Park in Alabama over the weekend of April 23-25, then staying and working from there for a week. Then we’ll drive from there to Tampa FL over the weekend arriving on May 2nd. We’ll stay and work there for 2 weeks. And we’ll see how it goes, and learn and make adjustments as we go.
If you’ve been following my home automation activities, then you know that I’ve been fairly invested in using Alexa. Even though I live in an RV which basically has only 3 rooms, I am using 4 (sometimes 5) Echo devices. These provide a very rich voice control experience and I’ve been very happy with them.
A problem with using Alexa, at least from the perspective of one living in an RV, is the requirement of having an internet connection. Without a live internet connection Alexa is dumb as a box of rocks.
However, Alexa doesn’t need a fast connection. So I’ve setup my networking to connect my router to a Verizon Jetpack while I’m on the road. Since I’m a Verizon unlimited customer already, adding a Jetpack only costs about $10/month. It provides 15 gig of high speed bandwidth then throttles down to 600k, which is actually enough for Alexa and for communicating with all my IoT devices. So it continues to work even if I’ve used up the high speed bandwidth.
It’s been a fun year playing with creating home automation software, but totally unproductive. I had decided to write my own Mac Mini, Swift based programming to control all my IoT devices. I did this, and then ran into lots of issues trying to interface with all my IoT devices. To make matters worse, the things I was trying to interface with kept changing (eg. new Samsung Smartthings APIs, programming language, etc). So while I think I came up with a pretty powerful code base for automating my home, I hadn’t actually automated anything in the past year. So I’m going to call that a fun learning experience, but I need to change direction if I actually want to automate my RV home.
Home Assistant v0.91
I experimented with using Home Assistant. For me, it actually made things much more complicated. There are no off-the-shelf solutions for automating the 12v lighting system of an RV. So I have to create my own IoT solutions, and integrating that into another system like Home Assistant just adds another layer of complexity.
Rolling My Own
So having experimented with using Home Assistant, SmartThings, and Homekit, I eventually ended up using the Alexa skills I wrote awhile back, along with Patriot custom Photon coding.
Ok, I feel extremely nerdy. Did you see the episode of The Big Bang where they program an IoT device to turn on a lamp by sending a signal all around the world before it gets back to the lamp to turn it on? Well, I was suddenly struck by the similarity when I got Alexa to turn on the Z-Wave light bulb in my desk lamp last night:
- “Alexa, turn on desk lamp”
- The voice command is picked up by the Alexa Show device on my desk and sent to Amazon cloud.
- Alexa Smart Home converts the audio command to a “turn on desk lamp” intent and routes it to my Alexa Smart Home skill running in an Amazon Lambda in the cloud.
- My Smart Home skill converts the intent and forwards a “turn on desk lamp” command to Particle.io.
- Particle.io publishes the command to my Photon IoT controllers, one of which is acting as a bridge from particle.io to MQTT.
- The Photon bridge reformats the command and publishes it to MQTT.
- The MQTT broker is running on a Mac Mini, which then forwards it to all other devices subscribing to MQTT.
- One of these MQTT subscribers is the smartthings-mqtt-bridge app running on the Mac Mini. It then receives the MQTT “turn on desk lamp” command, and forwards it to the Smartthings web hook over the internet.
- (Should I mention the Wifi to router to … Nah).
- The Smartthings server receives the command via web hook, routes it through a Groovy program running in Smartthings, and forwards the command to my Smartthings hub over the internet (and router to wifi, etc).
- My Smartthings hub then transmits the “turn on” command over Z-Wave radio to my desk lamp light bulb.
- And the light turns on.
I’ve turned a corner in my thinking about how best to automate my home. For years now I’ve been trying to integrate and generalize all of the various technologies (MQTT, SmartThings, Particle.io, Alexa, iOS, Raspberry Pi, etc) to provide a simplified interface for controlling everything. The tough part is really describing what I want the system to do; how it behaves. Using an any sort of text or table driven, simplified, abstract programming model always comes up short. By this I mean the sort of approach where I am allowed to specify things such as “if device A is on, and the time is after HH:MM PM, then set device B to XX”. This works great for doing fairly simple things, but doesn’t really handle the more complex types of scenarios I always run into, or if it does handle it, it does so in a manner that gets very complicated and unmaintainable very quickly. As a professional programmer, this situation is very familiar, and describes what happens with poorly written code. So I started thinking about how to solve this problem in a way that would be greatly extensible and very maintainable.
And I got to thinking about how Patriot automatically detects new devices. Well, sort of automatic. If I program a Photon to expose a device, and write the Photon code to implement that device, then Alexa can detect it and control it with voice. That’s very cool, but I’m getting tired of having to tell Alexa which lights to turn on and off every morning and night. I want my home automation system to know when to do that based on the plethora of sensors that I’ve installed.
So then the big ah-ha moment for me. Automatically detecting and installing devices doesn’t provide any automation until I write some sort of specific code to control it. This could be generalized code such as IFTTT, or bare bones custom code like Photon C++ or Python code on a Raspberry Pi.
One of the issues that frustrates me is the large number of different programming languages and platforms I’ve had to work with. So recently I decided to replace my Raspberry Pi with a used Mac Mini in order to reduce the number of different programming languages, environments, and platforms I have to remember and work with. The 2010 Mac Mini is quite powerful and flexible, and I found one on craigslist for $150. It’s now my media center as well as my MQTT broker and home automation controller. And I can program it in Swift, which is my daytime job programming language.
So if I have to write code no matter what, why not do it using the best tools, environment, and clean programming practices? To my mind that means Swift programming on the Mac Mini.
So that’s where I’m going with Patriot 4. I’m writing a Mac app in Swift using clean, TDD code. I’ll be sharing the Swift framework that is evolving out of this, but it’s going to require Swift programming skills in order to use it. I’m excited to see just how far this can go.
Monday morning we had time to venture out for one last time before beginning our flight back to the U.S. in the afternoon.
We still had not spotted any Rhinoceroses, so that was our primary objective.
As we were leaving, we passed the Balloons getting ready to take off.
And so we got one final group picture as we’re getting ready to hop into the trucks to head back home.
Sunday we packed a lunch and headed out again. We had a full morning of Lions,
And of course Hippos.
We drove down to the Tanzanian border, and some of our group crossed over illegally.
In the afternoon, we visited a real Masai village.