Garage door closing rule?? for Elk

[wbonnell]

I am trying to write a rule to close the garage door and then keep trying to close the door up to 3 times if something causes the door to not close properly. Output 19 is wired to the contacts on the opener and output 100 is just a virtual output for using as a timer. Does this look like it will work? If I run it from the rules page it will close but if I trip the safety beam on the door it goes back up and doesn't try to close again. there must be something wrong in my thinking!!



14
WHENEVER close barn door (Task 3) IS ACTIVATED
AND SW Overhead (Zn 108) IS NOT SECURE
AND bill (Counter 1) IS LESS THAN 3
THEN TURN small ohd barn (Out 19) ON FOR 1 SEC
THEN TURN Output 100 ON FOR 30 SECS
THEN ADD 1 TO bill (Counter 1)
THEN ACTIVATE close barn door (Task 3)



15
WHENEVER SW Overhead (Zn 108) BECOMES SECURE
THEN SET bill (Counter 1) TO 0

 

[Steve]

First, I just have to say imho it is not a good idea to automate the door to keep closing. That being said, I think your problem is in use of the timer. Turning on an Output for x seconds does not actually pause things. So, you need to put a separate rule looking for the output turning off. The way you have it, it just runs through Task 3 three times consecutively with no pausing. I think this may work better:

WHENEVER close barn door (Task 3) IS ACTIVATED
AND SW Overhead (Zn 108) IS NOT SECURE
AND bill (Counter 1) IS LESS THAN 3
THEN TURN small ohd barn (Out 19) ON FOR 1 SEC
THEN TURN Output 100 ON FOR 30 SECS
THEN ADD 1 TO bill (Counter 1)

WHENEVER SW Overhead (Zn 108) BECOMES SECURE
THEN SET bill (Counter 1) TO 0

WHENEVER OUTPUT 100 TURNS OFF
THEN ACTIVATE close barn door (Task 3)

 

[fcwilt]

Well for one thing if the door never closes then the counter will keep incrementing until it hits 4 and then nothing will happen when you activate the task. So that needs to be fixed. Second turning on an output for a period of time doesn't stop the rule from executing. On my system, at least, it goes right on to the next step.

You might try something like:

WHENEVER EVERY 1 SECONDS
AND CountSecondsCounter IS GREATER THAN 0
THEN SUBTRACT 1 FROM CountSecondsCounter

WHENEVER CountSecondsCounter CHANGES TO 0
AND TryAgainCounter IS GREATER THEN 0
THEN SET CountSecondsCounter TO 30
THEN SUBTRACT 1 FROM TryAgainCounter

WHENEVER TryAgainCounter CHANGES TO A VALUE GREATER THAN 0
THEN TURN CloseDoorOutput ON FOR 1 SEC

WHENEVER DoorIsClosedZone BECOMES SECURE
THEN SET CountSecondsCounter TO 0
THEN SET TryAgainCounter TO 0

WHENEVER CloseDoorTask IS ACTIVATED
AND DoorIsClosedZone IS NOT SECURE
THEN SET CountSecondsCounter TO 30
THEN SET TryAgainCounter TO 3

 

[dBeau]

Not all openers act the same. I have two different models both, like most, have the problem that your only input is a single button press. Where they are in their cycle determines what they will do when the button is pressed. It would be a whole lot easier if the opener had one set of contacts to indicate a desire to close the door and another to indicate the desire to open it. Sometimes they change direction, sometimes they stop. By picking 3 as a number of times to "try", what you are really doing is saying that you will push the button up to three times to get the door where you want it. Where it will end up depends a lot on where it is when you start.

I decided that I didnt really want the door to move unless I was there to watch it (mostly). The one concession I made to that is what I'll call the "single attempt". That is, while unattended I'll allow the button to be pressed at most one time. If I want the door to go up and it's already up, there is no need to press the button. Likewise for down. I have a sensor at each end of travel that I use to determine the current state. The logic I use is like saying "if the door is not where I want it, press the button". This will almost always do the right thing... unless something goes wrong. If something goes wrong, I want to know about it. For this, I just send an email to my phone every 15 minutes if the door is not closed.

