I’m looking to install a brand-new garage door opener where there currently is none. No motor, no track, no controller, just an old-fashioned manually opened door.
Obviously I want something which works with HA. This is for the back of a building that’s far from the house. WiFi there is poor at best. I could run Ethernet cable there easily, but there’s already great Zigbee coverage.
I recognize that the “smarts” is in the open/close switch, not the mechanical stuff. Still, since I’m starting out with nothing I can chose the hardware which best interfaces with whatever controller would integrate efficiently with HA, hopefully using Zigbee instead of WiFi.
I have Hormann garage and gates. I have just disasemble the remotes and control them from RPI. Working without problem for over a year.
I would think that any in device solution would be proprietary(their cloud) or expensive.
I use the MYQ Liftmaster 3800 jack shaft opener. Best opener I have ever had but they are expensive. With nylon rollers it is very quiet and smooth opening. It operates with wifi. I also have a z-wave minimote for the other door that is very reliable. Sorry I have no experience with zigbee openers.
Have you considered a long range access point and a shelly 1 to act as the momentary switch. There is a wiring diagram here.
I don’t have any issues with wifi in my garage but I did have an issue with the MyQ remote cloud server always taking a dump so killing remote access to my door thru HA.
How I solved it was to use a modified sonoff basic to act as a dry contact relay (you could now use something like a shelly that already has that capability built-in but at the time I didn’t so I pulled out the Dremel and the soldering iron and made it work ).
And then modify a garage door opener remote control to put the dry contacts in parallel to the remote pushbutton switch contacts.
then when the sonoff/shelly is activated it’s just like pushing the remote control button.
That also could solve your problem of no wifi in your GD location. as long as the remote RF signal can reach the GD controller then you can put the sonoff/shelly/remote anywhere you want it.
It also solves the issue of trying to find a security enabled zigbee/zwave/wifi garage door controller that can integrate to the main garage door controller. The remote will already have the security features built into it.
What I think I’m hearing is that it doesn’t matter what door opener equipment I buy. The solution for local control via HA is to simply wire a Zigbee (or whatever) switch to the push button circuit.
For the record, this door is in an outbuilding. It doesn’t matter how loud it is, or whether or not it has good security. I just wanted to be able to control it from HA, for example if I’d forgotten to close it while I was out there.
Good point. I know they also sell garage door sensors, I haven’t played with them but I was thinking of using one on my mailbox. I assumed those just sensed the orientation of the sensors. At any rate, more opportunities to play with new stuff!!
Just to reinforce that idea, it’s what I did over a decade ago with a Sears garage-door opener (rebranded Chamberlain).
I ran a two-conductor cable from the wall-mounted garage-door button to a relay in my security system (apprx. 15m/50ft of wire). Closing the relay contacts momentarily simulates pushing the garage door button. My home automation system (Premise Home Control) sends commands to the security panel, via ethernet, to control the relay (on for 1 second then off).
When I migrated to Home Assistant, rather than re-engineer the whole thing, I simply have Home Assistant control the relay via MQTT through Premise:
HA -> MQTT -> Premise -> Security Panel Relay -> Garage Door Button
Whenever I have nothing better to do (hah!) I’ll distill it down to this:
HA -> Security Panel Relay -> Garage Door Button
FWIW, a large magnetic contact sensor is mounted on the garage door and hard-wired to the security panel. It serves to detect the door’s status (open/closed) and reports it to Premise (which reports it to Home Assistant via MQTT).
Would you mind sharing a link to the Premise software (I’m assuming it’s software) you’re referring to? I’m curious to learn what it does but searching for such a generic term anywhere leads one astray.
I think @123 is referring to a system that is no longer available or current. I have seen him refer to it before. Sounds good, but no longer available. So good that he still manages to leverage it!
I can share several links but, unfortunately, none will point directly to a recent web-site because the product was discontinued many years ago.
In May 2000, Premise Systems (about a half-dozen former Microsoft employees and professional systems integrators) announced the release of a beta version (Internet archive link) of Premise Home Control. Long story short, over the next 6 years there were two releases of the product and the company was sold to LANtronix and then to Motorola who ultimately discontinued it. The final version was released to the public for free (but remained closed-source). Despite only two releases, its architectural design remains impressive two decades later (even when compared to existing commercial and open-source solutions).
I created a summary of Premise and it’s posted on Cocoontech. It contains several screenshots of Premise Builder which is what is used to manage the entire product. I was actively involved in the user-community for many years.
The software has been available from Cocoontech but I recently noticed it says the download is broken. If that’s true and someone really, really wants to explore this forgotten gem, then I can point them to a different source. Please be aware that it runs exclusively on Windows.
If you’re interested, the following points contain links to Premise-related posts I have made in the past (in Home Assistant’s community forum):
Everything is object-oriented in Premise. You can easily create new classes of devices by inheriting/extending existing classes (i.e. imagine you were able to define custom domains in Home Assistant).
Premise’s objects (a.k.a entities) can be organized hierarchically (i.e. nested areas) and each one has a mandatory type (sort of like a super-charged version of device_class).
Premise’s sysevent object can tell you more about the trigger’s source than Home Assistant’s trigger object.
Premise supports the concept of a momentary boolean, where it can only maintain true for a brief moment to serve as a pulse.
Its drivers (integrations) can be installed/uninstalled/upgraded independently of the core Premise software and without restarting it or explicitly reloading anything. Here’s a description of the UPB driver whose C++ source-code (one of the rare exceptions for this closed-source product) was offered as a reference for the creation of Home Assistant’s excellent UPB driver.
Its scripting language is an enhanced version of VBScript. It isn’t just for creating automations but can also be used to create the equivalent of integrations. This is a tremendous advantage because it permits immediate, interactive development (within Premise’s UI) as opposed to the compile/install/test cycle for C++ driver development. Over the years I created several in VBScript including one for Text-To-Speech and just one in C++ (pointers to lists of pointers, oh my!).
FWIW, I discovered Premise in mid 2007 and continue to use it today. It has a few integrations that either don’t exist in Home Assistant or I simply prefer the Premise version. Three years ago, I added MQTT functionality to Premise (akin to a bi-directional version of Home Assistant’s MQTT Statestream integration) and it provides seamless interoperability with Node-Red and Home Assistant.
Thank you for the comprehensive answer! I also read your linked write-up. It seems like quite a system and advanced, especially for something that was developed 20+ years ago. I like reading up on these things, since one can learn from what was done and build a better next generation product.
(Thanks everyone for bearing with me going slightly off topic.)
I am also using my security panel and a connected relay module as an intermediary between HA and the door opener. The additional advantage is that I programmed the security system keyfob to toggle the doors, the keyfobs are in “high security” bidirectional encrypted handshake mode, which makes them far more secure than a regular remote opener.
HA is also programmed to use the alarm state as a condition as not to open the door until after the system is disarmed… so as to not accidentally set off the alarm. I also have 2 sensors on each door, one that measures if it is fully closed, and an inverted one that measures if it is fully opened. Both sensor states must be the same before HA is allowed to toggle the relays, since a mismatched state can indicate the door is moving.
As for the door hardware, its a standard chamberlain chain drive
).