Help me write Garage Door opener programs

[kaplansa]

Hey there. Having trouble with the logic for two seemingly basic programs (or series of programs that talk together).

 

Program #1:

First is an auto-door closer. I have two garage doors and door kits ("Inside" and "Outside"). I want a program(s) that will auto-close either door if it's between sunset and sunrise the following morning. I thought the following logic would work, but I don't think I got it right...

 

If From Sunset To Sunrise (next day)
And Status 'Garage Door-Inside Sensor' is Off

Then Wait 30 seconds
Set 'Garage Door-Inside Relay' On
Wait 30 seconds

 

Suggestions for improving theses programs? Thanks!!

I put the waits in there to give the door enough time to close before re-running the program and putting the doors into endless open/close loop. It's not consistently working though. I have a copy of this program for the Outside garage door too. What would you do differently?

 

Program #2

I want to turn on the kitchen lights and send myself an email every time the garage door is open. This is what I have - the lights part works but I'm just emailing myself endlessly.

 

If Status 'Garage Door-Inside Sensor' of Off
Or Status 'Garage Door-Outside is Off

Then Set Scene 'Kitchen Lighting' Fast On
Send Notification to 'Me'
Wait 30 seconds

 

How to I terminate this program so I get only one email each time the door opens, and then let the program rest until the door is closed (sensor = on) and then subsequently opened again (sensor = off)?

 

Thanks a ton!!

[ergodic]

A couple of things:

 

As I remember it, "tail" waits - that is a wait at the very end of a program body will be ignored by the ISY. Somebody from UDI can verify that.

 

So usually what is happening in cases like yours is that the execution of the program itself is changing something that causes the ISY to then stop the program and re-evaluate the program's conditions all over again. This 'self-interference' leads to partial execution, oddly repeated executions, all sorts of strange and undesired things.

 

Now if there were a simple program flag in the ISY to say "don't recheck my conditions while I'm running" this would be easy. But there isn't. So you have to code it yourself. Break the programs into two: a test/trigger program (P1) and an execution program (P2) that gets called from it.

 

For example:

 

//(Program P1)

