Incorrect IOLinc Query

[Kush]

Not sure I understand what happened so I hope someone here can help.

 

I have an IOLinc that monitors the status of 3 garage doors. If any one of the doors are opened, a Pushover notification is sent and the garage lights are turned on. At 3am, while sleeping, I got a Pushover notification indicating a garage door had been opened. Thinking someone was in the garage that shouldn’t be, I checked Mobilinc and it did show that a garage door was open, but noticed it did not show the garage lights turned on. I turned on the lights with Mobilinc and checked my cams to be sure no one was in the garage and all doors were closed. All seemed to be ok, so I checked the Administrative console and saw that the Factory Query All Program just ran at 3am and the ISY was showing a garage door was open. I again queried only the IOLinc Garage Door Sensor, and it corrected the door status. Why would the Query All report the incorrect status? Everything was working fine and showed the correct status before the query. Why would a second query be different from the first? The garage doors are on a NC loop and would have turned the lights on if any of the doors did actually open. I did go out to physically check the doors are all were properly closed.
 
Thank You
Kush

 

[Teken]

Not sure I understand what happened so I hope someone here can help.

 

I have an IOLinc that monitors the status of 3 garage doors. If any one of the doors are opened, a Pushover notification is sent and the garage lights are turned on. At 3am, while sleeping, I got a Pushover notification indicating a garage door had been opened. Thinking someone was in the garage that shouldn’t be, I checked Mobilinc and it did show that a garage door was open, but noticed it did not show the garage lights turned on. I turned on the lights with Mobilinc and checked my cams to be sure no one was in the garage and all doors were closed. All seemed to be ok, so I checked the Administrative console and saw that the Factory Query All Program just ran at 3am and the ISY was showing a garage door was open. I again queried only the IOLinc Garage Door Sensor, and it corrected the door status. Why would the Query All report the incorrect status? Everything was working fine and showed the correct status before the query. Why would a second query be different from the first? The garage doors are on a NC loop and would have turned the lights on if any of the doors did actually open. I did go out to physically check the doors are all were properly closed.

 

Thank You

Kush

 

Hello Kush,

 

Is it safe to say none of the I/O lincs are programmed with the *Trigger Reverse* option? Can you please verify and post up a screen capture for each I/O linc.

 

My expectation is (even if) the ISY was rebooted it would have sent a confirmation the door was closed not open. This is how I have my system set using Prowl and e-mail to ensure if there is a system issue I always know the last known (good) state.

 

One thing to try and confirm is if perhaps the sensor that gave the bad reading could have (momentarily) tripped due to a large gust of wind.

 

This is something I have tested in my own system to see how much magnetic gap would cause the system to trip. To date I have confirmed it would take more than half an inch of travel before the door would show a open / ajar state.

 

That sort of wind condition is not typical in my area so depending upon how your sensor is mounted this could impact you more or less. For your reference my sensor is mounted at the top of the door and the actual sensor just uses gravity to fall into place.

 

Meaning even if the wind blew the door (buffeted) the sensor would move in unison with the door moving back and forth. This is why I mounted my sensor this way because it provided the most robust method of monitoring opposed to other means.

[Xathros]

Kush-

 

Is your IOLinc and mag switch set up to have the sensor On when the door is closed?  If so, this could be an issue where the Query returned the correct state for the sensor but the ISY instead heard the return of the Relay state (Off) and mistook it to be the state of the sensor.  I know this has been discussed on these forums a few times before.  LeeG can likely explain the reasoning better than I but I believe it comes down to timing of the status messages mixed with duplicate messages from the IOLinc being received at the PLM.  The PLM Queries both the sensor and the relay in separate messages and can mistake a duplicate response from the first query as a response to the second.

 

-Xathros

[Kush]

Hello Teken and Xathros ,

 

Thanks for the quick replies!

 

Both garage doors and 1 service door each have a NC magnetic switch. They are connected in series in a Closed circuit loop to 1 IOLinc – Sensor terminals. I then created a program so that when any door is opened, either from a garage door opener or service door, a Pushover Notification is sent, then the garage lights are turned on for 10 minutes, then off unless Motion is detected.

 

The status in the ISY does show ON when all doors are CLOSED.

 

