IOLinc anomaly

[LeeG]

belias

 

The situation is not limited to I/O Lincs. I ran 4 QueryAll tests and found several devices besides the I/O Lincs that have duplicate ACKs with Hops Left=0 .

 

The PLM in use for my local tests is a 2413S at v.99

 

These are from the last trace you posted.

 

12.FA.3C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

13.32.2D-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

14.73.02-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

1F.C2.B7-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

17.A4.9D-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

14.37.A0-->ISY/PLM Group=0, Max Hops=3, Hops Left=0

[belias]

LeeG,

 

My PLM is a 2413S at V92. Also, see below for an explanation of the other devices you noted in your last post:

 

These are from the last trace you posted.

 

12.FA.3C-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 - IO Linc v.36

13.32.2D-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 - IO Linc v.36

14.73.02-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 - KPL v.36

1F.C2.B7-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 - IO Linc v.41

17.A4.9D-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 - KPL v.00

 

A few other comments:

 

1) I have a total of 6 IO Linc's in the house; 3 connected to the garage doors, and 3 used for other reasons. It's interesting that ONLY the garage door IOLincs are showing this anomaly. All but one are v.36.

 

2) I will attempt to move one of them closer to the PLM and see if this makes a difference. Also, around the time I started noticing this happen more frequently I believe I did add a dual band SwitchLinc nearby (although not on the same circuit). I will try removing this and seeing if there's any improvement. Frustratingly, this only happens about once per week on the Query All, so it makes it tough to troubleshoot...

 

 

Thanks again for the help.

 

- Brian

[LeeG]

I no longer think distance is related as the test I ran over the weekend had the devices on the same circuit as the PLM. Could be an RF message from a distant Access Point that took its time getting back through a series of devices before reaching the PLM. Also since multiple devices types show the same behavior it is more likely an issue with the Insteon Mesh network rather an any one particular device or device type. Some of the I/O Lincs (at least what I thought were I/O Lincs) in your trace reported Sensor Off as the normal state. These would not show any external symptom since a duplicate relay response that marks them Off would not change the reported Sensor state. For example, are 17.A4.9D and 15.BB.75 I/O Lincs. It looks like it from the query calls. The Sensors on these I/O Linc (?) show the Sensor as Off to begin with.

 

I'm thinking about getting a new 2413 PLM to see if a later PLM firmware has any affect on this.

[Xathros]

I am having a different but similar problem that I am convinced is a multiple message problem. I have a RL2 in my car that I use to turn toggle outside lights or set away/vacant modes in the house as we are leaving. Recently, my lights started to turn on then about a second later back off almost every time I used the RL2 button when outside of the garage. From outside the garage, the RL2 is able to reach an access point in the garage and a new Dualband SLR for my front porch lights. This problem started when I added the SLR. If I airgap the front porch SLR the problem stops. Adding a 2 second wait as the first line in my then "fixed" the symptom by ignoring the cause.

 

I realize this is different from the IOLink query double response issue reported here but I fully believe the underlying cause is the same - duplicate messages treated as valid messages.

 

-Xathros

[belias]

LeeG,

 

Sorry, I should have made this more clear in my last post. See below for quick list of device types...a few of these are NOT IOLincs as you expected...

 

 

12.FA.3C - IO Linc v.36 (garage; sensor normally on)

13.32.2D - IO Linc v.36 (garage; sensor normally on)

14.73.02 - KPL v.36

1F.C2.B7 - IO Linc v.41 (garage; sensor normally on)

17.A4.9D - KPL v.00

15.BB.75 - IO Linc v.36 (monitors an external IR sensor; sensor normally off)

[swnewman]

It's nice to see that I wasn't the only one with this issue. Though I wouldn't wish the frustration on anyone, it helps to see that it is not unique to my setup. This definitely seems like an issue that Smart Labs should address with the mesh protocol on the PLM.

 

In the meantime, any word on the priority for the BugID#58 workaround? Hopefully it'll move up the list with more and more people noticing the problem. Haven't noticed any issues since I disabled Query All, but I'd still like to get back to the "nominal" configuration at some point.

 

-Seth

[northportphoneguy]

I too have this identical problem. So...i'm watching this thread with much interest. Everytime there is a query or reboot, I have to manually open and close the garage doors to get the IOLincs to be in sync.

[LeeG]

northportphoneguy

 

Your symptom does not sound like what is reported in this topic. When a simple Query gets the Status out of sync it is the result of using Trigger Reverse. This option reverses the commands the I/O Linc sends for a Sensor state change. When the Sensor turns On it sends an Off command, when the Sensor turns Off it sends an On command.

 

