Automating Garage Door to Replace MyQ - Taking the Garage Door Cloudless

Okay here is how I automated my garage door and made my own ‘MyQ’ system in the wake of MyQ blocking all 3rd party apps. FWIW I have a Liftmaster 8500W but this should work on any model.

Background - What I tried first: The garage door can be activated by wireless remote or via Smart Control Panel. The wireless remotes use rolling codes and I could not find a way to duplicate these with a Broadlink RM3 (or similar). The connection between the Opener and the control panel is digital so you can’t just short the 2 wires that run between them to activate the door. I’ll describe how I got around this below.

Parts: I am linking what I bought below but please check your system for compatibility.

  • Smart Control Panel - I a bought second one for this but you can use your existing one.
  • Shelly Plus 1 - or similar. It needs to have the ability to de-couple the switch wire from the output (see below).
  • Small gauge wire - I used 22GA. Better if you have multiple colors.
  • 12V Power supply - I cut the end off of one that I had from an old modem I wasn’t using
  • Contact Sensor - We will use this to detect if the garage door is open or closed.
  • Soldering iron and Solder. Just a basic one will do.

The Design Concept:
To get around the Smart Control Panel signals being digital, I soldered 2 wires on either side of the button that you press to activate the garage door on the Control Panel. Note that there are 2 buttons on the circuit board that correspond with the large grey button you see from the outside. You can solder to either of these buttons. Also note that each button has 4 terminals. Use a multimeter to determine which ones to use. I found that either diagonal set would work. These wires go to the Shelly Plus 1 “I” “O” terminals (the relay output terminals). When the Shelly output is activated, it will short the Control Panel button, simulating a press, and will activate the garage door. We will deal with rules and further config on this below.

After your soldering is done, I would go ahead and wire the Control Panel into your opener. This is a second opener for me and I wired it in just like I did the first one. Please check your manual to confirm yours is the same as mine. I connected mine to the red and white terminals on the left side of the terminal block of the opener as shown below. The green/green-white wires go to Control Panel 1 and the blue/blue-white wires go to Control Panel 2.

Now we can control the garage door but we still need to be able to detect whether it’s open or closed. I attached the contact sensor to the door as shown below. This particular model has NO (normally open) and NC (normally closed) wires. We want to use the NO wires which means it ONLY outputs a signal when the sensor is closed. This will be more reliable than using NC. On my model the NO wires were black and green. I connected one to the SW terminal of the Shelly and the other to the L terminal.

Contact Sensor Installed

Overall Wiring Diagram

By default, the shelly will power the output terminal based on the switch wire. We don’t want this because we are using the switch terminal (the contact sensor) to detect if the garage is open or closed. When you power the Shelly up and add it to wifi, there is a setting in the Shelly app that allows you to decouple these 2.

Go ahead and install the Shelly binding and add Shelly to openHAB. Add the Thing and the Items. The relevant items that I used are the:

  • relay output switch - We need to send a short pulse to this to simulate someone pressing the button to open/close the garage
  • relay input switch - This goes to the contact sensor and detects whether the garage door is open or closed.

My rule for activating the garage door is below:

rule "Shelly Open/Close Garage"
when
    Item MasterGarageDoorActivator received command
then
    ShellyPlus1GarageDoor_RelayOutput.sendCommand(ON)
    Thread::sleep(1000)
    ShellyPlus1GarageDoor_RelayOutput.sendCommand(OFF)
end

You can then use the input switch Item to send notifications when the garage door opens and closes and even display the garage door status on Main UI if desired.

Hope this helps!
JM

PS: Wanted to give credit to this video. Really helped me in getting this done.

1 Like

Here is a picture of the button from the control panel. You can see the 4 terminals mentioned above. Just solder to 2 diagonal terminals.

good catch on the detached switch, totally forgot about this! It beat using another shelly or relays to get the garage door status.

What I’m planning on my end though is having 2 sensor, one at the top of the garage and one at the end. I want to know if it’s open, close or moving. I could even know which way it’s moving. That’s because I have different automation depending on what’s it’s doing (opening, closing, closed, open, etc).

Also, you could use a shelly with multiple output and control the light from the control box too.

Great job!

1 Like

Instead of a rule you could use Expire for this. Though I have a vague memory that maybe Expire cannot handle times below three seconds so maybe not. It’s worth an experiment.

Assuming you do need a rule, there’s a side effect here I’m concerned with. Because of the sleep, if someone spams the MasterGarageDoorActivator, each of those commands will be queued up they will all be worked off in order. Instead, a better behavior would be to ignore those commands unless the ShellyPlus1GarageDoor_RelayOutput has gone back to OFF.

There are a couple of ways you can accomplish this.

  1. Use the Debounce rule template on MasterGarageDoorActivator to ensure that it cannot change faster than your one second “button” press
  2. Use a Timer instead of a sleep and skip the rule if the Timer already exists (which is basically a debounce coded into this rule instead of coded into a separate rule like in 1 above)

