stusviews Posted January 19, 2016 Share Posted January 19, 2016 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. Link to comment
Blackbird Posted January 19, 2016 Author Share Posted January 19, 2016 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? Link to comment
stusviews Posted January 19, 2016 Share Posted January 19, 2016 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. Link to comment
Blackbird Posted January 19, 2016 Author Share Posted January 19, 2016 whats to blame then the isy? PLM? Link to comment
stusviews Posted January 19, 2016 Share Posted January 19, 2016 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. Link to comment
Michel Kohanim Posted January 19, 2016 Share Posted January 19, 2016 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 Link to comment
MWareman Posted January 19, 2016 Share Posted January 19, 2016 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. Link to comment
Blackbird Posted January 20, 2016 Author Share Posted January 20, 2016 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 Link to comment
MWareman Posted January 20, 2016 Share Posted January 20, 2016 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. Link to comment
stusviews Posted January 20, 2016 Share Posted January 20, 2016 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. Link to comment
MWareman Posted January 20, 2016 Share Posted January 20, 2016 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. Link to comment
Blackbird Posted January 20, 2016 Author Share Posted January 20, 2016 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 Link to comment
Blackbird Posted January 20, 2016 Author Share Posted January 20, 2016 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. Link to comment
MWareman Posted January 20, 2016 Share Posted January 20, 2016 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. Link to comment
LeeG Posted January 20, 2016 Share Posted January 20, 2016 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. Link to comment
Blackbird Posted January 20, 2016 Author Share Posted January 20, 2016 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? Link to comment
MWareman Posted January 20, 2016 Share Posted January 20, 2016 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? Link to comment
Blackbird Posted January 20, 2016 Author Share Posted January 20, 2016 It has only happened once and I can't reproduce it manually so I'm not sure what I can do Link to comment
stusviews Posted January 20, 2016 Share Posted January 20, 2016 GremLincs. They're somewhat different in that they always travel in groups of two, hence dual-band GremLincs Link to comment
MWareman Posted January 20, 2016 Share Posted January 20, 2016 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. Link to comment
Blackbird Posted January 21, 2016 Author Share Posted January 21, 2016 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? Link to comment
Blackbird Posted January 21, 2016 Author Share Posted January 21, 2016 My overhead garage door sensor reads as a controller and the relay is a responder. Is this normal? Link to comment
stusviews Posted January 21, 2016 Share Posted January 21, 2016 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. Link to comment
oberkc Posted January 21, 2016 Share Posted January 21, 2016 My overhead garage door sensor reads as a controller and the relay is a responder. Is this normal? In the same scene? Link to comment
Blackbird Posted January 21, 2016 Author Share Posted January 21, 2016 In the same scene? Yes Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.