Jump to content

Bad Garage Door Status at 0300 on two occasions


dba62

Recommended Posts

I have the INSTEON 74551 Garage Door Control and Status Kit on my two garage doors.  I also have a program that sends out an alert if the garage door is left open for 30 minutes.

 

Twice I have gotten this message at exactly 3:30 in the morning.  In each case, the status of the garage door shows up as open, yet the door is closed.  In each case, it was a different garage door. Opening and closing the garage door resolves the issue.

 

Any thoughts?  The fact that the door status changed at exactly 0300 in both cases doesn't seem like a coincidence.

 

Link to comment

Check to see if "trigger reverse" is checked under the IOLinc options. If so then you're probably using a N/O contact and should switch to a N/C contacts and uncheck trigger reverse.

 

The 3:00 am query is resetting the IOLinc thus triggering your alert.

Link to comment

OK - I will check tonight.  This has happened two times since January 1st.   So basically this is working correctly 99% of the time (it has never missed an alert that I am aware, just the 2 false alerts over 240 effective days).

 

The magnetic sensors are in proximity contact when the garage door is closed.

Link to comment

OK - I will check tonight.  This has happened two times since January 1st.   So basically this is working correctly 99% of the time (it has never missed an alert that I am aware, just the 2 false alerts over 240 effective days).

 

The magnetic sensors are in proximity contact when the garage door is closed.

 

If you find that neither of the I/O Lincs are programmed for trigger reverse. This could be COM issue which you will need to address.

Link to comment

If you find that neither of the I/O Lincs are programmed for trigger reverse. This could be COM issue which you will need to address.

 

I'm guessing it is the latter.  Now that I think of it, I have had a couple of times when my outside lights have not been turned off.  Again, this problem has been very infrequent (working correctly 99% of the time).

 

How does one go about addressing a com issue?

Link to comment

I'm guessing it is the latter.  Now that I think of it, I have had a couple of times when my outside lights have not been turned off.  Again, this problem has been very infrequent (working correctly 99% of the time).

 

How does one go about addressing a com issue?

 

Do you have any dual band device(s) on the same electrical branch as the GDO? If you have another plugin dual band Lamp Linc or On/Off Relay this would help you determine if you have bridging / coupling.

 

The 4 tap (beacon) test is the first thing you need to confirm for a solid Insteon network. Initiate the beacon test from the 2413S PLM and see if the dual band device Acks this RF test.

 

If the test shows no bridging / coupling you need to address that portion.

 

If the 4 tap beacon test shows proper coupling / bridging than more likely there is a new noise issue present. This can be a noise maker to a signal sucker. That can be from a new device being plugged in not normally at those hours or operating in that time frame.

 

Most common are cell chargers, bad transformers, even LED / CFL bulbs just going bad. When you notice devices turn on fine but have a hard time turning off its more likely the load is the cause. Even if that load worked fine before when electronics go bad like the electronic ballasts etc.

 

These little gremlins start to impact the network.

Link to comment
  • 1 month later...