I do not have Trigger Reverse checked in Options

 

I do not use the RELAY of the IOLinc at all due to the ALL ON issue. (I’ve had 1 unreported ALL ON after installing the Motion Sensor, but haven’t had another since inserting a 2 sec delay)

 

Both garage door magnet switches are as close as they could possibly get. (Nearly resting on top of each other) The service door magnet had issues at one time due to the weather causing the wood frame to swell, so I set it up so the gap can be adjusted.

 

This closed loop was used for a wireless alarm system before Insteon. I do not believe the wind would have cause the loop to open, if it did, even for an instant, it should have triggered the program to turn on the garage lights.

 

I also use an ApplianceLinc to control the Garage Door Opener Power with MobiLinc and a (Unreliable) geofence. (I do have an ibeacon but don’t know enough about the RPi to get that working!)

 

My garage set up has been working fairly well for at least a few weeks now until this query issue had me thinking someone was in the garage. The ISY did not reboot and has been running continuously for at least a few weeks.

 

Thanks again

 

KUSH

[Jimbo.Automates]

I have experienced the exact same 3am query all problem with IoLinc sensor status, because of this I changed my notifications to run a query again before sending the notice. I suspect they were caused by communication problems but haven't been able to confirm.

 

Sent from my Nexus 7 using Tapatalk

[LeeG]

Kush

 

The I/O Linc Sensor and Relay are queried when either Sensor or Relay is queried.  The Relay query response can be delayed due to comm issue such that the relay response comes back after the Sensor is queried but before the Sensor response comes back. It makes the Relay query response look like the Sensor response.  Since the Relay is Off, it looks like the Sensor has changed state to indicate an open door (since NC magnetic switches are used).

 

Suggest running Tools | Diagnostics | Event Viewer at LEVEL 3.  Issue a Query for the I/O Linc Sensor a few times and post the event trace.  There is an Icon on the bottom of the Event Viewer display, next to last on right, that Copy to Clipboard.  Paste the event trace to a forum post.

 

The problem may be time dependent.  If the comm issue is difficult to solve, using NO magnetic switches wired in parallel will bypass the comm issue because the Relay Off and Sensor Off have the same response.

[Kush]

Thanks everyone for all your help and suggestions. I now have a good understanding of what probably happened.

 

Jimbo, thanks for the tip, I'll try that for now.

 

LeeG, thanks for the expaination, I think as soon as the weather warms up, I'll rewire the garage to use NO magnetic switches. I also like Teken's suggestion that if the ISY reboots, I would be sent a confirmation that the doors were closed.

 

Thanks Again

Kush

[Jimbo.Automates]

Kush, you are welcome.

 

Lee, that explains the issue for NC, but mine are NO, so not sure what caused this for me?

[Xathros]

Kush, you are welcome.

 

Lee, that explains the issue for NC, but mine are NO, so not sure what caused this for me?

Was your relay On at the time by any chance?

 

-Xathros

[Jimbo.Automates]

Was your relay On at the time by any chance?

 

-Xathros

The relay should only be on for the short time, but I need to check my setup to verify.

[LeeG]

Kush

 

We have a cross in terminology.   The magnetic switches are closed when the doors are closed.  They would not work in a series loop otherwise.   Whether you call them NO or NC (security applications refer to them one way, industry applications refer to them the other),  the I/O Linc Sensor is On with the doors closed.  The Relay is Off when the Query is done so the response is the opposite to the door closed state reported by the I/O Linc Sensor.  Therefore it looks like a door has moved when it has not. 

 

Sorry for the confusion regarding NC versus NO.   The solution is to correct the comm issue (assumption without seeing event trace).   The alternative is to use magnetic switches that operate opposite to what you are using now.

 

That way the Relay and Sensor are in the same state so if the Relay response is slow to arrive it will be the same as closed doors so no false message.

[LeeG]

Kush

 

Finally had some time to find examples that show the difference in nomenclature.

 

This link describes a NO switch (one that closes when magnet near switch)

 

https://www.inventables.com/technologies/magnetic-switch-normally-open

 

This link describes the same operation, circuit closed when magnet near, as NC switch.

 

http://www.smarthome.com/seco-larm-sm-205q-w-enforcer-nc-magnetic-contacts-with-15-inch-leads-white.html

 

