GDO Light Program - Status / Control?

[Teken]

I have a Liftmaster 3800 GDO which has a remote light. The remote light has started to stay on well past the internal timer limit. The only way to turn off the light is to turn off the breaker which resets the light.

 

I have since installed an old Appliance Linc to turn the remote light on / off so energy is not wasted. The program below is what I crafted but wanted to confirm that it would operate as expected.

 

I would like the remote light to stay on for whatever XX minutes ( Below I selected 3 minutes just for an example for the program ). The program will then wait 3 minutes and kill the power to the remote light.

 

2 seconds later the program will turn the Appliance Linc back on, and stay on.

 

My question is should the (IF) statement use the Status or Control operator? I ask because I want to ensure the program does not run non stop, cycling forever. I only want it to run when the GDO opens, closes, then the program does its portion once the GDO is down and closed.

 

 

 

If

        Status  'IO Linc Garage Door-Sensor' is Off

 

Then

        Wait  3 minutes 

        Set 'Garage Ceiling Light' Off

        Wait  2 seconds

        Set 'Garage Ceiling Light' On

 

Else

   - No Actions - (To add one, press 'Action')

 

 

Teken . . .

[Xathros]

Hi Teken-

 

In this instance, I don't believe it matters.  Either control or status will achieve the same result.  Only difference is that when using Status, the program will trigger on both door open and close.  On open, it will run the empty Else clause and have no effect.  On close it will run Then and do what you want.  With Control, it should only trigger on the door closing.

 

If you get some sensor bounce when the door is moving near the sensor, control might cause a false "Closed" trigger when opening the door while status would correct itself once the door moves away from the sensor.  I would stick with Status in this case.

 

Hope this helps.

 

-Xathros

[Teken]

Hi Teken-

 

In this instance, I don't believe it matters.  Either control or status will achieve the same result.  Only difference is that when using Status, the program will trigger on both door open and close.  On open, it will run the empty Else clause and have no effect.  On close it will run Then and do what you want.  With Control, it should only trigger on the door closing.

 

If you get some sensor bounce when the door is moving near the sensor, control might cause a false "Closed" trigger when opening the door while status would correct itself once the door moves away from the sensor.  I would stick with Status in this case.

 

Hope this helps.

 

-Xathros

 

Hello Xathros,

 

As always you're correct!

 

I just had the chance to test the program just moment ago. I intended to test it last night but it was very late and the mosquitoes were simply insane! The program appears to be working just fine right now using the *Status* clause. I increased the time for the Appliance Linc to wait 5 seconds for a buffer.

[oberkc]

^{With a certain level of anxiety about offering advice different from xathros, I must admit that I would have offered a little different opinion.  I think "control" is the better solution here.  My concern with the use of "status" is what happens when the sensor status changes to OFF during the wait period?  Would not the program halt, and the power of the ceiling light not cycle?  Would this be a problem?}

[Teken]

Let me explain my scenario and if anyone sees a problem. I am more than happy to change if so it works correctly for the intended purpose.

 

The GDO light has a built in timer which seems to be broken.

 

My program waits for the door to close and leaves the light on for 3 minutes which seems to be a good balance of it being interrupted by the internal GDO timer.

 

Once the three minutes elapses the APL turns off and waits 5 seconds and than restores power to the remote GDO light.

 

All of this hinges on the GDO door sensor being in the closed position. Which must be closed for the program to execute.

 

Based on the above, does there still seem to be a problem?

 

 

Encrypted By: Phoenix Security Solutions

[larryllix]