If Program P2 is false and
(If Status 'Garage Door-Inside Sensor' is Off 
Or Status 'Garage Door-Outside is Off)
Then Run Program P2 (Then Part)

//(Program P2)

Set Scene 'Kitchen Lighting' Fast On 
Send Notification to 'Me' 
Wait 30 seconds
Run Program P2 (Else Part)

 

The basic idea is that P1 triggers on the status changes, but only when P2 isn't already active. P2 does the work, but can't get interrupted by P1 while it is running ("If Program P2 is false and (...)").

 

The last thing P2 does is set itself false, allowing P1 to trigger again. This also neatly solves the problem of the 'tail wait' not doing anything since it is now no longer the final command.

 

Once you get this basic logic in place I think the rest will come together pretty quickly for you. I think what is happening now is that the program is re-executing over and over, but you don't see the lighting change since it is already on.

 

Lastly, you might also want to use a dawn-to-dusk folder condition to save a little testing if you have several programs that are all only active during that time.

[kaisersoze]

My garage door program is similar to your program 1

 

If
From Sunset to Sunrise (next day)
and Status 'Garage Door Status' is On

Then
Wait 30 minutes
Set 'Garage Door Opener' On
Send Notification to 'Administrator'

 

I have a 30 minute wait built in because what if you drive home after sunset and park your car in the garage? You need time to get out of your car and take your groceries into the house... That's my solution, I'd love to see other program solutions

[oberkc]

kaplansa,

 

I have a couple of questions....

 

do you have your sensor wired in such a way that "off" means "open"?

is your relay configured such that sending it an "on" command will close it?

 

while I agree conceptually with ergodic about the possibility of programs causing conditions to change, I don't see it in your example. I also agree with him on the value (or lack thereof) of the trailing wait statements. You stated that you put them there in order that the programs not be immediately re-evaluated, but I see nothing in your program or input conditions that would force an immediate re-evaluation. (I anticipate a re-evaluation only when your sensor changes state.)

 

I may have missed it, but what is this first program doing or not doing that you believe it should be doing or not doing? You also mentioned programs that "talk together". Is it possible that one of the other programs is talking to this one, changing the input conditions, and causing the phenominon mentioned by errodic? One thing to consider is swapping "status" with "control", depending on what problems you are experiencing.

 

As far as second program, you may also try "control" rather than "status".

[kaplansa]

A couple of things:

//(Program P1)

If Program P2 is false and
(If Status 'Garage Door-Inside Sensor' is Off 
Or Status 'Garage Door-Outside is Off)
Then Run Program P2 (Then Part)

//(Program P2)

Set Scene 'Kitchen Lighting' Fast On 
Send Notification to 'Me' 
Wait 30 seconds
Run Program P2 (Else Part)

 

Thanks ergodic. I ran your program suggestions and actually found a bug/issue. What's happening here is that when P2 executes, after the wait period it immediately turns False. But unless you've closed the garage door seconds after it opened (closed during the wait period in P2), then then P1 will immediately turn True and re-run P2 again...and again... and again... I've hilariously received about 100 emails in the past 60 seconds or so! So that was really my initial problem/question. How to get P2 to run ~only once~.

 

The correct use case minus the logic is: I open the garage door. Trigger program checks that the door is open and runs a lighting program and notifies me. At this point, the whole process should end until I close the door (could be hours later for all it matters), which resets the program(s) such that next time the garage door opens, the cycle starts again. Not before.

 

I'm thinking there might be a P3 in here? Did any of that make sense? I really appreciate you helping me understand the logic here. This is actually quite enjoyable to learn!

[kaplansa]

Here's what I'm thinking - four programs.

 

Program Garage Door Closed

If Status 'Garage Door-Inside Sensor is On
Or Status 'Garage Door-Outside Sensor is On

Then Run Program 'Garage Door Open' (Else Path)

 

Program Garage Door Open

If Status 'Garage Door-Inside Sensor is Off
Or Status 'Garage Door-Outside Sensor is Off

Then - No Conditions - 

 

Program Garage Execution
If - No Conditions - 

Then Send Notification to 'Me'
Set Scene 'Kitchen Lighting' On
Run Program 'Garage Execution" (Else Path)

 

 

Program Garage Door Trigger

If Program 'Garage Door Open' is True
And (Status 'Garage Door-Inside' is Off
Or Status 'Garage Door-Outside' is Off )

Then Run Program 'Garage Door Execution' (Then Path)

 

Obviously I'm still figuring this stuff out. My logic is that if the garage doors are open, the Open Program will be true. The only way to make the Open Program = False would be to actually close the doors (The Garage Closed program). The the Trigger program simply checks to see if the doors are open and haven't been closed. If that's the case, the don't run the trigger program - we only want the trigger to run if we know that the doors have been closed before they've been opened. If that makes sense

 

We'll see how it goes... heh

[ergodic]

Yes, sorry. Didn't notice the "status" instead of "control."

 

Three programs might work: Exit P2 true when it is done, leaving P1 disabled and unable to trigger. Then use another, 3rd program that triggers on the status or control change to run P2 else/false, thereby re-enabling P1.

 

It's hard for me to mentally emulate whether the four-program solution works.

 

You can kind of drive yourself crazy trying to chase these ad-hoc solutions, each one often leading to some other, weird, Copernican cycle of yet another unexpected behavior to be puzzled out and patched around.

 

I did post a while back on a more formal method I use to diagram the logic and then mechanically translate that to ISY programs that do what I want. That post is here if you want to wade through it:

 

http://forum.universal-devices.com/viewtopic.php?t=4650

 

It is unfortunately long, but if nothing else it might help understand how the ISY works.

 

In your case you seem to have just two "states" - or maybe three depending on how you look at it. That would actually be four or six programs using that method.

 

HTH

[Illusion]

The most through garage door programs I have seen:

 

http://forum.universal-devices.com/view ... 1184#21184