…and I can start looking at home automation again. So my first bit of research post warmth has been to look at setting up a browser based interface for opening, closing and displaying the current state of the garage door. Yah, I hear you…it’s not that sexy of a project. It fills a need though. You see, we’ve had a couple of incidents where a resident of this house (who will remain unnamed) has left the garage door open for extended periods of time. By extended, I mean all night. So wouldn’t it be nice to have something where I can tap my phone, have a scheduled ‘closing’ event or just be able to look and see if it is closed.
Enter our garage door system…the LiftMaster 8355
We have a keypad outside for entry to the garage and by the door into the house there is a multi-function control panel that allows us to turn on the system’s lights and open/close/stop the door. From what I gather most garage door systems traditionally have had a ‘short-to-trigger’ style system which allowed you to easily interface with them and kick off the movement of the door. Chamberlain (the underlying manufacturer of this system) did away with that and has implemented a proprietary communication between the keypad and multi-function control. From what I can figure out the communication across the wire is serialized so you can’t simulate another device.
That’s okay though because Chamberlain has created something that they call MyQ. This is a system that requires you to purchase a ‘hub’ that enables wireless communication between phone apps and a website (hosted by Chamberlain) and your garage door. Here’s what the system looks like conceptually.
So yah…there are no moving parts in there what-so-ever. There is no architectural way around this. The wireless protocol from the LiftMaster to the MyQ hub is proprietary and unknown. There is some speculation that it is a modified implementation of Z-Wave, but nobody seems to know speculate more than that. The communication between the MyQ Hub and the Chamberlain servers is also proprietary, although I think I could sniff the wires to see what is being sent. Certainly the calls between the phone apps and your browser can be sniffed and someone has created an unofficial api based on some of that work. That api doesn’t help the overall architecture any. The two main points in the architecture are the MyQ hub (which is an additional $129 US investment that you must make) and the Chamberlain servers.
If the Chamberlain servers go offline (for maintenance or otherwise) the whole system goes offline. You can be sitting 5 feet from the MyQ hub clicking furiously on your phone app and the door will not move. Granted, you could walk over and push the multi-function panel button, but that’s not the point here. If you can’t get data service from your smart phone, neither the phone nor the website will be of use to you since you can’t get to either. The problem with these is that both of these known points of failure that you and I have no control over. The success of our “smart home” experience is being entrusted to someone else.
Since you’re here at my blog, you’re likely a developer, so let me put this to you another way. Today nuget.org experienced an outage. Not a “server is down” outage. Not a “internet is unavailable” outage. It was an outage caused by a bad DNS record. Remember when Azure had that happen? Not cool right? Nuget.org being down today was one of those things that probably really annoyed a whole bunch of developers. It likely didn’t stop them from doing some work, but it was another burr under the saddle. The whole architecture implemented by Chamberlain has the same potential. DNS issues, routing issues, maintenance, etc…they can all become a burr under the saddle of our smart home experience. I’ve had my share of burr under the saddle moments and as I get older I’d like to have fewer.
To me that means eliminating moving parts. The first thing I want to do is drop the reliance on the Chamberlain servers. That takes a lot of the possible fail points out of the equation. Ideally I’d like to drop the MyQ Hub. It’s $129 expense and it doesn’t add any additional value to the smart-home experience beyond enabling communication to the LiftMaster. That leaves two options:
- direct access to the wireless protocol used to communicate between the LiftMaster 8355 and the MyQ Hub
- direct connectivity (short-to-trigger) at the LiftMaster
Today I took to twitter to ask Chamberlain why they don’t want to enable option #1 as a direct API. Ironically their twitter handle is @chamberlaindiy….yet you can’t DIY anything with this system.
@dbelcham We’re integrating with several tech partner systems, including @Nest and @TheWinkApp. Also part of the HomeKit smart home platform
— Chamberlain-DIY (@ChamberlainDIY) September 3, 2014@dbelcham At Chamberlain, safety & security are our top priority. We’d be happy to discuss further offline if you’d like.
— Chamberlain-DIY (@ChamberlainDIY) September 3, 2014
So they think that keeping things proprietary and in a tight circle of integrators is the best thing since “…safety & secruity are our top priority”. Essentially they’re promoting security through obscurity which is commonly accepted as one of the most dangerous things you can do with a security system. Think about the security issue a bit more practically though. Is the garage door the biggest attach surface that is available on your house to a criminal? Is it the easiest? I’d answer no to both of those questions and argue that the windows and exterior doors offer more options for entry and that those options are easier than hacking your garage door opener. Even if you did hack the garage door, and get it open, an attached garage will usually have an exterior grade door between it and the house. Maybe I’m a chronic door locker, but I treat that door like any other exterior door when it comes to locking it. So really, at a practical level, the only thing that you’re trying to protect by having proprietary communications is whatever is in the garage. That’s the worst case scenario…a poorly implemented device/system using the API (much like was exposed at Black Hat 2013 on the proprietary Z-Wave home automation protocol). Heck, that can happen right now if one of Chamberlain’s integration partners do a poor job of implementing the proprietary MyQ protocol.
@chamberlaindiy reached out to me to have a conversation offline about my concerns so hopefully sometime in the near future that will happen and maybe…..just maybe….I can convince them that opening up a well written communications api would be in their best interest.