dba62 Posted April 27, 2015 Posted April 27, 2015 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.
Techman Posted April 27, 2015 Posted April 27, 2015 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.
dba62 Posted April 27, 2015 Author Posted April 27, 2015 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.
Teken Posted April 27, 2015 Posted April 27, 2015 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.
dba62 Posted April 27, 2015 Author Posted April 27, 2015 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?
Teken Posted April 27, 2015 Posted April 27, 2015 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.
saphotoexpress Posted June 9, 2015 Posted June 9, 2015 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?
LeeG Posted June 9, 2015 Posted June 9, 2015 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.
stusviews Posted June 9, 2015 Posted June 9, 2015 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?
saphotoexpress Posted June 9, 2015 Posted June 9, 2015 Green LED on Both. Same switch/setup on both identical units. Only problem I was having before I messed with trigger reverse was occasionally waking up to lights on based on a program set to turn them on when GD is open.
saphotoexpress Posted June 9, 2015 Posted June 9, 2015 Hmm, thought I uploaded the file, let me try again. ISY-Events-Log.v4.2.18__Mon 2015.06.08 08.20.39 PM.txt
stusviews Posted June 9, 2015 Posted June 9, 2015 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.
LeeG Posted June 9, 2015 Posted June 9, 2015 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.
saphotoexpress Posted June 9, 2015 Posted June 9, 2015 If garage door is closed, green led is lit. If garage door is open, green led is off.
saphotoexpress Posted June 9, 2015 Posted June 9, 2015 Ok, now both garage doors are closed and status is showing "on" for both and the issue seems to be gone for now. I guess I won't play with trigger reverse any more I will look into com issues (as mentioned above) to resolve the 3am problem. Thanks.
apostolakisl Posted June 9, 2015 Posted June 9, 2015 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.
LeeG Posted June 9, 2015 Posted June 9, 2015 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.
apostolakisl Posted June 9, 2015 Posted June 9, 2015 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..
LeeG Posted June 9, 2015 Posted June 9, 2015 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.
apostolakisl Posted June 9, 2015 Posted June 9, 2015 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?
LeeG Posted June 9, 2015 Posted June 9, 2015 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.
apostolakisl Posted June 9, 2015 Posted June 9, 2015 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?
LeeG Posted June 9, 2015 Posted June 9, 2015 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.
Recommended Posts