Bad Garage Door Status at 0300 on two occasions

[apostolakisl]

What problem are you having with a KPL?

 

If you're asking me, none.  Just questioning why multiple nodes on a fanlinc or io linc might cause this odd issue and if I should consider the same problem on my kpls if and when I have any odd behavior.  I don't have any fanlincs or iolincs, though I think I will be buying some fanlincs in the future.  I have no need for IO lincs as I have all that stuff hardwired to my elk, which is rock solid reliable.  And if I were to go with a non Elk I/O device, it would be my webcontrol boards, which I suppose may even be integrated as nodes at some point in the near future, but even if not, they work great using the REST interface.  I have a number of wifi to ethernet adapters which work quite nicely with my webcontrol boards and to date has never had a failed com.  I can pretty much put them anywhere and get ~100% response.

[dba62]

The I/O Linc has two nodes, Sensor and Relay, each node must be queried individually.  In this case the Sensor will report On with the door closed and of course the Relay will report Off.   There are cases traced and posted where a Query response will be late arriving at the PLM such that the Relay Off Query response is applied to the Sensor Query.  The Query response does not indicate which node it applies to.   This can result in a Program being run because the door Status looks Open when the door is actually closed. 

 

Although it best to try and resolve the late message some users have found it easier to change magnetic switch such that the door Status is Off when door is closed.

 

What do you mean by change the magnetic switch?  Move the location of the magnet or sensor? 

 

Are there any other options to work around an intermittent communications issue?

[Teken]

What do you mean by change the magnetic switch?  Move the location of the magnet or sensor? 

 

Are there any other options to work around an intermittent communications issue?

 

Older GDO kits came with a sensor that could be wired to be N.O. vs N.C. Meaning the LED on the unit would reflect the door open (lit)  vs closed (unlit).

 

Newer GDO kits have only one contact and this always results in the I/O Linc's LED to show the reverse state. So your choices are to purchase the magnetic contact that offers the reverse behavior.

 

Better yet purchase the correct kit which offers both N.O. & N.C. contacts.

[stusviews]

Older GDO kits came with a sensor that could be wired to be N.O. vs N.C. Meaning the LED on the unit would reflect the door open (lit)  vs closed (unlit).

 

Newer GDO kits have only one contact and this always results in the I/O Linc's LED to show the reverse state. So your choices are to purchase the magnetic contact that offers the reverse behavior.

 

Better yet purchase the correct kit which offers both N.O. & N.C. contacts.

 

Not possible, there's only one garage door kit.

[dba62]

Older GDO kits came with a sensor that could be wired to be N.O. vs N.C. Meaning the LED on the unit would reflect the door open (lit)  vs closed (unlit).

 

Newer GDO kits have only one contact and this always results in the I/O Linc's LED to show the reverse state. So your choices are to purchase the magnetic contact that offers the reverse behavior.

 

Better yet purchase the correct kit which offers both N.O. & N.C. contacts.

 

So the newer kits have NO and NC, but this is for control of the garage door opener?   I only see one input for the sensor.

[stusviews]

All Insteon garages kits include NO and NC.  That's just the feature of the I/O Linc which has many purposes.There has always been only one sensor input. The concern is if the sensor terminals are connected a Normally Open or Normally Closed magnet contact switch.   The former will send an Off signal when the garage door is open (when the sensor is away the magnet the contacts are open) and the latter will send an On signal when the door is open.

[Brian H]

Stu,

Are you referencing the NC and NO relay contacts or the magnetic sensor in the kit?

I just looked. The present kit has the single contact arrangement magnetic sensor. Not the older more expensive one with NO and NC outputs.

[dba62]

There has always been only one sensor input. The concern is if the sensor terminals are connected a Normally Open or Normally Closed magnet contact switch.   The former will send an Off signal when the garage door is open (when the sensor is away the magnet the contacts are open) and the latter will send an On signal when the door is open.

 

OK - I finally understand.  Are the older magnetic sensors still available?  Regardless, I probably don't want to spend the money and/or do the requisite rewiring.

 

Would it be possible to code around this in my program that monitors the garage door?   Specifically I am asking is there a way to programmatically  force a query?  If so, I can code around this.

[Teken]

Yes, here is the older dual type sensor: http://www.smarthome.com/seco-larm-sm-226l-3-magnetic-garage-door-contact-switch.html

[stusviews]

And yes, you can code around the problem by selecting Trigger Reverse. A difficulty is the the nightly query will at some time randomly reverse the reverse with no warning.

[dba62]

Right now I have:

 

If Open

    Wait 30 minutes

     Send alert

 

Is threre anyway to do something like:

 

If Open

    Wait 10 minutes

    <query>

    If Open

      Wait 10 minutes

       Send Alert

 

 

I assuming merely adding If Open won't accomplish anything because there won't be a second query after the 3 am query.

[stusviews]

The ISY does not have nested IFs as a construct. In any case, that won't solve the reverse the Trigger Reverse problem.

[Sub-Routine]

How I solved the Query All at 3AM issue with IOLincs, unpowered LampLincs, etc.

 

I created a few scenes containing all the devices I want to Query and none of the ones I don't.

I modified the 3AM Query program to query only those scenes.

Query My Lights - [ID 0027][Parent 002B]

If
        Time is  3:00:00AM
 
