So do this: just point opengarage at your MQTT server by going to the OG web app and filling it out. Then go to supervisor-Mosquitto-logs and see if you see a message like:
New client connected from [ip address] as GarageDoor (p2, c1, k15, u’mqtt’).
If you see that, then your MQTT instance can talk to the OpenGarage device. Then it’s a matter of getting the right entries into configuration.yaml and groups.yaml per my post.
thanks man, appreciate it… will give it a go…
this is what i see… not sure why it looks like the user is homeassistant when i setup the user for opengarge as mqqt. Also, that IP isn’t the IP of opengarge, not sure if it is supposed to be the actual IP of the opengarage device.
[09:42:51] INFO: Setup mosquitto configuration [09:42:51] INFO: Found local users inside config [09:42:51] INFO: Initialize Hass.io Add-on services [09:42:51] INFO: Initialize Home Assistant discovery [09:42:51] INFO: Start Mosquitto daemon 1612460571: mosquitto version 1.6.3 starting 1612460571: Config loaded from /etc/mosquitto.conf. 1612460571: Loading plugin: /usr/share/mosquitto/auth-plug.so 1612460571: – *** auth-plug: startup 1612460571: ├── Username/password checking enabled. 1612460571: ├── TLS-PSK checking enabled. 1612460571: └── Extended authentication not enabled. 1612460571: Opening ipv4 listen socket on port 1883. 1612460571: Opening ipv6 listen socket on port 1883. 1612460571: Opening websockets listen socket on port 1884. 1612460571: Opening ipv4 listen socket on port 8883. 1612460571: Opening ipv6 listen socket on port 8883. 1612460571: Opening websockets listen socket on port 8884. 1612460571: Warning: Mosquitto should not be run as root/administrator. 1612460578: New connection from 172.30.32.1 on port 1883. [INFO] found homeassistant on local database 1612460578: New client connected from 172.30.32.1 as 1P3VzCcc1p1YeFfBlmEyRi (p2, c1, k60, u’homeassistant’).
yeah it should be the IP address of opengarage. If it’s not there, then OG is not connecting. What OG firmware are you running, and what have you entered into the MQTT tab?
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:
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 
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.
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 %}
(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:
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.
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.