I am running the 1.2.1 fork that you linked to. Here is a screenshot of my OG settings page. Not sure what is at 172.30.32.1, maybe it’s an internal home assistant thing, i don’t use those addresses in my setup? Also, i don’t have a single word about mqtt in my config.yaml, and i don’t have anything else mqtt in my setup, just trying to get it sorted. The mqtt username is one i made for mqtt in homeassistant>config>users
OK. then try defining the cover and sensor in configuration.yaml - that should get the message subscription going - and add the entities to groups. Restart, and then hopefully it is working.
This excellent discussion has recently focused on OpenGarage, which is a great solution. I want to offer an update from the DIY perspective of things, with an emphasis on security.
Last weekend I decided I want to encrypt all IoT network traffic on my main LAN. So my goals:
- All 3rd party devices (e.g. Arlo) are isolated to a VLAN.
- All of my DIY devices need to use encryption.
I know, hot-take regarding zero trust in your home, but it’s been an interesting process and I’ve learned a lot.
One glaring gap is lack of TLS support from my ESPHome enabled ESP12s device. For example, after enabling TLS on my Mosquitto MQTT instance, I was only left with HA http integration; hence no options to encrypt local traffic.
Until ESPHome can manage to get some reasonable cert auth on these devices (ESP32?) my ESP devices are relegated to sensor readings only i.e. no ability to open my garage door.
I decided to go with an XBee ZigBee module on an Arduino compatible Fribee controller. I enabled encryption on my ZigBee mesh network satisfying goal #2. I wrote a minimal ZigBee controller in Python to accept commands via TLS enabled MQTT.
I now have an encrypted communication method via HA to open/close my not-MyQ garage door. Here’s a photo of my ugly implementation Velcro’d to my garage opener 
1 Like
Finally was able to free my Craftsman 3043 from the yoke of MyQ using a Shelly1 relay.
Followed two different how-tos, one being from The Hookup, the other from Smart Home Makers, except that both assume that mimicking the open/close button is a simple matter of using the Shelly1’s “I” and “O” leads to jump the two wires, which doesn’t work on Chamberlin based openers with the “Smart Panel”.
The solution was a second set of wires run between the panel and the opener, with the wires soldered onto the circuit board to tell the board “hey i pressed the open/close button”, which in turn tells the opener to do its thing.
I used the reed switch so the Shelly app shows status (this is shown in The Hookup video), I have a SmartThings v5 Multipurpose sensor in garage door mode, and I used the YAML from Smart Home Makers post linked above to create the cover entity in Home Assistant. This all works great and it was a fantastic feeling to pull the MyQ gateway off my network and banish it to a bin in a storage cabinet.
Here is a diagram putting it all together.
- The orange/white pair is for the existing opener <–> smart panel connection and operation.
- The blue/white pair is to let the Shelly mimic pushing the physical button on the panel
- The SmartThings sensor is used by Home Assistant to determine if the door is open or shut and used as part of YAML to create the cover
- The reed switch is to tell the Shelly app if the door is open or shut. This only means anything to the Shelly app to indicate open or shut.
Your YAML may vary, but I used the open and close actions to call an MQTT that Node-Red handles (as I turn on/off lights based on time of day as well as opening/closing the door). I also check “if opened was requested, then make sure the door isn’t already opened (checking the current state of the SmartThings sensor)” as well as “don’t close if already closed”
- platform: template
covers:
garage_door:
device_class: garage
friendly_name: "Garage Door (Shelly)"
open_cover:
service: mqtt.publish
data:
topic: "commands/garage"
payload: '{ "open": true }'
close_cover:
service: mqtt.publish
data:
topic: "commands/garage"
payload: '{ "close": true }'
stop_cover:
service: switch.turn_on
data:
entity_id: switch.garage_door_button_shelly1
value_template: >-
{% if is_state('binary_sensor.garage_door_tilt_contact','on') %}
open
{% else %}
closed
{% endif %}
icon_template: >-
{% if is_state('binary_sensor.garage_door_tilt_contact','on') %}
mdi:garage-open
{% else %}
mdi:garage
{% endif %}
2 Likes
(I’m sure @qoheleth you knew this already) so just to clarify for future readers coming to this thread: With the solution that @joelp mentioned above, you wouldn’t need any battery.
OpenGarage is selling this, a hacked and wired version to handle Security+ 2.0 situation:
Other guys are selling something similar:
Or as @joelp mentioned above, you could get a ~$10 883LM button off Amazon or eBay or your garage door installer, and go DIY route.
Yes. As I mention (a long way) above, that solution involves soldering directly to the door opener panel button. Those panels are more expensive than the remotes.
However, I’d not seen that Garadget item in your post. That doesn’t require soldering (wires already connected) and it’s less expensive than both a remote or a door opener panel. Good find.
Agreed, Garadget is a good find.
Hoping @wnelson could give me a few pointers.
I have my MQTT server setup and as you pointed out in the supervisor-mosquitto-logs i can see my instance of the OpenGarage device is connected. Just wanted to also point out that I am on firmware v1.1.1, which does not allow me to input MQTT port, username/password. I ensured that i’ve allowed anonymous login, so hence it doesn’t appear that there are any issues connecting to my MQTT broker.
New client connected from [IP] as mygdo (p2, c1, k15).
Then in my config.yaml file i have this:
cover:
- platform: mqtt
name: "mygdo"
state_topic: "mygdo/OUT/STATE"
command_topic: "mygdo/IN/STATE"
retain: false
payload_open: "on"
payload_close: "on"
payload_stop: "on"
state_open: "open"
state_closed: "closed"
device_class: "garage"
However, with all this … cover.mygdo shows as “unknown”.
I’m a complete newb with MQTT so maybe there is still something not configured properly?
in the opengarage device interface, what is the Device Name?
Also, consider updating the firmware to the forked version described above.
The name matches the one in the topics parameter… ‘mygdo’
I just updated the firmware to 1.2.1 and have added a mqtt username and password to the OG web interface. Also made sure the same credentials exist in the HA >> config >> users page
Apparently not recommended for Australia. AFAIK the MyQ Home Bridge is a US market product, and the frequencies for that class of device differ between USA and Australia.
No mention of the Nfarina Homebridge, a HomeKit emulator?
It’s funny I just shared this Athom option in another thread:
1 Like
I have an extra remote for my GDO. It was easy to open the case and I see that it contains a 3v battery and a removable circuit board. It seems easy enough to wire the 3v into the 3v pin of an ESP and use a relay to mimic the push button(s) of the remote by tapping into the back side of the circuit board. I probably won’t disturb the solder points; I’ll just use metal contacts against the solder points (and the battery bay) and use some thin wires from an old cat5, which look like they’ll fit within a small gap already built into the right-hand side of the remote’s case. So, I can close the whole thing back up and have four wires coming out the right side. …run those wires to an ESP for power, and the other two to a relay (assign to it a .5s toggle automation), and it should work. I haven’t done this yet. If anyone believes it won’t work, feel free to chime in.
Edit: The 3v pin didn’t seem to work. It could have been an error on my part. But I successfully ran two leads out the side of the case to mimic a button press when there’s momentary contact (running off of the 3v battery). I’m happy with the outcome. I’ll set up a relay and an ESPHome config and should be all set.
I reverse engineered the serial encryption and designed a shield for interfacing an ESP8266 with Security + 2.0 doors. This provides you with dry contacts (if you want to use buttons or relays to control the door, or sense when its open/obstructed) as well as a cloudless MQTT interface.
3 Likes
I like this idea, this is better than my approach, I used an extra programed remote connected to an ESP to open and shut ‘locally’ but I don’t have the open/shut feedback locally.
Pictures would be nice in your instructions on the GitHub IO page, especially the soldering areas.
I notice you misspelled shield on the first page at the bottom.
For $30, that is a good price to just buy it and not have to track down the parts myself.
Is August still you expected ship date?
Edit There is no diagram for step 10 of the solder method.
@GlennHA I just finished authoring the diagrams for connecting the shield to the door opener. Also corrected the spelling mistake 
And yeah, August is still the expected ship date. With luck I’ll have the first round of boards ready for shipping out the first week of August.