The difference being one is for security, the other for industry.  Same switch operation, circuit closed when magnet near, but one is described as NO and one is described as NC.  Just one of those things that can add to the confusion about how a switch operates. 

[DavidJ101]

It can be confusing, but I always use the following rule when determining normal state.

 

Normal state, as it relates to switches, is with no external influence. In this case, without the magnet.

 

Also if you'll notice even on the smarthome page they list it as N.O. contact for N.C. circuits.

[LeeG]

DavidJ101

 

Works for most of the mag switches Smarthome sells as they are primarily Security devices.   If the mag switch is purchased from a larger online firm that sells both Security and Industry devices it requires some analysis of how the device actually functions.  I was burned many years ago by that mistake.

[Brian H]

Unfortunately there is confusion.

As an Electronic Technician I also think of the resting state with no magnet next to it.

 

Security use. Lists the state of the magnetic switch when it is not in the violated state. Most likely when the magnet is next to the switch.

I have seen similar problems over in the X10 forums when trying to decipher a magnetic switch type.

[bipto]

_{This sounds painfully familiar.  I was also burned by this ambiguity when buying replacements for my garage door IOLincs, purchasing switches identical to those I sought to replace.  I ended up hedging my bets and finding a single pole, double throw (SPDT) model reed switch, which allowed me to wire it in the configuration of my choice.  Fool me once, LOL...} 

[Brian H]

The original Garage Door Kit. Came with a SPDT reed switch. So you could pick the NO or NC contacts  for your setup.

Smarthome now uses a cheaper magnetic switch. Though I believe the kit is the same price.

[Teken]

The original Garage Door Kit. Came with a SPDT reed switch. So you could pick the NO or NC contacts  for your setup.

Smarthome now uses a cheaper magnetic switch. Though I believe the kit is the same price.

 

No kidding, talk about scamming the customer. The Seco version has been used in almost every major application from thousands of vendors around the world.

 

Its proven, reliable, and flexible for the end users needs why mess with something good that just works??

[Kush]

LeeG

 

Very sorry for the delayed response. There has finally been some decent motorcycle weather around here so I've been busy working on that.

 

Sorry about the confusion. I did install wired alarm systems back when I was young, so that is how I am used to referring to them. An alarm system could use either NO or NC magnetic switches. NO circuits (with magnet near switch) would be wired in parallel so when a door opened (magnet moved away) it completed or close the circuit. Problem with NO is wires could easily be cut and never trigger the alarm.  

NC (with magnet near switch) wired in series was always much better to use because if a wire were to be cut anywhere along the length of the circuit, it would trigger the alarm.

 

Since I do not use the relay of the IOLinc, would it help avoid the query issue if I checked “Relay Follows Input” with my current set up?

 

I ran the event trace 4x

 

 

