Jump to content

IOLinc anomaly


swnewman

Recommended Posts

Posted

First time poster...

 

I have two IOLincs (actually the garage door kit SH sells) in my garage (one for each overhead door). I have them programmed in ISY to turn on lights as I come and go through the garage doors. I have timers for lights in the hallway from the garage, lights outside the garage, the whole nine yards. I'm very happy with how it's working. Everything works great, except occasionally I randomly get a false signal from one of the IOLinc sensors. I say randomly because I don't know what's causing it, but from the logs it appears to happen around 4am each time (but not every day). I have a KeypadLinc button inside the house that shows me when either garage door is open, so it is a little disconcerting to wake up to find that light on.

 

Here's the strange thing. When this happens both doors are definitely closed. I go out there and both IOLincs have the green status LED on, indicating that the switch is closed. But when I go into ISY one of the garage door sensors is showing a status of off! I can open this door and close it back and everything goes back to normal. This is very frustrating because I can't imagine how this is happening unless I have a faulty IOLinc.

 

Just for grins I just tried a Restore Device on this IOLinc. I can't get it to complete the process. I have attached the log from this attempt. I have tried it multiple times. I see some "Hops Left=0" but also "Max Hops=1" on some. Not sure if that is relevant.

 

For further info, I seem to have no problem getting a correct status from this device after I 'reset' it (open/close door). Also, I have a house full of Dual Band devices (probably close to 45 spread all around the house). This seems to be my only nagging issue. I'd just like to know if it is an ISY problem or hardware related. Thanks for your help.

 

-Seth

ISY-Events-Log.v3.3.10__Sun 2013.02.17 10.38.08 AM.txt

Posted

Michel,

 

Ah! I knew there must have been something scheduled at 4:00AM...yes it's the Query All. No, I'm not using Trigger Reverse on either IOLinc. I checked the options and both are the same. Is the query all doing something wrong in my setup?

 

Thanks,

Seth

Posted

Hi Seth,

 

If you have not setup your unit with Trigger Reverse, then something else is either changing the status OR that the status is not really reported to ISY. What you need to do is to manually query your IOLinc a few times and see whether or not you get consistent behavior. Some older versions of IOLinc didn't report the status of sensor properly ...

 

With kind regards,

Michel

Posted

Michel,

 

This is an IOLinc v.41.

 

The main issue is it works 98% of the time. If it didn't, all these other programs that depend on the sensor changing state wouldn't be working properly. And they have never not worked; they are rock solid. I can manually query it all day long and have no issue, until one morning at 4am it decides to report the opposite of the state it is in, and stay that way until I cycle it. Very strange.

 

What exactly is the Query All doing? Because this state error condition is literally seconds after 4AM.

 

Did you have a chance to look over the log I created? There seems to be some sort of communication issue, but I don't know what's causing it or if it is related.

 

Thanks,

Seth

Posted

Hi Seth,

 

Yes, I have looked at the log you attached. This said, the log does not show any problems with restore. What error do you get? You might want to factory reset the IOLinc and the retry the restore.

 

With kind regards,

Michel

Posted

Michel,

 

It shows both "ERR 0" and "ERR 1" towards the bottom and I see a few places where "Hops Left=0". Also, every time I attempt the restore, I get the communication error pop up window at some point during the middle of the restore.

 

Thanks,

Seth

Posted

Sounds like the same deal. So far mine has not actually opened the garage door. In fact I have programs set up so that is almost impossible to for the garage door to open via Insteon. The button inside the house is Non-Toggle Off and it checks to see if either door is already open before activating the relay for that door (or both if both are open). Unfortunately when the sensor erroneously reports that the door is open (after a Query All), my scheming doesn't work because now the button inside will open the door when toggled off. Very frustrating!

 

Glad to see I am not the only one with this issue. Sounds like a fairly major issue that needs attention if Insteon is going to be relied on for critical things.

 

Any other suggestions?

Posted

Eh, yeah, not easily but if you think doing a successful restore might help resolve this issue I could do it. For obvious reasons the IOLinc needs to be near the garage door/opener. As I said before though, there don't seem to be any other communication issues with the IOLinc in its current location (programs run as soon as the garage door opens). The other IOLinc (actually farther from the house) is able to restore successfully last time I checked.

Posted

Okay, I'll give it a shot. I probably won't know if it worked--until it fails again--due to the random nature.

 

Most of my devices are dual band; there are two DB switches and a DB dimmer in the garage with the IOLinc.

 

Just out of curiosity, what are the consequences of disabling the Query All program?

Posted

Hello swnewman,

 

Consequences are dependent on:

1. Whether or not you have programs that depend on accurate status of your devices

2. How reliable is your INSTEON system such that ISY can depend on the correct status of your devices

 

With kind regards,

Michel

Posted

Michel if the ISY gets a comm error during the query does it change the current state to a default value or just leave it unmodified?

 

To the poster if you can't restore the device you have com issues. This is going to continue until you tackle them.

Posted

I believe failed comm during query leaves the status of the device unchanged but will pop up a "Could Not Communicate With ..." message on your next login to the admin console.

 

