Xathros

Because his error was: /conf/net/6.res -Xathros Sent from my iPhone using Tapatalk

Excellent. Thanks for posting back. -Xathros Sent from my iPhone using Tapatalk

Problems like this often turn out to be a corrupted file on the SD card. Do you have the network module? If so, delete and recreate resource #6 and then try to backup again. -Xathros

The only one that I can think of is eKeypad. -Xathros EDIT: Nevermind. Thats not it. It's Home Automation Pro. Sent from my iPhone using Tapatalk

I see a problem with this. Let's say it's just after sunset and you arrive home, open the door, pull in and close the door. I bet the lights stay on rather than turn off in 5 minutes. This is because the status of the sensor changes to Off when the door closes, re-triggering the program and running Else before the 5 minute wait can timeout. Change 'Status' to 'Control' and then it should work as intended. Additionally, you may want to add "Set Scene 'Garage' Off" to the Else section to force the lights off in the case where sunrise might occur during the 5 minute wait. Hope this helps. -Xathros

I think I understand what you mean but let me make sure- When you say devices A,B,C and D you are referring to thinks other than KPL buttons such as Switchlincs or Outletlincs correct? In addition, for each of those devices, you have assigned a KPL button to display they're individual status. Correct? If both of my questions above are correct then all you need to do is include the additional KPL buttons in the scene that the initial Non-Toggle Off KPL Button is controlling. Add them as responders. -Xathros

In this case, the one sample trace shows good comms between the IOLinc and PLM though that one brief trace is not really enough to says all is good there without question. If the relay was off then and given Lee's response above, I find a false status message to be unlikely. Not sure where else to go with this now. Keep an eye on it and lets see if there is any pattern to the problem if it happens again. -Xathros

Can you clarify this a bit for me? When you press a button to turn the devices off, is it the button that you presses that remains On? If so, then the button is NOT in non-toggle Off mode. A button in non-toggle Off will blink twice then go off after being pressed. If the button(s) that is/are staying on are on a different KPL, then you will need to include them in the scene that you are turning off as responders. -Xathros

Another thought and maybe @LeeG can chime in on this, some multi-node devices when queried report the status for the multiple nodes and a duplicate message from one node can be mistaken as status for a a defferent node by the ISY. If your IOLinc relay was on when it was queried, it may be possible that the ISY mistook a duplicate on status message from the relay as the sensor status. I have heard of this happening with the EZIO devices and I vaguely remember a thread where this happened with an IOLinc in a garage door application. Do you know what the relay status should have been with the false sensor On occurred? -Xathros

The proximity of the sensor ON to the 3AM query makes me wonder about the IOLinc trigger reverse option. If Trigger reverse is enabled, this would explain the behavior. As LeeG reported above, Trigger reverse reverses the sensor commands when the sensor state changes but does not reverse the sensor when queried. This has the effect of changing the sensor state in the ISY when the 3Am query runs. Can you verify that Trigger Reverse is not checked in the IOLinc options? -Xathros

I feel your pain. Things never seem to fail at convenient times here either. Another remote possibility is a phantom on message received by the PLM similar to the dreaded ALL ON or random scene On events that some have seen. While unlikely, this could explain the unexpected sensor On state reflected by your ISY. Following that train of thought, maybe you could post your PLM's hardware (Sticker) and firmware (from the ISY) versions for comparison with other known problematic PLM versions. It seems to me that the more RF insteon traffic in any one install, the greater the chance for corrupted insteon messages to mess things up. This is just gut feeling but I suspect it is shared by others here. Anyway, no rush. Whenever you are ready to troubleshoot this, I and others here and at UDI stand ready to help. Do what you can in the interim to document the issues and save logs and error logs that reflect the problems as they may prove quite valuable in determining the root cause when we do get to work on this. -Xathros

I have found that the addition of the BE469 and the FE599's has helped with getting the doors to fully close in my case. The added mass of these locks helps carry the door to the fully closed position. I have had a few instances when the 469 reported a JAM from the door not fully closing but compared to the number of times I found the door partially closed before these locks were installed, thats a big improvement coupled with notification of failure. The bolt on the 469 appears to be slightly tapered as well which when properly adjusted, helps pull the door tight against the weather seal. -Xathros