So I read this thread and thought I would see if I could resolve my 3am garage door issues (occasional lights on in the garage in the morning when I wake up.  

 

Trigger reverse was not selected so I thought I would try it, bad idea.  Now that I have unchecked trigger reverse, my status is reversed.  On one door, things are working correct.  When door is closed, status is on.  On the other door, when door is closed status is off. Both doors do not have the option for trigger reverse and both doors are set exactly the same.  I tried restoring the device and no change.  Any ideas?

Link to comment

Run Tools | Diagnostics | Event Viewer at LEVEL 3.   Click on the I/O Linc Options button, set Trigger Reverse and click Done.  Click I/O Linc Options button again, uncheck Trigger Reverse and click Done.   Post event trace.  Assuming using the same type magnetic switch, either the Options update was not successful before or the magnetic switch is not working correctly.

Is the Green LED On on both I/O Lincs when door closed. 

Link to comment

Do you mean the status of the sensor (green LED) or something else? Do you have a 2-wire or 3-wire magnetic switch? Any particular reason that you change the trigger to reverse? Were you already having a difficulty?

Link to comment

If the green status LED is lit in one position of the garage door and unlit in the other position for both garages, then the I/O Lincs are functioning correctly and the problem is elsewhere.

Link to comment

I would check the Green LEDs.   Comm to I/O Linc is varied.  Some response has Hops Left=2,  some have Hops Left=0.

 

Mon 06/08/2015 08:20:03 PM : [iNST-TX-I1  ] 02 62 1A E8 CB 0F 11 FF
 
Mon 06/08/2015 08:20:03 PM : [iNST-ACK    ] 02 62 1A.E8.CB 0F 11 FF 06          LTONRR (FF)
 
Mon 06/08/2015 08:20:03 PM : [All         ] Writing 1 bytes to devices
 
Mon 06/08/2015 08:20:03 PM : [iNST-TX-I2CS] 02 62 23 D2 F1 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0
 
Mon 06/08/2015 08:20:03 PM : [iNST-SRX    ] 02 50 1A.E8.CB 24.1C.B3 2B 11 FF    LTONRR (FF)
 
Mon 06/08/2015 08:20:03 PM : [std-Direct Ack] 1A.E8.CB-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
 
Mon 06/08/2015 08:20:03 PM : [D2D EVENT   ] Event [1A E8 CB 1] [sT] [255] uom=0 prec=-1
 
Mon 06/08/2015 08:20:03 PM : [  1A E8 CB 1]       ST 255
 
Mon 06/08/2015 08:20:03 PM : [iNST-ACK    ] 02 62 23.D2.F1 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06        (00)
 
Mon 06/08/2015 08:20:04 PM : [iNST-SRX    ] 02 50 23.D2.F1 24.1C.B3 2B 2F 00           (00)
 
Mon 06/08/2015 08:20:04 PM : [std-Direct Ack] 23.D2.F1-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
 
Mon 06/08/2015 08:20:04 PM : [iNST-ERX    ] 02 51 23 D2 F1 24 1C B3 11 2F 00 01 01 0F FF 20 A2 00 24 1C B3 FF 1F 01 ED 
 
Mon 06/08/2015 08:20:04 PM : [Ext-Direct  ] 23.D2.F1-->ISY/PLM Group=0, Max Hops=1, Hops Left=0
 
Mon 06/08/2015 08:20:04 PM : [23 D2 F1 1  ] Memory : Write dbAddr=0x4006 [0E] cmd1=0x20 cmd2=0x0E
 
Mon 06/08/2015 08:20:04 PM : [iNST-TX-I2CS] 02 62 23 D2 F1 1F 20 0E 00 00 00 00 00 00 00 00 00 00 00 00 00 D2
 
Mon 06/08/2015 08:20:04 PM : [iNST-ACK    ] 02 62 23.D2.F1 1F 20 0E 00 00 00 00 00 00 00 00 00 00 00 00 00 D2 06        (0E)
 
Mon 06/08/2015 08:20:05 PM : [iNST-SRX    ] 02 50 23.D2.F1 24.1C.B3 2B 20 0E           (0E)
 
Mon 06/08/2015 08:20:05 PM : [std-Direct Ack] 23.D2.F1-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
 
Mon 06/08/2015 08:20:05 PM : [iNST-SRX    ] 02 50 23.D2.F1 24.1C.B3 23 20 0E           (0E)
 
Mon 06/08/2015 08:20:05 PM : [std-Direct Ack] 23.D2.F1-->ISY/PLM Group=0, Max Hops=3, Hops Left=0
 
Mon 06/08/2015 08:20:05 PM : [iNST-SRX    ] 02 50 23.D2.F1 24.1C.B3 23 20 0E           (0E)
 
Mon 06/08/2015 08:20:05 PM : [std-Direct Ack] 23.D2.F1-->ISY/PLM Group=0, Max Hops=3, Hops Left=0
 
Mon 06/08/2015 08:20:13 PM : [iNST-TX-I1  ] 02 62 33 F1 0F 0F 11 FF
 
Mon 06/08/2015 08:20:13 PM : [iNST-ACK    ] 02 62 33.F1.0F 0F 11 FF 06          LTONRR (FF)
 
Mon 06/08/2015 08:20:14 PM : [iNST-SRX    ] 02 50 33.F1.0F 24.1C.B3 27 11 FF    LTONRR (FF)
 
Mon 06/08/2015 08:20:14 PM : [std-Direct Ack] 33.F1.0F-->ISY/PLM Group=0, Max Hops=3, Hops Left=1
 
Mon 06/08/2015 08:20:14 PM : [D2D EVENT   ] Event [33 F1 F 1] [sT] [255] uom=0 prec=-1
 
Mon 06/08/2015 08:20:14 PM : [   33 F1 F 1]       ST 255
 
Mon 06/08/2015 08:20:18 PM : [All         ] Writing 1 bytes to devices
 
Mon 06/08/2015 08:20:18 PM : [iNST-TX-I2CS] 02 62 23 D2 F1 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0
 
Mon 06/08/2015 08:20:18 PM : [iNST-ACK    ] 02 62 23.D2.F1 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06        (00)
 
Mon 06/08/2015 08:20:19 PM : [iNST-SRX    ] 02 50 23.D2.F1 24.1C.B3 27 2F 00           (00)
 
Mon 06/08/2015 08:20:19 PM : [std-Direct Ack] 23.D2.F1-->ISY/PLM Group=0, Max Hops=3, Hops Left=1
 
Mon 06/08/2015 08:20:19 PM : [iNST-SRX    ] 02 50 23.D2.F1 24.1C.B3 23 2F 00           (00)
 
Mon 06/08/2015 08:20:19 PM : [std-Direct Ack] 23.D2.F1-->ISY/PLM Group=0, Max Hops=3, Hops Left=0
 
Mon 06/08/2015 08:20:20 PM : [iNST-ERX    ] 02 51 23 D2 F1 24 1C B3 11 2F 00 01 01 0F FF 20 A2 00 24 1C B3 FF 1F 01 ED 
 
Mon 06/08/2015 08:20:20 PM : [Ext-Direct  ] 23.D2.F1-->ISY/PLM Group=0, Max Hops=1, Hops Left=0
 
Mon 06/08/2015 08:20:20 PM : [23 D2 F1 1  ] Memory : Write dbAddr=0x4006 [0F] cmd1=0x20 cmd2=0x0F
 
Following command to turn Trigger Reverse Off got no Response.
 
Mon 06/08/2015 08:20:20 PM : [iNST-TX-I2CS] 02 62 23 D2 F1 1F 20 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 D1
 
Mon 06/08/2015 08:20:20 PM : [iNST-ACK    ] 02 62 23.D2.F1 1F 20 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 D1 06        (0F)
 
Mon 06/08/2015 08:20:23 PM : [iNST-TX-I1  ] 02 62 00 00 19 CF 11 00
 
Mon 06/08/2015 08:20:23 PM : [iNST-ACK    ] 02 62 00.00.19 CF 11 00 06          LTONRR (00)
 
Mon 06/08/2015 08:20:23 PM : [Ext MH      ] Unexpected Ack imCmd=62 cmd1=LTONRR 0x11
 
Retry of command gets multiple responses
 
Mon 06/08/2015 08:20:28 PM : [iNST-TX-I2CS] 02 62 23 D2 F1 1F 20 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 D1
 
Mon 06/08/2015 08:20:28 PM : [iNST-ACK    ] 02 62 23.D2.F1 1F 20 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 D1 06        (0F)
 
Mon 06/08/2015 08:20:28 PM : [iNST-SRX    ] 02 50 23.D2.F1 24.1C.B3 2B 20 0F           (0F)
 
Mon 06/08/2015 08:20:28 PM : [std-Direct Ack] 23.D2.F1-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
 
Mon 06/08/2015 08:20:28 PM : [iNST-SRX    ] 02 50 23.D2.F1 24.1C.B3 23 20 0F           (0F)
 
Mon 06/08/2015 08:20:28 PM : [std-Direct Ack] 23.D2.F1-->ISY/PLM Group=0, Max Hops=3, Hops Left=0
 
Mon 06/08/2015 08:20:33 PM : [iNST-TX-I1  ] 02 62 23 FE FE 0F 11 FF
 
Mon 06/08/2015 08:20:33 PM : [iNST-ACK    ] 02 62 23.FE.FE 0F 11 FF 06          LTONRR (FF)
 
Mon 06/08/2015 08:20:33 PM : [iNST-SRX    ] 02 50 23.FE.FE 24.1C.B3 27 11 FF    LTONRR (FF)
 
Mon 06/08/2015 08:20:33 PM : [std-Direct Ack] 23.FE.FE-->ISY/PLM Group=0, Max Hops=3, Hops Left=1
 
Mon 06/08/2015 08:20:33 PM : [D2D EVENT   ] Event [23 FE FE 1] [sT] [255] uom=0 prec=-1
 
Mon 06/08/2015 08:20:33 PM : [  23 FE FE 1]       ST 255
 
 
I would expect retry to have worked and Trigger Reverse would be Off.  Green LEDs should confirm.
Link to comment

I'm not understanding how a bad com is causing his 3 am query to trigger the program.  If the com is bad, then the query will get a no response from the device.  If the program says "if status is on, then . . " then a no response will not trigger the program.  The device must actually be on, but ISY thought it was off, and then the query succeeded, thus changing the status in ISY to on and triggering the program.

Link to comment

apostolakisl 

 

The comm issue may be other than no response to Query although the trace of Trigger Reverse does show a no response to the Extended command.  The 3AM Query is a short Standard command and most likely is a delay in getting one of the Query responses back which can falsely indicate "door open" when it is actually closed.   The trace does show Hops Left=0 messages so it is difficult to know without an actual trace at 3AM of a failure.    

Link to comment

apostolakisl 

 

The comm issue may be other than no response to Query although the trace of Trigger Reverse does show a no response to the Extended command.  The 3AM Query is a short Standard command and most likely is a delay in getting one of the Query responses back which can falsely indicate "door open" when it is actually closed.   The trace does show Hops Left=0 messages so it is difficult to know without an actual trace at 3AM of a failure.    

 

The reason I say this is that I have had a similar experience with my whole house audio turning on when the kpl button I use to turn it on was actually on, and ISY thought it was off, then the 3am query corrected the ISY register and triggered the program.  I prevented that issue from ever happening again by changing to a "if control" program.  It was certainly rather startling to have the whole house music turn on at 3am!

 

So, in fact had a com issue, but the com issue wasn't at 3am, it was sometime earlier when the kpl was supposed to have shut off along with the whole house music, but didn't, leaving it out of sync with the ISY register.

 

But to your statement "comm issue may be other than no response".  Are you saying that a bad comm can result in a wrong answer (on instead of off) instead of just no answer at all?  I'm having a hard time figuring out the mechanism.  I have never seen that before, but I don't have any devices with trigger reverse and perhaps that feature can  cause a false opposite answer..

Link to comment

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.   This way both Sensor and Relay report Off at 3AM so a  late Query response does not produce unwanted action at 3AM.

 

An event trace at 3AM when something unexpected occurs is needed to know what actually happened. 

Link to comment

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.   This way both Sensor and Relay report Off at 3AM so a  late Query response does not produce unwanted action at 3AM.

 

An event trace at 3AM when something unexpected occurs is needed to know what actually happened. 

Makes sense now.

If this can happen with 2 separate nodes on the same device, why can't is happen with 2 nodes on 2 different devices?  Or can it? 

Link to comment

Not with different devices.   The Query response has the device Insteon address so physical device confusion is not possible.  Only which node in the same physical device can be an issue because the Query response does not contain the node Group number.

 

There was a FanLinc issue a few days ago for the same reason (wrong node Status changed).  First time I had seen a situation where the FanLinc Query results triggered a Program because of the change in Fan Status because Light Status was applied to Fan node.  

Link to comment

Not with different devices.   The Query response has the device Insteon address so physical device confusion is not possible.  Only which node in the same physical device can be an issue because the Query response does not contain the node Group number.

 

There was a FanLinc issue a few days ago for the same reason (wrong node Status changed).  First time I had seen a situation where the FanLinc Query results triggered a Program because of the change in Fan Status because Light Status was applied to Fan node.  

So would a kpl have the same potential issue?

Link to comment

Don't think so.   The load control button is Queried with a Standard/Direct command to obtain local load information.

 

This is followed by a single Extended command that returns all the Secondary KPL button On/Off states as a bit map.

 

This Direct message pulls local load information.
 
Tue 06/09/2015 06:23:01 PM : [iNST-TX-I1  ] 02 62 1B 57 F8 0F 19 00
Tue 06/09/2015 06:23:01 PM : [iNST-ACK    ] 02 62 1B.57.F8 0F 19 00 06          LTSREQ (LIGHT)
Tue 06/09/2015 06:23:01 PM : [iNST-SRX    ] 02 50 1B.57.F8 22.80.0B 2B 00 00           (00)
Tue 06/09/2015 06:23:01 PM : [std-Direct Ack] 1B.57.F8-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Tue 06/09/2015 06:23:01 PM : [D2D EVENT   ] Event [1B 57 F8 1] [sT] [0] uom=0 prec=-1
Tue 06/09/2015 06:23:01 PM : [  1B 57 F8 1]       ST   0
Tue 06/09/2015 06:23:01 PM : [D2D EVENT   ] Event [1B 57 F8 1] [OL] [51] uom=0 prec=-1
Tue 06/09/2015 06:23:01 PM : [  1B 57 F8 1]       OL  51
Tue 06/09/2015 06:23:01 PM : [D2D EVENT   ] Event [1B 57 F8 1] [RR] [31] uom=0 prec=-1
Tue 06/09/2015 06:23:01 PM : [  1B 57 F8 1]       RR  31
 
This single Extended message pulls all Secondary button information.
 
Tue 06/09/2015 06:23:01 PM : [iNST-TX-I2  ] 02 62 1B 57 F8 1F 2E 00 01 00 00 00 00 00 00 00 00 00 00 00 00 D1
Tue 06/09/2015 06:23:01 PM : [iNST-ACK    ] 02 62 1B.57.F8 1F 2E 00 01 00 00 00 00 00 00 00 00 00 00 00 00 D1 06        (00)
Tue 06/09/2015 06:23:02 PM : [iNST-SRX    ] 02 50 1B.57.F8 22.80.0B 2B 2E 00           (00)
Tue 06/09/2015 06:23:02 PM : [std-Direct Ack] 1B.57.F8-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Tue 06/09/2015 06:23:02 PM : [iNST-ERX    ] 02 51 1B 57 F8 22 80 0B 11 2E 00 01 01 00 00 20 20 1F 33 43 02 00 00 12 00 
Tue 06/09/2015 06:23:02 PM : [Ext-Direct  ] 1B.57.F8-->ISY/PLM Group=0, Max Hops=1, Hops Left=0
 
Hard to see how these messages could be confused.
Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...