The problem with using Trigger Reverse is it does NOT reverse the Query response. Query returns the True state of the Sensor, not the command reversed state. This situation has become more prevalent when Smarthome started shipping the garage kit with a NC magnetic switch rather than the combined NO/NC magnetic switch. The only good solution is to change the magnetic switch to NO and drop the use of Trigger Reverse.

[Scott MS]

I agree with Lee's comments above. I finally broke down and bought the NO garage magnetic contacts and have had fewer issues.

 

As far as the 3 AM Query and the IO Lincs, I got tired to getting texts at 3:20 a.m telling me the garage was open for 20 minutes (Running 4.0.2, PLM v99, and IO Lincs v.41). It has happened to me about 5 times in the past year at 3:00 a.m. and mostly in the past 2-3 months. Hasn't seemed to happen since I changed the garage contacts to NO last weekend -- perhaps because both the sensor and relay is both Off with the NO contacts.

 

I now also Query the IO Lincs a second time at the end of the program after a couple of Wait statements to isolate the traffic.

 

If

Time is 3:00:00AM

 

Then

Set Scene 'ISY' Query

Wait 5 minutes

Set 'Large Garage Status' Query

Wait 5 minutes

Set 'Small Garage Status' Query

 

Else

- No Actions -

[northportphoneguy]

Thank you LeeG. Whatever would this board do without you. A wealth of knowledge, you are.

[Xathros]

I now also Query the IO Lincs a second time at the end of the program after a couple of Wait statements to isolate the traffic.

 

If
Time is 3:00:00AM

Then
Set Scene 'ISY' Query
Wait 5 minutes
Set 'Large Garage Status' Query
Wait 5 minutes
Set 'Small Garage Status' Query

Else

- No Actions -

 

I suspect the first 5 minute wait is to ensure you are past the traffic from the big 3am query. I would think 5 seconds would be sufficient for the second wait.

 

-Xathros

[Scott MS]

Correct on the wait times between queries -- no rationale other than it is 3:00 a.m. and at that time I have absolutely nothing occuring in terms of Insteon traffic.

 

I actually changed my programs slightly. I don't trigger any scenes based on the garage door open, although I do start a timer to provide an alert if the door is open longer than 20 minutes. This was randomly being triggered at 3:20 a.m. since the Query resulted in the door sometimes being "Off" using the NC sensors.

 

I fixed the problem using two measures. First, I installed the NO garage magentic sensors so that garage is now "On" when open and then "Off" when closed. The nightly queries of my two IO Lincs should both return "Off" for the senor and the relay because they should never be open at 3:00 a.m. Thus, a delay in routing should have little impact, if I understand the issues correctly.

 

The second measure I put in place was removing the separate IO Linc Query from the 3:00 a.m. program (that I documented above) and created a special query if the either door is open after 10 minutes. Basically, if the original query was incorrect, this second query at the 10:00 minute mark should update with the correct door status and end any programs that were running based on an invalid status. In order for the 20 minute alert to be sent, an "On" event should have been received initially and the an "On" query would also have been received at the 10 minute mark confirming the status.

 

In the end, I really only want to make sure that nobody leaves the garage doors open by accident. And I like the fact that I can close them remotely, if necessary.

[JScott]

Hi All,

 

I'd like to add my name to the hat of folks experiencing this issue as well.

 

I have a PLM v63 and my IOLinc is v.41 which is hooked up to the Garage door (reply controls door, sensor reports open/closed of garage door.) My PLM is old, my IOLinc is new (purchased last week.) Exactly two min and 39 seconds after my QueryAll Program runs (at 3am), the state of the sensor changes from off (meaning door is closed) to On (reporting door is open.) This naturally queues other programs altering me that the garage door has been left open. I have the armored garage door sensor from SH and am not using the Trigger Reverse option.

 