EricK- My suggestion was that the ISY did not hear the message last time the sensor turned off, not that the sensor was actually on. All of the evidence you have provided so far indicates that the sensor was off but the ISY believed it was still on. This makes me think there may be some comm issues between the IOLinc and the PLM location. The sensor must have sent the off message as the KPL button status was correctly updated. Does the new power strip share a circuit with either the PLM or IOLinc? If so, then this could very well be the issue and could likely be resolved by adding a filterlinc or relocating that strip to another circuit if possible. It may be worth running the event viewer test a few times both with and without that strip plugged in to see if there is a noticeable change in comm quality with.without the strip. -Xathros

Always happy to help. Re: The IOLinc sensor, if you know when it should have turned OFF, check your log for that off message. It's possible that it got missed leaving the ISY thinking the sensor was on. Try running a few tests with the event viewer running at level 3, query the IOLinc and see what the event viewer shows for Max/Remaining hops. This should give an indication of comm quality between the PLM and the IOLinc. -Xathros

I've had my 469 for 6-8 months now and am planning on a second one soon. I also use the FE599 (4 of those installed) and will be adding another of those as well. The FE599's get the most use and I've replaced batteries on one of them already. Two are currently between 40 - 50% and still running fine. Don't remember what the fail point was on the first one but will record that going forward. My BE469 motor runs on avg 6 times daily and it still at 86% on the stock batteries. -Xathros

Excellent. Glad we could help. -Xathros

If this program is DISABLED and only called by your Geofence program then you should be OK. Otherwise, if this is enabled, I suspect you may have trouble opening your garage door as this will want to close the door as soon as it opens. -Xathros

EricK- Anything notable in either the Log or Error Log around the affected times? -Xathros

Thanks Lee. That is what I meant -Xathros

You bet. Since the secondary buttons on the KPL (A-D) are not directly addressable like a switchlinc or the main On/Off buttons on the KPL, they need to be controlled by a scene. Create a new scene called ROG_KPL_A and place the KPL-A button in it as a responder. You don't need to put anything else in this scene. Then modify you program as follows: If Status 'ROG Other KPL / ROG Other KPL A (Bedtime)' is On Then Set 'Chandelier (Upstairs)' On Set 'Mom's Bedroom KPL / Mom's Bedroom KPL 1 (Light)' On Wait 5 minutes Set 'Chandelier (Upstairs)' Off Set 'ROG_KPL_A' Off Else Set 'Chandelier (Upstairs)' Off Set 'ROG_KPL_A' Off Notice the last line in both the Then and Else sections. That should do it or you. Hope this helps. -Xathros

Hi EricK- Can you describe the conditions on the programs that didn't run? Are they in folders with conditions and if so, what are the conditions on the folder(s). I have never seen the ISY miss running a time based program unless there was a power loss or another unmet condition in the program or enclosing folder. -Xathros

Are all of the failures with notifications? If so, this could be an issue with notifications not sending rather than programs not running. Check your error log around the times these notifications were to be sent for any errors. -Xathros

Smokegrub- If this is a 6 button KPL, the KPL-A is a secondary button and would need to be controlled by a scene. Create a new scene and make the KPL-A button a responder. Then in your program, also turn off that new scene. -Xathros

If the features you are referring to are the ZWave capabilities, then no, you would need to purchase the $99 Zwave add-on board (goes inside your existing 994) and the $1 software module to make that work. Depending on what you have now, you may also need to upgrade the firmware. -Xathros

Thanks LeeG. As always, your insight on these things is invaluable. My example scene contains only a sensor and a single SLD. I was trying to keep it simple to make it as understandable as possible. As you point out above, if there are more responders in a scene, that would require additional Adjust scene statements with those responders as the target devices. Based on the OP's and Others goals in this thread, we weren't concerned with how the scene would react from controllers other than the motion sensor so I limited my example to only that function. -Xathros