Wed 03/18/2015 10:24:07 PM : [iNST-TX-I1  ] 02 62 2F 79 00 0F 19 01
Wed 03/18/2015 10:24:07 PM : [iNST-ACK    ] 02 62 2F.79.00 0F 19 01 06          LTSREQ (01)
Wed 03/18/2015 10:24:07 PM : [iNST-SRX    ] 02 50 2F.79.00 25.28.20 2B 00 01           (01)
Wed 03/18/2015 10:24:07 PM : [std-Direct Ack] 2F.79.00-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Wed 03/18/2015 10:24:07 PM : [D2D EVENT   ] Event [2F 79 0 1] [sT] [255] uom=0 prec=-1
Wed 03/18/2015 10:24:07 PM : [   2F 79 0 1]       ST 255
Wed 03/18/2015 10:24:07 PM : [D2D-CMP 00B2] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=255 uom=0 prec=-1) --> true
Wed 03/18/2015 10:24:07 PM : [D2D-CMP 00B1] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> false
Wed 03/18/2015 10:24:07 PM : [D2D-CMP 0077] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=255 uom=0 prec=-1) --> true
Wed 03/18/2015 10:24:07 PM : [D2D-CMP 0076] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> false
Wed 03/18/2015 10:24:07 PM : [iNST-TX-I1  ] 02 62 2F 79 00 0F 19 00
Wed 03/18/2015 10:24:07 PM : [iNST-ACK    ] 02 62 2F.79.00 0F 19 00 06          LTSREQ (LIGHT)
Wed 03/18/2015 10:24:08 PM : [iNST-SRX    ] 02 50 2F.79.00 25.28.20 2B 00 FF           (FF)
Wed 03/18/2015 10:24:08 PM : [std-Direct Ack] 2F.79.00-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Wed 03/18/2015 10:24:13 PM : [iNST-TX-I1  ] 02 62 2F 79 00 0F 19 01
Wed 03/18/2015 10:24:13 PM : [iNST-ACK    ] 02 62 2F.79.00 0F 19 01 06          LTSREQ (01)
Wed 03/18/2015 10:24:13 PM : [iNST-SRX    ] 02 50 2F.79.00 25.28.20 2B 00 01           (01)
Wed 03/18/2015 10:24:13 PM : [std-Direct Ack] 2F.79.00-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Wed 03/18/2015 10:24:13 PM : [D2D EVENT   ] Event [2F 79 0 1] [sT] [255] uom=0 prec=-1
Wed 03/18/2015 10:24:13 PM : [   2F 79 0 1]       ST 255
Wed 03/18/2015 10:24:13 PM : [D2D-CMP 00B2] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=255 uom=0 prec=-1) --> true
Wed 03/18/2015 10:24:13 PM : [D2D-CMP 00B1] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> false
Wed 03/18/2015 10:24:13 PM : [D2D-CMP 0077] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=255 uom=0 prec=-1) --> true
Wed 03/18/2015 10:24:13 PM : [D2D-CMP 0076] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> false
Wed 03/18/2015 10:24:13 PM : [iNST-TX-I1  ] 02 62 2F 79 00 0F 19 00
Wed 03/18/2015 10:24:14 PM : [iNST-ACK    ] 02 62 2F.79.00 0F 19 00 06          LTSREQ (LIGHT)
Wed 03/18/2015 10:24:14 PM : [iNST-SRX    ] 02 50 2F.79.00 25.28.20 2B 00 FF           (FF)
Wed 03/18/2015 10:24:14 PM : [std-Direct Ack] 2F.79.00-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Wed 03/18/2015 10:24:19 PM : [iNST-TX-I1  ] 02 62 2F 79 00 0F 19 01
Wed 03/18/2015 10:24:19 PM : [iNST-ACK    ] 02 62 2F.79.00 0F 19 01 06          LTSREQ (01)
Wed 03/18/2015 10:24:19 PM : [iNST-SRX    ] 02 50 2F.79.00 25.28.20 2B 00 01           (01)
Wed 03/18/2015 10:24:19 PM : [std-Direct Ack] 2F.79.00-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Wed 03/18/2015 10:24:19 PM : [D2D EVENT   ] Event [2F 79 0 1] [sT] [255] uom=0 prec=-1
Wed 03/18/2015 10:24:19 PM : [   2F 79 0 1]       ST 255
Wed 03/18/2015 10:24:19 PM : [D2D-CMP 00B2] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=255 uom=0 prec=-1) --> true
Wed 03/18/2015 10:24:19 PM : [D2D-CMP 00B1] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> false
Wed 03/18/2015 10:24:19 PM : [D2D-CMP 0077] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=255 uom=0 prec=-1) --> true
Wed 03/18/2015 10:24:19 PM : [D2D-CMP 0076] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> false
Wed 03/18/2015 10:24:19 PM : [iNST-TX-I1  ] 02 62 2F 79 00 0F 19 00
Wed 03/18/2015 10:24:19 PM : [iNST-ACK    ] 02 62 2F.79.00 0F 19 00 06          LTSREQ (LIGHT)
Wed 03/18/2015 10:24:20 PM : [iNST-SRX    ] 02 50 2F.79.00 25.28.20 2B 00 FF           (FF)
Wed 03/18/2015 10:24:20 PM : [std-Direct Ack] 2F.79.00-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Wed 03/18/2015 10:24:25 PM : [iNST-TX-I1  ] 02 62 2F 79 00 0F 19 01
Wed 03/18/2015 10:24:25 PM : [iNST-ACK    ] 02 62 2F.79.00 0F 19 01 06          LTSREQ (01)
Wed 03/18/2015 10:24:26 PM : [iNST-SRX    ] 02 50 2F.79.00 25.28.20 2B 00 01           (01)
Wed 03/18/2015 10:24:26 PM : [std-Direct Ack] 2F.79.00-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Wed 03/18/2015 10:24:26 PM : [D2D EVENT   ] Event [2F 79 0 1] [sT] [255] uom=0 prec=-1
Wed 03/18/2015 10:24:26 PM : [   2F 79 0 1]       ST 255
Wed 03/18/2015 10:24:26 PM : [D2D-CMP 00B2] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=255 uom=0 prec=-1) --> true
Wed 03/18/2015 10:24:26 PM : [D2D-CMP 00B1] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> false
Wed 03/18/2015 10:24:26 PM : [D2D-CMP 0077] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=255 uom=0 prec=-1) --> true
Wed 03/18/2015 10:24:26 PM : [D2D-CMP 0076] STS [2F 79 0 1] ST op=1 Event(val=255 uom=0 prec=-1) is Condition(val=0 uom=0 prec=-1) --> false
Wed 03/18/2015 10:24:26 PM : [iNST-TX-I1  ] 02 62 2F 79 00 0F 19 00
Wed 03/18/2015 10:24:26 PM : [iNST-ACK    ] 02 62 2F.79.00 0F 19 00 06          LTSREQ (LIGHT)
Wed 03/18/2015 10:24:26 PM : [iNST-SRX    ] 02 50 2F.79.00 25.28.20 2B 00 FF           (FF)
Wed 03/18/2015 10:24:26 PM : [std-Direct Ack] 2F.79.00-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
 