This logic works well with what people expect of a garage door. Imagine coming home with the car at the same time an automation rule tried to close the door. You'll hit the button in the car to open it, but the fancy rule will hit it again to close it... With the set up I described, the button in the car will simply stop or change the direction of the door, no different than if the initial motion was caused by the button in the car. The same goes for pushing the button on the wall.

It would be great fun to design the perfect garage door algorithm. It's certainly possible. However, if you are going to limit yourself to 1 or 2 sensors and elk rules it could prove to be quite a challenge.

 

[jaysonc]

When I implemented my garage door logic, I also foundthe 'single button press' as the only interface to control the motor and issue. Here is how I decided to work around it.

In the end, I installed two sensors. One that trips when the door is completely closed. The second when the door is completely open.

X seconds (the time your door takes to close) after you send a single button press, you can definitively know the door is in one of three states: completely open, completely closed or "has been blocked from closing".

--
Jayson

 

[fcwilt]

It would be great fun to design the perfect garage door algorithm. It's certainly possible. However, if you are going to limit yourself to 1 or 2 sensors and elk rules it could prove to be quite a challenge.

For the reasons you stated I used two sensors (open and closed) and a ELK MagicModule programmed to give a me a "smart" door controller. So now I have a garage door controller with distinct open and close requests, automatic retry, status reporting and the knowledge of "manual" requests (requests not issued by the home automation system). As a result my home automation controller doesn't have to worry about the details.

 

[dBeau]

X seconds (the time your door takes to close) after you send a single button press, you can definitively know the door is in one of three states: completely open, completely closed or "has been blocked from closing".

If you allow control from outside the system there are a couple more states. X seconds in, the door could be still moving in the direction opposite to what was desired due to a button press or two from an approaching car or the wall switch. One of my doors behaves different depending on whether it was stopped while going down or going up. So for me at least, that makes a couple more states. Of course if you dont allow external control it's not a big deal. Dealing with it, otoh, could be lot of fun.

In addition to the stoppped at the top and stopped at the bottom sensors, I added external homelink receivers for input. So rather than use the receiver in the opener, I send the external request in via the elk and treat it as a "toggle" request. This lets me ignore the approaching car unless the door is in a known state. ...well that was the theory. Ignoring the press from the car while the door was moving just didnt feel right. For safety reasons, I didnt think it was a good idea either. The "normal" behavior of stopping or changing direction makes more sense.

A good use of the two sensors would be to track the time the door is neither open nor closed. If it's in that state for longer than X trigger a trouble alarm. But since I always keep the door closed, I just do that when the door is in the "not closed" state for "too long".

I think the real question in these discussions is what to do when the door "has been blocked"?. Does trying again really make sense?
Another point I just started playing with is checking what happens when the elk does a power cycle. For the record, my doors both open then close about 5 seconds later!

 

[sic0048]

Could someone explain how they are capturing the Homelite wireless signals. Is there a plugin module or some device that can be added to an ELK (or a standalone version) to do this. Several people have alluded to the fact they do this, but I haven't paid enough attention in the past to know that device to use. I just got an ELK, so this is of interest to me now.

Thanks,

 

[dBeau]

Could someone explain how they are capturing the Homelite wireless signals. Is there a plugin module or some device that can be added to an ELK (or a standalone version) to do this. Several people have alluded to the fact they do this, but I haven't paid enough attention in the past to know that device to use. I just got an ELK, so this is of interest to me now.

Thanks,

I use a couple of these:

"Chamberlain Universal Radio Control Replacement Kit -- Model 955D"

http://www.homedepot.com/webapp/wcs/stores...=10000003+90401

Just connect the output to a non-alarm zone on the elk.

I'd love to hear about a better solution though. Something like it that that did three or four channels would be great. Either my google skills are lacking or it doesnt exist (with rolling codes and homelink support).