spage Posted February 12, 2010 Posted February 12, 2010 ISY-99 v2.7 I have about 10 v37 Outletlinks (OLLs) as part of my system. 6 of them control computer servers in two power strip arrangements. One power strip has 2 OLLs labelled A10-A11, the other 4 labelled B1-B4. All the OLLs respond correctly every time to commands without fail. I have a program called Query ALL that runs at 3am each day. When it runs it usually TURNS OFF A10 and B1. If I disable the program the OLLs do NOT turn off. I set another program to Monitor A10 and B1 and record when they turn off and it is at 3:00:06 each time so I know it is the query all that is doing it. My Questions: How on earth can a Query turn OFF a device? Why just the two that it picks? What significance does having the OLLs connected in a power strip arrangement have? (the other wall mounted OLLs are never affected) Why is it the first one in the strip that is affected? (the others in the strip have NEVER turned off by the Query All) Most Odd.... Assistance greatly appreciated.
ryarber Posted February 12, 2010 Posted February 12, 2010 Do you control the state of the OLL's via a program? I have times where a query will trigger a program that might turn on or off a device. For instance, if switch 1 is off, then turn OLL 1 off. Something like that. If a query determines a device state that will trigger a program to execute, then you can see this behavior.
Michel Kohanim Posted February 12, 2010 Posted February 12, 2010 hi spage, As ryarber suggests, I think there might be programs that might be causing this behavior. To test: 1. Click on My Programs 2. In the If section, put a condition that is always false ... this eliminates all the programs from running 3. Right mouse click on My Lighting and do a query If the programs are not the culprits, then the problem is the InLineLincs themselves. I've had this issue with both InLineLincs and SocketLincs (now obsolete) before where too much INSTEON traffic caused them to turn on/off randomly. With kind regards, Michel
spage Posted February 13, 2010 Author Posted February 13, 2010 Do you control the state of the OLL's via a program? I have times where a query will trigger a program that might turn on or off a device. For instance, if switch 1 is off, then turn OLL 1 off. Something like that. If a query determines a device state that will trigger a program to execute, then you can see this behavior. Yes the Query All is in a program it looks like this: IF Time is 3 am Set Scene "My Lighting" Query Else No Actions It is innocuous enough.... BUT it turns off those 2 OLLs most times it runs. I guess I don't really need to query the system every night - but the idea was that if I did that then the status' would be more likely right - I didn't want the ISY status to say ON when the device was OFF- perhaps that does not happen. With X10 you couldn't read the status at all and often the control program showed the wrong status...
Michel Kohanim Posted February 14, 2010 Posted February 14, 2010 Hi again, We still need to figure out why those devices are turning on during query. Were you able to disable all your programs and do a query again? With kind regards, Michel
spage Posted February 14, 2010 Author Posted February 14, 2010 Hi again, We still need to figure out why those devices are turning on during query. Were you able to disable all your programs and do a query again? With kind regards, Michel Yes, I was able to have ONLY the Query All program - all others deleted and the two OLLs turned off at 3:0:6. Most odd At the moment i have disabled the Query All and the OLLs have not turned off since. ...Steve
upstatemike Posted February 14, 2010 Posted February 14, 2010 I assume you have ruled out X-10 addresses? The query process generates a lot of traffic and there is a chance that the resulting noise could mimic an X-10 Off command for some address or "All Off" command for some house code. The reson it would only affect the first modules in each strip is that those modules might attenuate the noise enough to prevent similiar triggere in the downstream ones, even if the noise looks like an X-10 "All Off"
spage Posted February 14, 2010 Author Posted February 14, 2010 Ah. Great idea about why it is only the first one in the strip. They are all daisy chained and A10 and B1 are connected first. I am not running any X10 at all. This morning while replying to your post I manually ran the QueryAll and 6 seconds later A10 powered off. The two strips are connected to a UPS. The UPS also has an Access point to get communication to the ISY. The ISY is NOT connected to the UPS. I read the posts about that and indeed when I tried it it would not work hardly at all. Very unreliable. I have some filters from my X10 days. Would they help at all do you think? I can't connect them to the UPS outlets as I font have room. But they could plug into the always in side of A10 and B1 thanks so much for your interest. ...steve
upstatemike Posted February 14, 2010 Posted February 14, 2010 So what happens if you take the access point off of the ups and run the query? If the module still triggers it must be noise since no valid Insteon message should get through. If it does not then it was triggering from a valid Insteon signal passed through the Access Point and the problem would be in the ISY or PLM.
spage Posted February 15, 2010 Author Posted February 15, 2010 With the UPS access point unplugged there is NO communication to the two power strips at all - which is as expected. The problem only happens when I run the QueryALL program. So I don't think it is the PLM. It could be a bug in the ISY... which is why I reported it. Is there any detailed logging we can turn on? ...steve
Sub-Routine Posted February 15, 2010 Posted February 15, 2010 Hi Steve, You could use the Event Viewer on level 3 which will show all the communications between the PLM and the ISY. Rand With the UPS access point unplugged there is NO communication to the two power strips at all - which is as expected. The problem only happens when I run the QueryALL program. So I don't think it is the PLM. It could be a bug in the ISY... which is why I reported it. Is there any detailed logging we can turn on? ...steve
Recommended Posts
Archived
This topic is now archived and is closed to further replies.