As I've indicated in #45, I have had the garage doors (both) opening at query time.  Nothing else turned on. I've also experienced the ALL ON on several occasions including I/O Lincs, originally several times within a couple of weeks, later less often; now rarely. My current PLM is V2, v9E. Most of the ALL ONs were with a V.1 PLM,

 

There phenomena, to date, have no definitive cause.

Edited January 19, 20169 yr by stusviews

As I've indicated in #45, I have had the garage doors (both) opening at query time.  Nothing else turned on. I've also experienced the ALL ON on several occasions including I/O Lincs, originally several times within a couple of weeks, later less often; now rarely. My current PLM is V2, v9E. Most of the ALL ONs were with a V.1 PLM,

 

There phenomena, to date, have no definitive cause.

Check my first post.  It shows the query program running 16 seconds after the door opened.  Am I reading this wrong?

I'm in agreement with you. But if it was just the query that caused the garage doors to open, then it would occur every night, but it doesn't. So, I'll say it again (w/o the typo), these phenomena, to date, have no definitive cause.

whats to blame then the isy?  PLM?

Only ISY users have reported such events. But, to date, these phenomena have no definitive cause, only speculation. No one has been able to reliably reproduce this aberrant behavior.

Edited January 19, 20169 yr by stusviews

Hello all,

 

The only possible reason would be that

1. What ISY considered to be the status is NOT the same when IOLinc is queried (Trigger Reverse?)

2. There's a program that depends on #1

 

I have seen this before with Trigger Reverse and some older IOLincs.

 

With kind regards,

Michel

Fundamentally, if you have 'Trigger Reverse' set on, a query will always cause the sensor to reverse state - potentially causing havoc with any programs that trigger on a door state change.

 

'Trigger Reverse' only reverses the on/off triggers - it does not reverse the state when queried.

 

Let's say I have a program that triggers when the door opens, and closes the door after 30 mins. With trigger reverse enabled, at 3am (or whenever the query runs) the status will change to 'open' even though the door is still closed. The program will trigger and 30 mins later a 'close' signal will be sent - but this will actually open the door. Now a real 'open' trigger is sent, restarting the program and 30 minutes later the door will close.

 

Best practice is to never use trigger reverse. If you need to reverse the input state on an IOLinc, change out the door sensor for a 3 wire one and wire it show it shows the correct state without having to use trigger reverse.

 

Then when the query runs, there will be no state change.

Edited January 19, 20169 yr by MWareman

Fundamentally, if you have 'Trigger Reverse' set on, a query will always cause the sensor to reverse state - potentially causing havoc with any programs that trigger on a door state change.

 

'Trigger Reverse' only reverses the on/off triggers - it does not reverse the state when queried.

 

Let's say I have a program that triggers when the door opens, and closes the door after 30 mins. With trigger reverse enabled, at 3am (or whenever the query runs) the status will change to 'open' even though the door is still closed. The program will trigger and 30 mins later a 'close' signal will be sent - but this will actually open the door. Now a real 'open' trigger is sent, restarting the program and 30 minutes later the door will close.

 

Best practice is to never use trigger reverse. If you need to reverse the input state on an IOLinc, change out the door sensor for a 3 wire one and wire it show it shows the correct state without having to use trigger reverse.

 

Then when the query runs, there will be no state change.

I don't have reverse trigger checked off

Other than trigger reverse and an odd program there really is nothing electrically that could operate the door other than a failing IOLinc or bad GDO itself. What makes you think it was ISY that commanded the opening?

 

Unless someone nearby managed to send a wireless Insteon signal that opened the door. It's not impossible because there is no security in the Insteon protocol.

Edited January 20, 20169 yr by MWareman

My indication was that, according to the log, the garage doors--both--opened seconds after the nightly query began each time, about 3 or 4 instances. The garage doors haven't unexpectedly opened any other time.

If you manually run the 'Query All' - does your door open? If so - capture and post a level 3 log of the event. If not, then its probably not the query doing it.

My indication was that, according to the log, the garage doors--both--opened seconds after the nightly query began each time, about 3 or 4 instances. The garage doors haven't unexpectedly opened any other time.

 

This happened 3 min before the nightly 3am query

Could my "all off" program have opened the door even though the io link is not part of the program? It is set to run at 2:57am and ran 1 second before the door opened.

Could my "all off" program have opened the door even though the io link is not part of the program? It is set to run at 2:57am and ran 1 second before the door opened.

From the log, it certainly looks like something in the 'all off' program opened the door - and the sensor sent a status update after the door opened - all before the 'query all' ran. However, a level 3 log of the incident would have revealed more detail.

MWareman

 

I suggested a LEVEL 3 Event Trace in post #25 Jan 10th.   No interest for doing that in 10 days so I gave up.

MWareman

 

I suggested a LEVEL 3 Event Trace in post #25 Jan 10th.   No interest for doing that in 10 days so I gave up.

As I said I have been out of town. How do I do a level 3 trace?

You'll have to open the Admin Console, open up the log and select level 3, then leave the Console open while you reproduce the issue. It's pretty verbose - but that's what is needed. Capture the event then filter it for the timeframe before posting it.

 

We're you able to reproduce the issue with manually running the scene and/or program you suspect?

It has only happened once and I can't reproduce it manually so I'm not sure what I can do

GremLincs. They're somewhat different in that they always travel in groups of two, hence dual-band GremLincs

You could try splitting apart the times of the 3am query and the 2:57 program - put an hour between them so you can identify which is causing it next time it happens. Maybe change the query to 4am. I suspect some device in your 2:57 program has another program triggering on status change of one of the member devices (which your 2:57am program will trigger), and the opening time will likely stay with the program rather than move with the query.

 

Other than 'All On', I've never seen any reports of iolincs spontaneously operating. Even though I am NOT a proponent of using an iolinc for garage door control, I strongly suspect there is a logic error somewhere buried in the programs that is/was the root cause. It's not going to be easy to identify without being able to reproduce it.

You'll have to open the Admin Console, open up the log and select level 3, then leave the Console open while you reproduce the issue. It's pretty verbose - but that's what is needed. Capture the event then filter it for the timeframe before posting it.

 

We're you able to reproduce the issue with manually running the scene and/or program you suspect?

I click on log and it asks if I want to open in excel.  I don't see the level 3 option.  Or do you mean the Event viewer?

Edited January 21, 20169 yr by Blackbird

My overhead garage door sensor reads as a controller and the relay is a responder.  Is this normal?

Level 3 refers to Tools > Diagnostics > Event Viewer, not the log.

 

Yes, the sensor is a controller (and responder) and the relay is a responder only.

My overhead garage door sensor reads as a controller and the relay is a responder.  Is this normal?

In the same scene?

In the same scene?

Yes