I will be doing an event Trace Level 3 and post that once the anomaly happens again, but from the sounds of it, it appears I am just getting the duplicate/delayed sensor responses during the QueryAll program which is causing the change of state problems (of course won't know until I inspect the event trace log.)

 

LeeG - you mentioned you were getting a newer PLM. I am wondering if that would help me out also, considering mine is about 5yrs old. Thoughts?

 

Thanks all.

 

~J

[LeeG]

JScott

 

Absent an event trace it does sound like the same situation unless you are using Trigger Reverse. Use of Trigger Reverse is a separate issue.

 

I received a new 2413S PLM yesterday with firmware v.9B. I'm hoping to replace the PLM in my test bed this weekend to see if the v.9B firmware is any better at catching the duplicate messages. I’ll post the results when testing with the new PLM is complete.

[JScott]

 

I received a new 2413S PLM yesterday with firmware v.9B. I'm hoping to replace the PLM in my test bed this weekend to see if the v.9B firmware is any better at catching the duplicate messages. I’ll post the results when testing with the new PLM is complete.

 

Excellent! I'll also post the event trace once I have it captured. Thanks!

 

Jordan

[LeeG]

JScott

 

I reread your first post. With the Sensor turning On with the Query I would check the I/O Linc options in use. This sounds much more like Trigger Reverse is in use than duplicate Relay status messages. The Relay is Off in a garage application except for the second or so the Relay starts door movement. If a duplicate Relay message was the cause it would be interpreted as Sensor Off rather than Sensor On.

[LeeG]

The v.9B PLM firmware does not eliminate the duplicate message traffic with Hops Left=0.

[JScott]

That's unfortunate re the newer PLM fw not helping...

 

In other news, I'm a flipping idiot. I did have Trigger Reverse set. I won't go in to why I thought I didn't. Long story short, I'll be ordering the NO armored magnet sensor! Endless purchases at SH!

 

~J

[LeeG]

JScott

 

Thanks for taking the time to post back. That feedback is so useful to others who are/will read this topic.

 

It is unfortunate that the current garage kit only includes the NC magnetic contact. Some prefer the Sensor to be On when the door is closed but many prefer the opposite. Was so easy when the combined NO/NC switch was standard part of the garage kit.

[mmb]

I have an iolinc and experiencing the same problem - query all or any query changes the sensor status. Was this issue ever resolved?

 

In my opinion, if you can't query the sensor and get a reliable response, then the device is useless and shouldn't be on the market.

 

Am I missing something?

 

Thanks!

 

mike

[LeeG]

The Query response has not been changed. Query has always returned the accurate state of the I/O Linc Sensor. If the Sensor is On (Green LED On) Query indicates the Sensor is On. If the Sensor is Off (Green LED Off) Query indicates the Sensor is Off.

 

This problem arises when the Trigger Reverse option is used in combination with Query. Trigger Reverse reverses the commands the I/O Linc sends when the Sensor changes state. When the Sensor turns On (Green LED On) the I/O Linc sends an Off command. When the Sensor turns Off (Green LED Off) the I/O Linc sends an On command. Trigger Reverse only reverses the commands the I/O Linc sends. Trigger Reverse does not change the Query response. The Query response is an accurate state of the Sensor.

 

Since the ISY issues Query every day at 3 AM a conflict can exist between Trigger Reverse and Query. The best solution is to use a magnetic switch that produces the desired Sensor On/Off state without using Trigger Reverse.

[hart2hart]

Lee and/or Michel:

 

Didn't locate this thread and posted another viewtopic.php?f=27&t=15163 this morning and was directed here by helpful person. What is current state of this issue? Suggestions of installing NO contacts and doing additional query of device as required are what I got from the postings. Aside from bandaids on our part, is this on SmartLabs radar?

 

Thanks,

 

Paul

[LeeG]

I'm not sure this is an I/O Linc issue. If this is the same problem the Insteon network presents a duplicate message after the next Query is done to the I/O Linc. The duplicate message looks like a response to the last Query which changes the I/O Linc Sensor status. I don't think the duplicate message is physically sent by the I/O Linc which makes it hard for any change to the I/O Linc itself to resolve this.

[MWareman]

Its why I've kinda given up on IOLinc for garage door status... I've ordered one of these to test for my garage door: http://www.amazon.com/dp/B00HGVJRX2/ref ... 90_TE_dp_1

[hart2hart]

I'm not sure this is an I/O Linc issue. If this is the same problem the Insteon network presents a duplicate message after the next Query is done to the I/O Linc. The duplicate message looks like a response to the last Query which changes the I/O Linc Sensor status. I don't think the duplicate message is physically sent by the I/O Linc which makes it hard for any change to the I/O Linc itself to resolve this.

 

Understand what is happening based on reading your excellent research. Issue is that we are still getting wrong results so a fix is needed. Not sure where which is why i mention SL. Without fully understanding, Would updating ISY query so iolinc queries are run last and with delay have potential impact results since firestorm of activity appears from reading your posts to facilitate issue.

 

Just spitballing but is there no solution possible ?