Thank You

Kush
 

[LeeG]

The Relay is already reporting as On which should not be possible in any of the Momentary modes.  It looks like the relay Options the ISY is tracking for the I/O Linc do not match the device.  Comm looks good in the trace.  It would take some intermittent interference to be causing a comm issue.  

 

 

\\Wed 03/18/2015 10:24:07 PM : [iNST-TX-I1  ] 02 62 2F 79 00 0F 19 00

Wed 03/18/2015 10:24:07 PM : [iNST-ACK    ] 02 62 2F.79.00 0F 19 00 06          LTSREQ (LIGHT)
Wed 03/18/2015 10:24:08 PM : [iNST-SRX    ] 02 50 2F.79.00 25.28.20 2B 00 FF           (FF) - Relay On
Wed 03/18/2015 10:24:08 PM : [std-Direct Ack] 2F.79.00-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

Cannot tell from this trace what happened at 3AM Query.

 

Since the Insteon products are not Security oriented an EOL resister cannot be used to protect a NO circuit.

 

 

At this point I would not change any Option to try to compensate without positive trace information, except turn the Relay Off.  If failing often then have the event trace running at 3AM.  Otherwise wait and see what happens.

[stusviews]

NO circuits (with magnet near switch) would be wired in parallel so when a door opened (magnet moved away) it completed or close the circuit. Problem with NO is wires could easily be cut and never trigger the alarm.  

NC (with magnet near switch) wired in series was always much better to use because if a wire were to be cut anywhere along the length of the circuit, it would trigger the alarm.

 

 

The usual definition of a contact closer/interrupter is the device's at rest state, that is, no external influence. A NC relay, for example, opens when voltage is applied. A NO momentary switch requires moving a lever or pushing a button to complete the circuit. Likewise, a magnetic reed/contact switch changes it's at rest state when under the influence of a magnet.

 

NO = proximity to a magnetic field closes the contacts

NC = proximity to a magnetic field opens the contacts

 

That's also the same way the I/O Linc contacts are labeled.

[Kush]

LeeG

 

Sorry, the relay reporting On was my fault. I switched the relay to Latching in an effort to cause the failure. I will leave things as is (Relay Off) for now, and hope I can capture something in an event trace. For now, there isn’t much I can do. Thank you for your time. If I continue to have issues on this or I am able to capture an event trace, I’ll be sure and post it here.

 

Thank You

Kush

[LeeG]

Thanks for the update.  A delay in either the Sensor or Relay response is easy to see in the event trace regardless of On or Off state.   Appreciate the effort in trying to recreate.  Post back if anything develops.