The myQ link between Chamberlain openers and Home Assistant has been dead since December 2023. The fix is a small controller that talks to the opener directly instead of going through the Chamberlain cloud. Every Home Assistant garage door controller in this guide keeps the open, close and door-state handshake on your own network, so the door still answers when the internet or the vendor API is down.
We compare six local-control picks. The Konnected blaQ, the ratgdo32 and the HomeKit Meross MSG150HK cover Chamberlain-family Security+ openers, the Konnected GDO White handles wall-button openers, and a Shelly relay with a door sensor is the DIY route. The Tailwind iQ3 rounds it out for garages with more than one door. The picks were judged on maker spec sheets, current listings and the Home Assistant integration docs, not on a garage of our own. I confirmed the Shelly garage cover YAML below working on Home Assistant 2026.10 in October 2026, with the relay and reed switch simulated on a lab VM.
Pick a controller by what your opener speaks
The opener decides the shortlist before any feature does, because a controller either speaks the opener’s wire protocol or just shorts the two wall-button terminals. Here is where we would start:
- Best overall for Security+ 2.0 openers: the Konnected GDO blaQ. It ships pre-flashed with ESPHome, needs as few as three wires, and reports real door state from the opener itself.
- Best value, and Home Assistant’s own suggestion: the ratgdo32 (or the ratgdo32 disco with vehicle sensing). Cheapest way to the same Security+ control, if you don’t mind flashing it from a browser.
- Best for any wall-button opener: the Konnected GDO White, with a built-in laser that measures door position.
- Cheapest DIY build: a Shelly 1 Gen4 relay plus any door contact sensor, tied together with a template cover.
- Least tinkering on a Chamberlain-family opener: the Meross MSG150HK, paired to Home Assistant as a HomeKit device.
- Worth watching for two or three doors: the Tailwind iQ3 2.1, though Home Assistant documents only the first-generation iQ3 so far.
None of these will drive an opener with a white learn button. That is Security+ 3.0 from Chamberlain, and the next section explains why it shuts out every wired add-on on this list, so check the button before you order anything.
Check the learn button before you buy
Chamberlain-family openers (Chamberlain, LiftMaster, Craftsman, Merlin) have a colored learn button on the motor head, and its color tells you which protocol the wall button speaks. Security+ 1.0 and 2.0 openers send a serial signal down the wall-button wires, so a plain relay that shorts the wires cannot drive them reliably, which is why ratgdo and the blaQ exist. Older and non-Chamberlain openers usually close a simple dry contact, and any relay works there.
| Learn button | Protocol | Controllers that work |
|---|---|---|
| Yellow, round | Security+ 2.0 | Konnected blaQ, ratgdo32, Meross MSG150HK, Tailwind |
| Purple, or red on most models | Security+ 1.0 | Konnected blaQ, ratgdo32, Meross MSG150HK, Tailwind |
| White, round | Security+ 3.0 | None of the wired controllers here |
| Square buttons (green, gray, white or yellow) and non-Chamberlain openers | Dry contact | Konnected GDO White, Shelly relay, ratgdo32 (with a status sensor), Tailwind |
The round white button is the one to fear. Chamberlain shipped Security+ 3.0 in late 2025, and The Verge reported that it blocks aftermarket controllers such as Tailwind, Meross and ratgdo, while Konnected lists Security+ 3.0 openers as incompatible. If your opener has one, the realistic choices are the Chamberlain myQ app or replacing the opener, and no amount of Home Assistant config changes that.
That is also the history behind this guide. Home Assistant removed the myQ integration in 2023.12 after Chamberlain blocked third-party access to its API, and the project pointed users at ratgdo instead. Every pick here keeps the vendor cloud out of the control path, so a cloud shutdown like that one leaves them working, though Security+ 3.0 shows Chamberlain can still lock out local controllers on new openers.
Compare the six Home Assistant garage door controllers
Side by side, the picks line up on the things that decide fit: how the controller reaches the opener, which Home Assistant integration carries it, and whether door state comes from the opener or from a sensor you mount. Prices are the bands we saw in late October 2026, so check the live price before you buy.
| Controller | Talks to opener over | Home Assistant path | Door state from | Price band |
|---|---|---|---|---|
| Konnected GDO blaQ | Security+ 1.0/2.0 serial | ESPHome (official, local) | Opener | About $89 |
| ratgdo32 / ratgdo32 disco | Security+ 1.0/2.0 or dry contact | ESPHome (official, local) | Opener (Security+) | About $62 / $94 plus shipping |
| Konnected GDO White | Dry contact | ESPHome (official, local) | Built-in laser or wired sensor | About $89 |
| Shelly 1 Gen4 + contact sensor | Dry contact | Shelly integration + template cover | Sensor you add | About $28 plus sensor |
| Meross MSG150HK | Security+ 1.0/2.0 (Chamberlain family only) | HomeKit Device (official, local) | Opener, no door sensor needed | About $70 |
| Tailwind iQ3 2.0 / 2.1 | Digital link to many openers, or dry contact | Tailwind integration (documents first-gen iQ3 only) | Opener (digital) or optional sensor | About $90 to $115 / $100 to $125 |
Read the “door state from” column first. A controller that reads state from the serial bus of the opener (blaQ, ratgdo on Security+) knows the door is opening or closing, sees the obstruction sensor and needs nothing glued to the door. Everything else infers state from a sensor, which is fine until the sensor battery dies or the magnet shifts on the door. That is the most common reason a DIY garage cover lies about being closed.
Wire a Konnected GDO blaQ to a Security+ 2.0 opener
For most Chamberlain and LiftMaster owners who want the myQ features back without flashing anything, the blaQ is the pick.
Konnected wires the blaQ to the wall-button terminals of the opener with as few as three wires and speaks Security+ 1.0 and 2.0 directly, so it works with Chamberlain, LiftMaster, Craftsman and Merlin openers that use those protocols. It runs ESPHome from the factory, which means Home Assistant discovers it through the official ESPHome integration and everything stays on your LAN. You get a cover entity with real door state from the opener, plus the extras the serial bus exposes, such as the light and obstruction status.
Look elsewhere if your opener has a white learn button, which Konnected lists as not compatible, or if you’re outside North America, because Konnected notes that some EU, AU and NZ openers lack the serial terminal it needs. It also costs about $27 more than a ratgdo32 for the same protocol support. You’re paying for a finished enclosure, pre-installed firmware and app-guided setup, and for most people that’s money well spent. It sells for about $89 on Amazon and at Konnected’s store; check the live price.
Flash a ratgdo32 for the cheapest Security+ control
ratgdo is the open hardware project Home Assistant recommended when myQ went away, and the ratgdo32 is its current ESP32 board.
Wire the board into the same terminals as the wall button. It supports Security+ 2.0 (yellow), Security+ 1.0 (purple, and most red buttons) and dry-contact openers. Load the ESPHome firmware from the browser installer of the project over USB-C, and it shows up in the ESPHome integration with the same kind of cover entity the blaQ gives you. MQTT and HomeKit firmware builds exist if you want those instead. The ratgdo32 disco adds a laser vehicle presence sensor that reports a car arriving or leaving, a beeper and wider obstruction sensor support (up to 16 V DC), while the parking-assist laser is sold separately.
Pass on it if you want something sealed and supported like a retail product. It arrives without firmware, you flash it yourself, and it’s sold only from the ratcloud store, not Amazon. On a dry-contact opener it also cannot read door position by itself, so you need limit switches or the ratcloud encoder add-on. The ratgdo32 runs about $62 and the disco about $94 before shipping; check the live price on the store.
If you already keep spare boards around for ESPHome projects, our ESP32 boards for ESPHome guide covers the flashing workflow ratgdo uses.
Use the Konnected GDO White on a wall-button opener
Openers that are not Security+ (Genie, many Linear models, older units) just need a relay across the wall-button wires, and the GDO White is the most polished way to do that.
It is an ESP32-S3 board running ESPHome with a dry-contact relay that simulates a wall-button press. Its party trick is an optical time-of-flight laser that measures the distance to the door, so you get open and closed state without a sensor on the door itself. Konnected says the laser works best on ceilings around 8 to 13 feet; for anything else there’s an optional wired contact sensor. It runs from the 12 V DC adapter in the box and talks to Home Assistant through the ESPHome integration, fully local.
It’s the wrong box for a Security+ 2.0 opener, because a relay cannot speak that protocol without an adapter. The same goes for an opener that takes separate open and close inputs, which Konnected lists as unsupported. It sells for about $89 on Amazon; check the live price.
Build a Shelly garage cover in Home Assistant
A Shelly relay is the cheapest controller here, and the only one where you build the garage door entity yourself, which is exactly why we tested its YAML.
The Shelly 1 Gen4 has potential-free relay contacts, so its O and I terminals can sit across the wall-button wires of the opener the same way a doorbell button would. It runs on 110-240 V AC, 24-48 V DC or 12 V DC, speaks Wi-Fi, Zigbee and Matter, and Home Assistant picks it up through the official Shelly integration as a switch. A 12 V DC plug-in supply keeps mains wiring out of the opener, and if you do wire it to mains, that job belongs to someone qualified. What the Shelly does not give you is door state, and the Shelly page for the 1 Gen4 suggests a sensor input such as the Shelly Plus Add-on for that. A battery Zigbee door contact on our Zigbee coordinator works just as well, and if you run Z-Wave, the Shelly Wave 1 is the same idea on your Z-Wave 800 stick.
Two entities and a template cover tie the pieces together: the relay as switch.garage_door_relay and the contact sensor as binary_sensor.garage_door_contact, where on means the door is open. Rename your entities to those IDs in Home Assistant, or edit them in the file. The wiring order:
- Wire the Shelly’s O and I terminals in parallel with the wall-button terminals on the opener.
- Add the Shelly to Home Assistant through the Shelly integration and rename its switch.
- Mount the contact sensor on the door and rename its binary sensor.
- Drop the template cover below into a package file and run the config check.
Our lab config loads packages from a folder, which keeps the garage door in one file. On a Docker install the config folder is wherever you mounted /config; we used ~/ha/config. Create the packages directory:
mkdir -p ~/ha/config/packagesThen point configuration.yaml at it. Open the file:
vim ~/ha/config/configuration.yamlAdd the packages include under homeassistant. This is the whole file from our lab, so merge it into yours rather than replacing what you have:
homeassistant:
packages: !include_dir_named packagesNow open the package file:
vim ~/ha/config/packages/garage_door.yamlPaste the cover. It pulses the relay for half a second, the way a finger presses the wall button, and the conditions stop an “open” from firing while the door is already open, since a second pulse would reverse the motor:
template:
- cover:
- name: Garage Door
unique_id: garage_door_shelly
device_class: garage
state: "{{ 'open' if is_state('binary_sensor.garage_door_contact', 'on') else 'closed' }}"
open_cover:
- condition: state
entity_id: binary_sensor.garage_door_contact
state: "off"
- action: switch.turn_on
target:
entity_id: switch.garage_door_relay
- delay: "00:00:00.5"
- action: switch.turn_off
target:
entity_id: switch.garage_door_relay
close_cover:
- condition: state
entity_id: binary_sensor.garage_door_contact
state: "on"
- action: switch.turn_on
target:
entity_id: switch.garage_door_relay
- delay: "00:00:00.5"
- action: switch.turn_off
target:
entity_id: switch.garage_door_relay
stop_cover:
- action: switch.turn_on
target:
entity_id: switch.garage_door_relay
- delay: "00:00:00.5"
- action: switch.turn_off
target:
entity_id: switch.garage_door_relayValidate it before restarting. We ran Home Assistant 2026.10.4 in Docker, so the check runs inside the same image. On Home Assistant OS or a Green, open Settings, Tools, YAML and press Check configuration instead:
docker run --rm -v ~/ha/config:/config ghcr.io/home-assistant/home-assistant:stable python -m homeassistant --script check_config --config /configA clean config exits 0 and prints this line, sometimes under a harmless Python SyntaxWarning from a library inside the image:
Testing configuration at /configAfter a restart, we drove the cover through the REST API with the relay and contact simulated by stub entities. Calling cover.open_cover on the closed door pulsed the relay on at 01:17:06.238 and off at 01:17:06.740, almost exactly the 0.5 second delay. Calling it again once the contact reported open returned an empty list, meaning the condition held and the relay never fired. With the door open, the cover carried these attributes:
{"is_closed":false,"current_position":100,"device_class":"garage","friendly_name":"Garage Door","supported_features":11}The device_class: garage is what makes Home Assistant draw a garage icon and lets voice assistants treat the entity as a garage door, and supported_features: 11 is open, close and stop. That stop action is the one gap in this file. Unlike open and close, stop_cover has no condition, and on a single-button opener a pulse while the door is still starts it moving, so a stray “stop” from a dashboard, voice assistant or automation would open a closed door. Delete the stop_cover block if anything other than you can call it; open and close keep working without it.
This build is the wrong choice if you want door state from the opener, or if your opener is Security+ 2.0, because a dry relay cannot drive it reliably. The Shelly 1 Gen4 runs about $28 on Amazon (some third-party listings ask far more, so buy the Shelly-sold one); check the live price.
Pair the Meross MSG150HK through HomeKit
If you would rather not touch YAML or flash firmware, the Meross MSG150HK is the shortest path to a local garage door entity.
The MSG150HK is the Meross model for Chamberlain, LiftMaster and Craftsman openers with a yellow, purple or red learn button: it speaks Security+ 1.0 and 2.0 itself, so Meross says it needs no separate magnetic door sensor. The official HomeKit Device integration in Home Assistant pairs HomeKit accessories directly over your LAN, and its docs list HomeKit garage door openers as a supported cover type. So the MSG150HK becomes a local cover with no Meross account in the path. Pair it while it is not in Apple Home, or remove it from Apple Home first, because a HomeKit accessory accepts only one controller at a time.
A Security+ 3.0 opener locks Meross out entirely, and other brands, plus red-button openers with three terminals, are outside what the MSG150HK supports. For those, Meross points buyers to its universal MSG100HK, which pairs through HomeKit the same way. The Meross-app-only MSG100 sold on Amazon for Alexa and SmartThings has no official local path and leans on the community meross_lan custom integration. The MSG150HK sells for about $70 on Amazon; check the live price.
Run up to three doors from a Tailwind iQ3
Tailwind is the one to watch for a garage with several doors, with one big caveat about which generation Home Assistant documents.
Home Assistant ships an official Tailwind integration that is fully local: it polls the controller every 5 seconds using the device IP and a local control key you generate in the Tailwind web portal. Each door becomes a cover entity, alongside a sensor for operational problems, an identify button and an LED brightness control. The current iQ3 2.0 controls one door, either over a digital link to many modern openers with no door sensor or as a dry contact. The iQ3 2.1 handles up to three doors or a gate, but only in dry-contact mode, so a house with three Security+ 2.0 openers still needs one controller per door.
Hold off if you need documented support on day one. The Home Assistant docs name only the original “Tailwind iQ3”, the first-generation unit is no longer sold, and the docs do not yet say whether the second-generation 2.0 and 2.1 work with the same integration. Both are sold direct, not on Amazon: about $90 for the 2.0 without a sensor and $115 with one, and about $100 to $125 for the 2.1, which was listed as a pre-order when we checked; check the live price on the Tailwind store.
Match the controller to your garage
Once you know the protocol, a few setup details decide which pick is less work for you. These are the checks to make on any candidate:
- Read the learn-button color and rule out anything that can’t speak it.
- Decide where door state comes from: the opener’s bus, a laser, or a sensor on the door.
- Check the Home Assistant integration is official and local, not a cloud bridge.
- Confirm 2.4 GHz Wi-Fi reaches the garage, or pick a Zigbee or Z-Wave path.
- Plan power: USB-C, a 12 V adapter, or mains for a Shelly.
Wi-Fi coverage is the one people skip. A garage is often the far end of the house behind a block wall, and an ESPHome device that keeps dropping off shows up as an unavailable cover right when you want to close the door. Test the signal with a phone in the garage before you mount anything. Also keep an eye on Matter: Matter 1.5 added a closures category that covers garage doors. Home Assistant’s Matter integration doesn’t handle that category yet, but once it does, controllers get a standard local path in without a vendor integration. If Home Assistant still needs a host, our mini PC picks for Home Assistant cover the hardware, and the Docker install guide matches the container setup we used for the config check.
Read the config check errors on a template cover
Most broken garage covers come from YAML copied out of older forum posts, because the template cover syntax changed and two of the old habits now fail the check. We broke our working file on purpose to capture what Home Assistant prints.
Error: “expected CoverDeviceClass or one of … got ‘garage_door'”
This one comes from giving the cover the binary sensor’s device class. garage_door is right for the contact sensor and wrong for the cover, which wants garage:
ERROR:homeassistant.config:Invalid config for 'template' at packages/garage_door.yaml, line 5: expected CoverDeviceClass or one of 'awning', 'blind', 'curtain', 'damper', 'door', 'garage', 'gate', 'shade', 'shutter', 'window' for dictionary value 'cover->0->device_class', got 'garage_door'Change the cover’s line to device_class: garage and leave the sensor alone.
Error: “‘value_template’ is an invalid option for ‘template'”
Under the current template: to cover: format, the state template key is state. Older examples used value_template, and the check rejects it with the line number:
ERROR:homeassistant.config:Invalid config for 'template' at packages/garage_door.yaml, line 6: 'value_template' is an invalid option for 'template', check: cover->0->value_templateRename the key to state and rerun the check. One legacy mistake slips through, though. A whole block in the old cover: with platform: template form passed with exit 0 in our run, even though the template docs say that format isn’t supported anymore and Home Assistant raises a repair at runtime. If your cover simply never appears after a restart, look in Settings, System, Repairs before you blame the relay.