Then
        Set Scene 'Indoor Lights / Indoor Lights' Query
        Wait  3 seconds
        Set Scene 'Outside Lights / Outside Lights' Query
        Wait  3 seconds
        Set Scene 'Basement / Basement Lights' Query
 
Else
   - No Actions - (To add one, press 'Action')
 
Schedule migrated from previous version.
Modified for specific devices.

Now the only time the unwanted devices are queried is after a power outage.

 

[oberkc]

Right now I have:

 

If Open

    Wait 30 minutes

     Send alert

 

Is threre anyway to do something like:

 

If Open

    Wait 10 minutes

    <query>

    If Open

      Wait 10 minutes

       Send Alert

 

 

I assuming merely adding If Open won't accomplish anything because there won't be a second query after the 3 am query.

dba62,

 

While I agree with stusviews response (in regards to nested conditions as well whethernthis is a solution to your trigger reverse problem), the ISY does (in my estimation) provide sufficient flexibility and power to program the logic you propose. If you wish to discuss further, let us know.

 

I definitely believe the best solution to a trigger reverse problem is to replace the sensor with one that works as needed for the application.

[dba62]

dba62,

 

While I agree with stusviews response (in regards to nested conditions as well whethernthis is a solution to your trigger reverse problem), the ISY does (in my estimation) provide sufficient flexibility and power to program the logic you propose. If you wish to discuss further, let us know.

 

I definitely believe the best solution to a trigger reverse problem is to replace the sensor with one that works as needed for the application.

 

I'm going to go ahead and purchase the sensors, but I would like to understand how the programming could be acconmplished.

 

It would seem that the following might work:

 

If Open

    Wait 15 minutes

    Query Garage Doors

    Sleep 10 seconds

    If Open

         Wait 15 minutes

         Notify

[stusviews]

I'm going to go ahead and purchase the sensors, but I would like to understand how the programming could be acconmplished.

 

It would seem that the following might work:

 

If Open

    Wait 15 minutes

    Query Garage Doors

    Sleep 10 seconds

    If Open

         Wait 15 minutes

         Notify

 

No, that won't work I already indicated that the ISY does not support nested IFs. Also, I'm not sure what you are trying to accomplish, the I/O Linc sensor status can be used a a program trigger, There's no need to query it.

[oberkc]

It would seem that the following might work:

 

If Open

    Wait 15 minutes

    Query Garage Doors

    Sleep 10 seconds

    If Open

         Wait 15 minutes

         Notify

 

it might, if you have nested IF statements.  We don't.

 

However, understanding triggers and effect on wait statements, you could accomplish similar logic by:

 

if

open

then

run second program (then path)

else

nothing

 

second program:

 

if

nothing

then wait 15 minutes

run third program (if path)

else

nothing

 

third program (disabled)

if

open

then

wait 15 minutes

notify

else

nothing

[dba62]

No, that won't work I already indicated that the ISY does not support nested IFs. Also, I'm not sure what you are trying to accomplish, the I/O Linc sensor status can be used a a program trigger, There's no need to query it.

 

The status can be bad.  I am trying to verify the status at least once before generating a message.

[dba62]

So what I ended up doing which seems to work was to write a query garage door program:

 

If

     Status ' Garage Closed' is Off

Then

     Wait 3 minutes

     Set "Garage Closed" Query

     Wait 3 minutes

     Set "Garage Closed" Query"

Else

      - No Actions

 

But I am wondering if this works the way I would like it to.  My question is: what happens if the first query shows that the door is actually closed.

 

Will the THEN be exited or will it continue to execute the following Wait/Query?  If the first query shows that the door is open, I don't want to execute the second query.

 

What I am trying to do is query the door status twice.  If it returns open both times, then I am willing to believe that it is actually opened.

[oberkc]

But I am wondering if this works the way I would like it to.  My question is: what happens if the first query shows that the door is actually closed.​

 

I suppose it depends on what you would like it to do, and whether "closed" = "off".  It may also be affected if you are using the sensor reverse mode on the IOLinc.

 

In general, if the query causes a change in status of 'garage closed', the program will re-evaluate.  A program in a wait state that is re-evaluated will be halted and run from the beginning, based upon the newly-evaluated status (true or false).

[dba62]

I suppose it depends on what you would like it to do, and whether "closed" = "off".  It may also be affected if you are using the sensor reverse mode on the IOLinc.

 

In general, if the query causes a change in status of 'garage closed', the program will re-evaluate.  A program in a wait state that is re-evaluated will be halted and run from the beginning, based upon the newly-evaluated status (true or false).

 

Thank you.  That is exactly what I wanted to know, although I end up with another question.  Here is the sequence of events, I am wondering what happens next:

 

Garage Opens

Wait 3 minutes

Query Garage (still open)

Wait 3 minutes

Query Garage (still open)

 

Does the program go back to the if statement at this point?    If so, then the second wait/query combination is superfluous.

[oberkc]

Programs are triggered by events, based upon the conditions. Programs do not automatically re-evaluate based solely upon completion of an action clause.

[dba62]

Programs are triggered by events, based upon the conditions. Programs do not automatically re-evaluate based solely upon completion of an action clause.

 

Thanks, so this program does want I want.

 

Occasionally (< 1% of the time) my garage door sensor will return a bad status (I believe that part of the message is lost which results in improper interpretation).  So now if that happens, the sensor is queried two additional times to validate the current state.  

[oberkc]

Yes. You can also check status (true/false) of the program. If true, that is a pretty good indicator tat it ladt run THEN path to completion.