@oberkc (since there doesn't seem to be any way to quote somebody for clarity and _{that was very small of you}  )

 

The way  I understand it is that "status" only triggers on the change of the device's status  and  "condition" triggers from the initiating signal stream to/from the device and the device does not need to change status position.

 

 

'Control' is based on signal stream.

Triggers every time the 'On' signal to the ISY device's status is received from elsewhere. ie. monitors the data stream inside the ISY. The status does NOT have to change.

If
        Control 'Gathering Room / Remote.C' is switched On
Then
        Set 'Foyer / Doorbell.Back' On

'Status' is based on ISY's internal device status.

Triggers each time the status of the ISY internal image value of the device changes to 'Not Off'.  Since the 'On' status is not available for this Mini-Remote  'On', 'Dim', 'Brighten', or 'Fast ON'  from Remote.C will trigger it **IF** it doesn't result in the internal ISY's device status as 'Off'.

If
        Status  'Gathering Room / Remote.C' is not Off
 Then
        Set 'F
 Set 'Foyer / Doorbell.Back' On

Yes I would have used the control also. A contact bounce could cancel the timer but then the remake of the contact should reinitiate the timers again. Interesting one...

 

 

The garage light stays on during the whole  open or ajar period. You may want a long timer for the garage door open period in case of a forgotten closing or door jam reversal.

[Xathros]

^{With a certain level of anxiety about offering advice different from xathros, I must admit that I would have offered a little different opinion.  I think "control" is the better solution here.  My concern with the use of "status" is what happens when the sensor status changes to OFF during the wait period?  Would not the program halt, and the power of the ceiling light not cycle?  Would this be a problem?}

As seen above, Quote seems to work.  At least on my Mac using Firefox.

 

@oberkc, don't worry about second guessing me.  I often miss things and you have offed much good advice here as well.

 

As I stated in my first reply, either status or control SHOULD work in this scenario assuming the perfect operation of the door sensor.  The only reason I suggested using status over control was due to the possibility of a sensor bounce occurring during the opening of the door causing a false close control message and starting the countdown while the door is open.  Since only Control Off would trigger the program, the sensor stabilizing in the On position would not abort the countdown and the light would be turned off while the door is open. Status in this case would correctly abort the run when the sensor finally stayed on the open position.  I have had to deal with sensor bounce on one of my garage doors and have helped a few others here with similar issues so it is a known possibility. 

 

In this particular case, I don't see an issue with status failing to accomplish the stated goal as any sensor bounce would only be a very momentary issue filtered by the waits and in the end the status will be correct for open or closed door positions.

 

-Xathros

[Teken]

Hello All,

 

I have cycled the GDO for 10 plus cycles and all seems fine. I will monitor this program and the GDO for the next few weeks and play back the security recordings as time allows. 

 

Much thanks to you all for the insight and confirmation.

[oberkc]

The way  I understand it is that "status" only triggers on the change of the device's status  and  "condition" triggers from the initiating signal stream to/from the device and the device does not need to change status position.

 

I am not sure that I understand the expression "signal stream", but  this sound correct to me.

 

My program waits for the door to close and leaves the light on for 3 minutes which seems to be a good balance of it being interrupted by the internal GDO timer.

 

What do you want to happen if the door closes (sensor OFF), then opens back in less than three minutes?  Do you want the program timer to continue or be halted?  I think that is the crux of the issue.  Do you want the light to stay in indefinitely when the door is open? 

 

If you want the timer to be halted, use STATUS.  If you want the timer to continue, use CONTROL.

 

_{that was very small of you} 

 

 I have no idea why this is/was happening, but the font sizes seem to change when I put them in quotes and at other times.  I was too lazy to go back and manually change the font size back to the original.

 

As I stated in my first reply, either status or control SHOULD work in this scenario assuming the perfect operation of the door sensor.  The only reason I suggested using status over control was due to the possibility of a sensor bounce occurring during the opening of the door causing a false close control message and starting the countdown while the door is open. 

 

I must admit that sensor bounce is not something with which I deal.  I agree that either should work in most cases, but I still suspect there will be different behavior between status and control if the door goes from closed (off) to open (on) while the program is executing the wait statement. 

[Xathros]

I must admit that sensor bounce is not something with which I deal.  I agree that either should work in most cases, but I still suspect there will be different behavior between status and control if the door goes from closed (off) to open (on) while the program is executing the wait statement. 

 

You are correct.  If we were to use Control in this case, there would be an issue with the reopening of the door during an existing countdown delay.  The use of Status in this case will take care of that scenario by aborting the countdown if the door reopens during the delay. 

 

Now just to be compete here, we could use Control as long as we look for both On and Off events as follows:

If
   Control 'Door Sensor' is Switched Off
   and Control 'Door Sensor' is not Switched On

Then
    Delay...

Else 
   Nothing...

But Status is easier in this case.

 

 

-Xathros

[Teken]

 

 

What do you want to happen if the door closes (sensor OFF), then opens back in less than three minutes?  Do you want the program timer to continue or be halted?  I think that is the crux of the issue.  Do you want the light to stay in indefinitely when the door is open? 

 

If you want the timer to be halted, use STATUS.  If you want the timer to continue, use CONTROL.

 

 

 

 

I would simply like the program to be halted. Keeping in mind regardless of what I do the remote GDO light will come on until it is turned off by itself.. Which seems to be quite random now, it appears to work by itself 50% of the time.

 

Its the other 50% of the time that I am trying to take care of. I am unsure what kind of un efficient power supply is in that unit but its a huge power hog!

[oberkc]

I would simply like the program to be halted.

 

In which case, I wholly agree with xathros.

[Teken]

I wanted to follow up and confirm the program works perfectly as intended. Reviewing security videos confirms the ISY is helping me solve this really annoying problem.

 

Thank you all once again!