The second option would look something like this in Rules DSL

var Timer buttonTimer = null

rule "Shelly Open/Close Garage"
when
    Item MasterGarageDoorActivator received command
then
    if(buttonTimer !== null) {
        return;
    }

    ShellyPlus1GarageDoor_RelayOutput.sendCommand(ON)
    buttonTimer = createTimer(now.plusSeconds(1), [ |
        ShellyPlus1GarageDoor_RelayOutput.sendCommand(OFF)
        buttonTimer = null
    ])
end

In Blockly it would look like (I’m just showing the script action):

In JS Scripting (again just showing the script action):

var timer = cache.private.get('timer');
if(timer === null || (!timer.isActive() && !timer.isRunning())) {
  items.ShellyPlus1GarageDoorActivator_RelayOutput.sendCommand('ON');
  cache.private.put(actions.ScriptExecution.createTimer('GarageTimer', time.toZDT(1000), () => {
    items.ShellyPlus1GarageDoorActivator_RelayOutput.sendCommand('OFF');
  });
}

jRuby has some very terse ways to do stuff like this but I’m not great with that language.

1 Like

I can also recommend fibgerbot devices, if you have to press an old school button and cannot make the button smart in other ways. That’s available in wifi and zigbee version as far as I know and does not require any soldering knowledge.

Yeah I know about some of these device. One thing I don’t like is they are battery powered and not very reliable. They often doesn’t mount properly and fell on the floor. I saw many reviews on these and while it’s working, it’s not perfect. But yes, it’s better then soldering.

The soldering can also be prevented but this require even more knowledge. Honestly if you’re into home automation with stuff like openhab or other diy, you shouldn’t be too afraid to solder on a small button.

Thanks for posting this. In the above rule is buttonTimer an item or a variable?

It’s a variable defined at the top of the file.

var Timer buttonTimer = null

Sorry I’m blind.

Question for you: Lets say that the rule is activated. Practically as soon as that happens, buttonTimer gets changed to a timer value (which is not ‘null’).

Now 0.5 seconds later, the rule gets activated again. Are you saying that the 2nd rule activation finds buttonTimer as the timer value rather than ‘null’?

In other words, variables in a rule get carried between simultaneous activations?

If they are declared outside the rule yes, the value carries between runs of the rule. You’ll notice I use the cache in the other examples above (the Blockly example also uses cache under the blocks). There’s is no “outside the rule” when creating rules in the UI so you have to use the cache.

I’ll also point out that there is no such thing as “simultaneous activations”. Only one instance of a rule can run at a time. If the rule is running when it’s triggered for a second time, that second trigger waits for the first one to exit before it runs.

That’s what sets up the problem with using sleep. If it gets spammed with 10 triggers over that one second, for the next ten seconds the door is going to go up for a second, stop for a second, go down for a second, and do on until all the queued triggers are worked off.

By using a timer you can ignore any trigger that occurs while the button is “pressed”, preventing that queue from building up. Once the button is"released" the rule will be able to immediately react to the event instead of waiting in an ever growing queue.

The situation you want to avoid is you need to stop the opener in an emergency and be unable to because you spammed the button because it didn’t stop on that first command, for example.

1 Like

Sorry if I’m missing something obvious but I copied your rule into my home.rules file and it gave me an error for declaring a variable outside of a rule. Do I need to import something?

You have to follow the syntax for a .rules file.

A rule file is a text file with the following structure:

  • Imports
  • Variable Declarations
  • Rules

    The Variable Declarations section can be used to declare variables that should be accessible to all rules in this file. You can declare variables with or without initial values and modifiable or read-only.

You can’t just place the “global” variables anywhere. They have to go after the Imports but before the first rule.

1 Like

Did you check how much power is sent to the external panel? I wondered if we could use that to power the shelly instead

I didn’t check but my understanding is that those 2 wires both power the external panel and transmit signals between the opener and the panel. I’m not smart enough to know whether that prohibits them from also being used to power something else.

Might want to confirm the above though.

My Chamberlain Opener has a 12V battery backup. I suppose I could run some wires from the battery terminals inside the opener to power the shelly relay?

I did think about this too. I have a battery backup also inside. I think it could work.

Edit: better would be to find the power merger where Ac and battery are met. This way, you power from Ac when it’s on and from battery when power goes out.

1 Like

Cleanest way is direct to the battery since the opener has a battery charging circuit with float to keep battery topped off already you are effectively running on A/C when it is present. And you avoid having to go too deep inside your opener. some f2 style piggyback connectors (avail on line and at most automotive stores) on the battery terminals would make it even easier.

I guess I wanted to keep it simple. The opener has to plug into the wall so I just plugged the shelly in there. If the power goes out, my openHAB VM shuts down and automation goes bye bye anyway.

Just found out about ratgdo and rat-ratgdo that connect to the brain and can give and control everything.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.