With the recent Chamberlain API lockdown, I thought it might be interesting to tear down one of their controllers to see what makes it tick. Thankfully I happen to have a spare unit sitting new in the box. Why do I have a spare unit you might ask? The standard package comes with what Chamberlain calls a WiFi hub and a single door sensor. I have 2 garage doors, each with openers. At the time a spare door sensor was most of the cost of the whole package, so I just bought the whole thing again.
The WiFi hub is incredibly simple to disassemble. There are just 2 screws that hold the faceplate to the frame. Once you remove the faceplate, a single snap lever retains the main PCB. Once I had the main PCB separated from the frame, it was easy to pick out the core components.
The system is based on a PIC18 microcontroller. In this case the Microchip PIC 18F67J11-1/PT. The PIC18 is a 16-bit RISC CPU compatible with the earlier PIC16. It has 128KB flash onboard and 4KB of RAM. While it’s no powerhouse, the CPU does offer 4 interrupt lines, 5 PWM, Parallel and Serial ports with SPI and i2C support.
Linked to the PIC18’s i2C bus is a 24C16K SPI Flash ROM. I had a compatible harness for this and dumped the contents which were mostly empty. I’m assuming this rom is used for configuration data, possibly to store the opener codes programmed in during initial setup.
The remaining modules of interest were an Si4432 433mhz transceiver chip (left) and an Fn-Link 6220N-IS 2.4Ghz WiFi 5 module. (right) These enable comms with your network and most garage door openers.
So, what can we do with this knowledge? Well, given the CPU has a built-in flash, we could attempt to dump the contents of that storage and see if there’s anything useful we can decipher from it. There are test points on the board that appear to be connected directly to the CPU for programming. I’m going to attempt to verify this against the datasheet for the PIC18 and see if that’s the case. To be continued…
Over the last week, garage door product company Chamberlain made a sudden move to cut off all third-party access to it’s cloud APIs. Chamberlain was known for making products like garage door openers and control products, but had begun offering cloud connected smart devices to go along with these in recent years. These smart garage door control products were sold in big box hardware stores like Lowes and were advertised with Amazon and Google compatibility at relatively low prices. (update: the package I purchased did not mention anything about third party systems, only that you could download the app for your phone via the App Store or Google Play.)
While we were going through a renovation project at our home, I wanted to be able to integrate our garage door openers with a smart controller so that I could open the doors for a contractor/sub if they sent someone who didn’t have the code, or had trouble with the external keypad. Chamberlain’s MyQ smart garage door controller seemed to have all the right options. Low cost, compatibility with major home automation systems from Apple, Google, Amazon and even Homeassistant integrations. It seemed like a no-brainer. Remote access to the garage door worked out great for the renovation project and I later integrated the system into my existing Homeassistant setup.
This setup worked perfectly until this week when Chamberlain made the decision to cut off API access to Homeassistant and any other “unauthorized” third party. Chamberlain claims that Homeassistant traffic was overwhelming at times, (to the point of effectively being a DDOS attack) and used that as an excuse to shut it down. However, this doesn’t seem to be the true motivation as they’ve also been slowly backing away from all external integrations they don’t directly control. This leaves consumers of their devices with products that may not work as advertised, controllable only via the smartphone app.
This is the danger inherent in cloud based consumer products. They may be cheap and they might work today, but the manufacturer can change the functionality at will and there’s little to nothing that you can do about it. Devices you paid good money for can become a paperweight overnight when the manufacturer decides they no longer want to support it, or wants to change the terms of service. (perhaps charge fees for access to features that were once free) This seems to be the case with Chamberlain, seeking payment for access to APIs and courting paid integrations with automotive manufacturers and security companies.
If you are looking to build a smart home system and you’re thinking about which device ecosystem to go with, I would highly recommend doing your research. Look for devices with local control via Z-wave, Zigbee, Matter, or Thread. WiFi products can work too, but make sure their core functions aren’t tied to a cloud service that could go away at any time.
I’ve been using RedHat Linux in various forms for the last 26 years or so. I started back in 1997 with a boxed copy of RedHat Linux 4.1. It wasn’t the first Linux distro I tried, but it was the first one that I really liked. I kept buying boxed copies of it through version 6.1, around the time when the first release of RHEL dropped. (it’s hard to believe that was 23 years ago) You see, back in the olden days internet speeds the typical person could get were largely via modem and
far too slow to grab entire CD images in a reasonable time. Buying a boxed copy every time a new version was released both supported the company and allowed me to get a fresh set of installation media in my hands right away.
So why am I quitting RedHat you might ask? The recent news of RedHat Enterprise Linux essentially going closed source, (yes, I realize this is debatable) was the straw that finally broke the camel’s back. However, I’ve had this urge many times in the past due to similarly bad decisions by the company and I’m finally just done. So where did this start? For me, it started with the last release of RedHat Linux 9 being merged into the Fedora project. (as you’ll see, what’s old is new again) When RHEL was initially released to the public, it was based entirely on RHL with some add-ons that were exclusive to RHEL. As time went on, RedHat realized that some of their customers weren’t buying RHEL and were just sticking to RHL, often just grabbing the ISOs for free.
RedHat didn’t like this and felt the existence of RHL as an upstream distribution was potentially hurting their sales of RHEL and decided to kill it in favor of a faster-paced and shorter lived variant that would become Fedora. At the time, I thought this was great… newer packages, more frequent releases… what’s not to like? What I didn’t know was the pain that would come from sticking with the free version. Initially, the short support cycles weren’t all that bad. You could in-place upgrade from one Fedora version to the next and be back up and running in short order. This didn’t last though, and soon it was better to just wipe and reinstall from scratch. This difficulty wasn’t just some random experience, it was by design to drive IT pros into the RHEL fold.
For hobbyists or IT pros wanting to practice with a stable RHL/RHEL style OS there was no longer anything available until CentOS arrived on the scene in 2004. (there were others as well, but CentOS was so close to RHEL that you could use it as a drop-in replacement for RHEL for nearly any application.) This server ran on that distro for the last 15 years and all was good until RedHat, again frustrated by something they perceived as taking business away from RHEL drove them to change the game again. RedHat planned and executed a coup that would see ownership of CentOS transferred to RedHat which laid the ground work to kill off CentOS as it existed at the time. In December of 2020, RedHat announced that CentOS would be discontinued in 2021 in favor of a new offering called CentOS Stream. This new distribution wouldn’t be a replacement for CentOS, but would rather become a Fedora-like upstream for RHEL. (fast release cycle, but unstable) Basically, Fedora is the bleeding edge, new stuff is constantly migrated from Fedora to Stream after testing and a stable version/snapshot is occasionally cut from Stream and used to build the next point-release of RHEL.
Modification of graphic from ServeTheHome
The final nail in the coffin was a blog post on 6/21/2023 by Mike McGrath, VP of Core Platforms at RedHat announcing that “CentOS Stream will now be the sole repository for public RHEL-related source code releases.” What this means is that access to the actual source code for RHEL is now locked behind a RedHat subscription. This is a direct attempt to kill off successor distributions to CentOS such as Rocky Linux and AlmaLinux. Rocky Linux did make a statement on their blog that they, “[remain] confident in [their] ability to continue as a bug-for-bug compatible and freely available alternative to Red Hat Enterprise Linux (RHEL), despite changes in accessibility.” However, the writing is on the wall. RedHat intends to stamp out copycats of RHEL for good. In a follow-up blog post, Mike tries to explain that RedHat isn’t evil and then rails against what he sees as essentially freeloaders stating, “I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous.” Nobody is profiting from the re-packaging, but I’m pretty sure this is a veiled reference to Oracle. (Oracle doesn’t charge for their RHEL derived distribution, but they do sell service and support)
What’s actually disingenuous is claiming that everyone who wants to use your source code without paying is a freeloader. Let’s not forget that RedHat wouldn’t exist today without the free contributions of thousands of open source coders over the last 3 decades. RedHat stands on the backs of these members of the open source community who receive little to no compensation yet feels aggrieved by those who want to use code they have the rights to under the GPL for free. The backporting and all the support effort Mike references in his post are self-inflicted and the very reason companies pay to get their product. Let’s be clear, those who use “rebuilder” distros like CentOS of old, Rocky, or Alma are not RedHat’s customers. If they had a need for RedHat’s support services and could afford it, they would be, but they’re not.
As for myself, I’ve been hanging onto this RHEL compatible distro and it’s ecosystem mostly out of nostalgia, experience and let’s be honest… laziness. When the initial shutdown of CentOS was announced, I created a replacement VM based on Debian/Ubuntu and planned to migrate, but never did. Instead I stayed on CentOS until the updates dried up and then migrated to Rocky. (big thanks to the Rocky Linux team for making that a mostly painless process) However, with this latest chapter unfolding I don’t see the point in staying in the RHEL/RedHat ecosystem. (at least not for anything I care about) RedHat’s senior leadership has made it clear that they are going to make it as hard as possible for anyone to duplicate RHEL going forward. I feel bad for Rocky and Alma, but I’m done being a victim of the chaos caused by RedHat’s periodic jealousy. Today, I built a fresh Debian 12 VM and migrated this blog to it. I already feel better, my packages are more up to date, but equally stable and it didn’t even take that long. Farewell RedHat, I hope this path works out for you, (I honestly do) but if it doesn’t you’ll know exactly why that is.