I have had my 3am query disabled since I moved into this house 2 yrs ago. No problems with that (until this morning). I have generally decent comms within the house. Only one Togglinc that gives me trouble in my barn at the far end of a 300+' run. The two other devices in that barn report consistent 3/2 comms so when I get a chance, I will replace the weak togglinc.

 

-Xathros

Posted

Hi bsobel,

 

Xathros is correct: the state remains as is but two things will happen:

1. The node is flagged as being in communication error (the flag in )

2. The control/action event ERR/1 is sent (and captured) so that you can use Is Responding/Is not Responding in your programs

 

With kind regards,

Michel

Posted

I agree there seems to be some sort of comm issue (especially during the restore attempt). This particular device just seems so rock solid in every other sense. It is clearly able to trigger programs when the sensor is actually opened and closed.

 

The query all is definitely doing something to the device. It changes the reported status in ISY to 'Off' - supposedly meaning the proximity switch has been opened. When I open the Admin panel I don't get any pop-up message about that particular device. The green LED on the IOLinc still shows 'On', but I can query the device in the Admin panel and it will say 'Off' until I actually open the sensor and close it back.

 

I will try to investigate the comm issue and attempt a factory reset. That being said, the anomaly hasn't happened again since I posted the original message. I will try some more things next time I see it happen. Thanks for your help.

Posted

swnewman

 

Can you run Tools | Diagnostics | Event Viewer at LEVEL 3 when the Green LED is On and a Query marks the Sensor Off. Thanks

Posted

Thanks. It does not sound like a comm problem if the Query says its Off and the Green LED is On as it should be with the door closed and the newer garage kit with the single NC magnetic switch. Unless the ISY is marking the Sensor with the wrong result from the Query (which is not happening at 4.0.1) it sounds like the I/O Linc is sending the wrong status. Not the kind of symptom I attribute to a comm issue unless the Query does not return a value. The Query request is actually two Insteon commands, one to get the Sensor state and one to get the Relay state. Both Sensor and Relay states are queried regardless of which node the Query is issued against.

Posted

The other thing to look for the next time it fails is compare the Green LED intensity between the I/O Linc that shows On in the ISY and the one that shows Off. The Green LED is not a binary condition. The Green LED can be On but not fully bright and the I/O Linc Sensor will be Off. We discovered this when working with other I/O Linc kits that supply a voltage to the Sensor rather than a c-form switch to GND. If the magnetic switch is not providing a good connection to GND or there is a marginal wire connection at the I/O Linc connector to magnetic switch the Green LED can be On but not fully On with the Sensor reporting Off. Might try moving the wires at the I/O Linc connections and the magnetic switch to see if the Sensor On is intermittent.

Posted

Ok, it happened again this morning. The Keypad light was on inside the house. I went to the garage and both IOLincs show green LEDs and the doors are shut. As far as I can tell the green LEDs are at full brightness, but I did not have time to jiggle the wires running to the device.

 

I went back inside and pulled up ISY. This time both IOLincs were indicating that the sensor was 'Off' aka switch open. So I pulled up Event Viewer Level 3, queried the first IOLinc. It sped right through that with no errors, and lo and behold, it changed the device's sensor state to 'On'. I did the other one and the exact same thing happened. No errors, and the devices are now in the correct state.

 

Ok, this tells me a few things:

1. A manual query when the devices have entered this error state, corrects the issue (as does physically cycling the sensor).

2. There is not a comm issue querying these devices, at least not at the times when I am awake to notice.

3. The Query All seems to be the only contributing factor that I can see at this point.

 

I'm not sure if this muddles things further, but hopefully this info is useful. I haven't had time to attempt further restores or a factory reset. I did log the event viewer data from the queries this morning, but I was on my way out the door. I can upload it later. But like I said, no issues that I could see.

 

I just remembered: I do have another IOLinc inside the house attached to a weather radio. I don't think it has ever entered this error state (haven't checked in ISY though), but I think I would notice since it runs a program that flashes the lamps in the master bedroom. It does work when I test the weather radio, but no 4am false alarms yet! Could be because it is using a momentary sense vs. solid on/off, though.

 

Question: Is there a way to exclude certain devices from the Query All?

Posted

Question: Is there a way to exclude certain devices from the Query All?

 

The only way would be to disable the normal 4am query and build your own scene with only the devices you want queried and a program to query that scene at 4am.

 

-Xathros

Posted

Question: Is there a way to exclude certain devices from the Query All?

 

The only way would be to disable the normal 4am query and build your own scene with only the devices you want queried and a program to query that scene at 4am.

 

-Xathros

 

Use EXTREME caution if you choose to do this. With a user made scene for the purpose of Query, devices that are controller only will be added to the scene as a controller. IE, an IOLinc sensor node would control all the other devices in the scene if it were to turn on. Same for triggerlincs and the like.

Guest
This topic is now closed to further replies.

  • Recently Browsing

    • No registered users viewing this page.
  • Who's Online (See full list)

  • Forum Statistics

    • Total Topics
      37k
    • Total Posts
      371.4k
×
×
  • Create New...