Blackbird Posted June 29, 2019 Share Posted June 29, 2019 According to the log, at 3:03am my overhead garage door sensor turned on for no reason I can see. The door was closed and it appears to be caused by the 3am query. Any ideas? Link to comment
Brian H Posted June 29, 2019 Share Posted June 29, 2019 Are you using the Sensor Reversed choice in the UDI setup screen for the 2450 I/OLinc in the garage door kit? There have been others reporting the Query see the actual sensors status not the reversed status. Used to control the garage door and see if it is closed or open. Link to comment
oberkc Posted June 29, 2019 Share Posted June 29, 2019 For what it is worth, I don't think the "sensor" can be turned on or off by the ISY, or by any other controller. The "relay", however, is a different story. Do you have a program that is triggered by a change of state by the sensor? Link to comment
Blackbird Posted June 29, 2019 Author Share Posted June 29, 2019 3 minutes ago, Brian H said: Are you using the Sensor Reversed choice in the UDI setup screen for it? There have been others reporting the Query see the actual sensors status not the reversed status. If your referring to "Trigger Reverse" then no. I dont see Sensor Reversed. Also using Momentary A Link to comment
Brian H Posted June 29, 2019 Share Posted June 29, 2019 Yes Trigger Reversed was what I was thinking about. Link to comment
Blackbird Posted June 29, 2019 Author Share Posted June 29, 2019 2 minutes ago, oberkc said: For what it is worth, I don't think the "sensor" can be turned on or off by the ISY, or by any other controller. The "relay", however, is a different story. Do you have a program that is triggered by a change of state by the sensor? It was definitely the sensor that turned on. Relay was off. I have email notifications when the door is opened. Nothing running at that time and nothing should have triggered it. First time happening. I also have a keypad in the house that lights up when the door is open. That keypad was lit in the morning. Link to comment
Brian H Posted June 29, 2019 Share Posted June 29, 2019 You may want to check the sensor itself. To verify it is still working correctly and its position has not changed. From your description it does sound like it actually sent an On command or the ISY994i thought it sent an on. Link to comment
Blackbird Posted June 29, 2019 Author Share Posted June 29, 2019 Sensors are working fine and havent moved. Be a weird coincidence that it happened at 3am right when the query happened and not be the isy fault Link to comment
jec6613 Posted June 29, 2019 Share Posted June 29, 2019 If you're using an IOLinc with your sensor, you might want to restore it from the ISY just in case. I've found that I have to restore mine every year or so because it goes wonky being attached to the same circuit as the garage door motor load. Link to comment
Blackbird Posted June 29, 2019 Author Share Posted June 29, 2019 What do you mean restore it? Link to comment
jec6613 Posted June 29, 2019 Share Posted June 29, 2019 Right click on the device in the Admin Console and hit Restore Device. It erases and re-writes the EPROM so that it matches what's in the ISY database for the device. Link to comment
oberkc Posted June 29, 2019 Share Posted June 29, 2019 6 hours ago, Blackbird said: t was definitely the sensor that turned on More likely (in my mind, at least) is that the query caused the sensor to report its status. The sensor cannot be a scene responder and cannot be controlled by anY other insteon device. Besides, absent a program or scene somewhere, the sensor, itself, would not cause the door to open. (You dont have the opener connected to the sensor inputs, do you?). I also remain curious about the answer to BrianH question about sensor reverse setting. Link to comment
larryllix Posted June 30, 2019 Share Posted June 30, 2019 Garage door openers have always been reported to upset Insteon communications for years here. I always just ignored that, but wondered why my comms were flakey at times, until I installed a newer GDO unit with battery backup (charger). Then Insteon comms went to about 50% and I had to investigate. Unplugging both technology GDOs, the comms went completely perfect again. It isn't the GDO motors that cause Insteon disturbances (they aren't moving) , it's the cheap electronics or the RF transmitter checking for remotes. Two FilterLincs solved those problems and the I/oLincs are plugged right into the back of them, on the unfiltered receptacles provided. Should have done it for the first GDO years ago. Link to comment
shbatm Posted June 30, 2019 Share Posted June 30, 2019 9 hours ago, Blackbird said: According to the log, at 3:03am my overhead garage door sensor turned on for no reason I can see. The door was closed and it appears to be caused by the 3am query. I've had this behavior for years, I always just thought it was a strange quirk. In my 3am query program I added a "Wait 3 Seconds" then "Run If" for my Garage Sensor change program (the program that updates/reverses my KeypadLincs. The "re-check" of the sensor in the if statement is usually enough to correct the sensor status. 18 minutes ago, larryllix said: Two FilterLincs solved those problems and the I/oLincs are plugged right into the back of them Of all the $$$ and time I've spent on Insteon and SmartHome.com -- This is the first I've ever heard of a FilterLinc. Thanks for the suggestion! Link to comment
Blackbird Posted June 30, 2019 Author Share Posted June 30, 2019 Trigger is not reversed. A while ago my door opened at 3am by itself. Since then I have the garage door opener plugged into a insteon outlet and the power is always off until I open the small door, then the power turns on for 5 min then shuts off again. Link to comment
larryllix Posted June 30, 2019 Share Posted June 30, 2019 29 minutes ago, Blackbird said: Trigger is not reversed. A while ago my door opened at 3am by itself. Since then I have the garage door opener plugged into a insteon outlet and the power is always off until I open the small door, then the power turns on for 5 min then shuts off again. Good work-around! When there is a lot of noise and things are programming or just operating Insteon devices sooner or later the devices can get bad messages, that actually make sense, and then the devices can get scrambled. Garage door openers are notorious for producing noise. Link to comment
jec6613 Posted June 30, 2019 Share Posted June 30, 2019 22 minutes ago, larryllix said: Good work-around! When there is a lot of noise and things are programming or just operating Insteon devices sooner or later the devices can get bad messages, that actually make sense, and then the devices can get scrambled. Garage door openers are notorious for producing noise. That's why I have filterlincs all over my house. I picked up a pile of them with the 50% off sales. Link to comment
shbatm Posted June 30, 2019 Share Posted June 30, 2019 5 hours ago, Blackbird said: Trigger is not reversed. A while ago my door opened at 3am by itself. Since then I have the garage door opener plugged into a insteon outlet and the power is always off until I open the small door, then the power turns on for 5 min then shuts off again. Sorry if I was confusing--I was saying that even though my sensor setup is reversed and yours is not, I saw the same thing with the 3am query--except my sensor would turn OFF (normally ON with door closed). Simply calling a program that uses that sensor as the IF clause would get it to show up back "on" correctly. I didn't realize you had actually had the Garage Door go open! I like the hard-switch idea. Just curious, what controllers do you have tied to the opener--did something command the relay on when the sensor flipped, or did the relay flip by itself too? (Another issue I've had is the relay node, even though it's set up as only momentary, will stay "ON" and I have to have an ISY program turn it OFF after 5 seconds--may all be caused by noise-I just went the route of @jec6613 and bought a FilterLinc @ 50% off). Link to comment
Blackbird Posted June 30, 2019 Author Share Posted June 30, 2019 5 hours ago, shbatm said: Sorry if I was confusing--I was saying that even though my sensor setup is reversed and yours is not, I saw the same thing with the 3am query--except my sensor would turn OFF (normally ON with door closed). Simply calling a program that uses that sensor as the IF clause would get it to show up back "on" correctly. I didn't realize you had actually had the Garage Door go open! I like the hard-switch idea. Just curious, what controllers do you have tied to the opener--did something command the relay on when the sensor flipped, or did the relay flip by itself too? (Another issue I've had is the relay node, even though it's set up as only momentary, will stay "ON" and I have to have an ISY program turn it OFF after 5 seconds--may all be caused by noise-I just went the route of @jec6613 and bought a FilterLinc @ 50% off). The door didnt open this time. It was 2 years ago and I found out at 7am. Been open since 3am. I have nothing operating the door except the app. My 8 button keypad lights up if the door is open but does not control the door. I like having the power always off, just incase someone got my code they still wouldnt be able to open it. When i pull up to my garage i disarm ELK with the key fob and when the button is pushed then the power to the opener turns on then I open the door. Also I will never have the alarm go off by accident if I forgot to disarm before opening the door. Link to comment
beninsteon Posted July 1, 2019 Share Posted July 1, 2019 I would not use io lincs on any security sensitive application. They are susceptible to the all-on bug and can open the garage door when not desired. Happened to me and I've removed all io lincs from my installation. Additionally since io lincs are power line only there can be issues with status reporting as you're experiencing. Thus, I'm using my security system to monitor garage door status (still gets reported to isy via nodelink/EVL-4) and a global cache relay to trigger door (controllable by isy through network resources). Link to comment
Blackbird Posted July 1, 2019 Author Share Posted July 1, 2019 1 hour ago, beninsteon said: I would not use io lincs on any security sensitive application. They are susceptible to the all-on bug and can open the garage door when not desired. Happened to me and I've removed all io lincs from my installation. Additionally since io lincs are power line only there can be issues with status reporting as you're experiencing. Thus, I'm using my security system to monitor garage door status (still gets reported to isy via nodelink/EVL-4) and a global cache relay to trigger door (controllable by isy through network resources). If my power is always off, I'm no longer worried about the door opening Link to comment
larryllix Posted July 1, 2019 Share Posted July 1, 2019 2 hours ago, Blackbird said: If my power is always off, I'm no longer worried about the door opening I guess his point is the All-On bug would turn both of the units on and could open your garage door anyway. Link to comment
beninsteon Posted July 1, 2019 Share Posted July 1, 2019 The old appliancelincs have the same bug. I think the newer plug in switchlincs are ok. But the solution seems like a hack. What if you want to open your garage in a more conventional way? Link to comment
Blackbird Posted July 1, 2019 Author Share Posted July 1, 2019 39 minutes ago, beninsteon said: The old appliancelincs have the same bug. I think the newer plug in switchlincs are ok. But the solution seems like a hack. What if you want to open your garage in a more conventional way? As soon as I open the man door, the power turns on to the garage door then I simply push the button to open. Easy. Link to comment
jgcharlotte Posted July 1, 2019 Share Posted July 1, 2019 I don't know what it is with that 3 am query, but I have a receptacle that has turned on a number of times. It is powering a heater. I have an automatic 90 minute timeout on the heater for safety, but I don't like it just turning on randomly. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.