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

Larry- Change the Scene in the "In Scene" drop down to the Motion Sensor (Device) instead. As I said in my example - this is NOT intuitive at all. You need to select the controller (MS) as the scene rather than the Scene itself. What we are saying here is: when the scene is controlled by the MS, then the SLD should respond with xx OnLevel and XX ramp Rate. By selecting the Scene instead of the MS, you are only affecting the outcome when the ISY calls the scene, not the MS. See my second screenshot for an example. -Xathros

Now, back to our regularly scheduled topic... HOWTO: Disable a scene controlled by a motion sensor using Adjust Scene statement in ISY Purpose: To achieve an instant light response via motion trigger yet maintain programmatic control over timeout and ability to disable motion response. A Switchlinc Dimmer and an Insteon Motion Sensor both added as controllers of a scene called 'OfficeMotionLights' Motion sensor is configured: On Only, Sensing Mode, Night Mode Disabled. A program is in place to watch for motion sensed and then turn off the scene after a timeout (15 seconds for testing purposes). And, there is no load connected to the SLD so my office lights do not resemble a Disco while I'm working on this. If Control 'Office / Office Motion-Sensor' is switched On Then Wait 15 seconds Set Scene 'Office / Office MotionSLD' Off Else - No Actions - (To add one, press 'Action') When I trigger the motion sensor, the SLD turns on to 100%. 15 seconds after the last motion triggered, the SLD turns off. So far so good. Next to Enable/Disable the "Lights" on motion, I created another program: Program: OfficeMotionLightsEnable/Disable If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then In Scene 'Office / Office Motion-Sensor' Set 'Office / Office SLD' 0% (On Level) Else In Scene 'Office / Office Motion-Sensor' Set 'Office / Office SLD' 100% (On Level) Here is a screenshot for assistance on this one: Here is the critical and not very obvious part: I selected the Motion sensor as the Scene and set the SLD OnLevel to 0%. I don't want to adjust the Scene, but rather the controller of the scene here - the motion sensor. If I were to adjust the Scene instead, only the scene when controlled from the ISY is affected. This is where is is misleading in a big way. Motion Sensor is NOT a scene but rather a Device. It happens to be a Scene Controller. In fact, there is no scene called 'Office Motion Sensor'. By selecting the device 'Office Motion Sensor' in the "In Scene" drop down list, we are adjusting the responder link record in the SLD that matches the motion sensor's Insteon address. Now to test. I run Then on the Enable/Disable program then trigger motion. The event log shows the motion sensor activity but the SLD stays off. I manually turn on the SLD then move in front of the sensor again and the SLD turns off with the motion. Running else on the Enable/Disable program restores the previous behavior. Thats it in a nutshell. Let me know if you find this useful. -Xathros

I see a few others have chimed in on this already with basically the same answers I would have given. I use program (true/false) status as a control flag in some cases. Running the empty else section sets the program false when I need it to be. Mobilinc sees program status and I use that for feedback on certain items so some programs will set others false for feedback reasons. -Xathros

Yes. You could. Just another aspect to consider though. -Xathros

LeeG- Thanks. So then by utilizing an ISY scene to beep a device, rather than a direct command, I am reducing overall traffic by roughly 50% correct? -Xathros

I use the beep for three functions: 1) Single beep a scene with many devices whenever and exterior door opens. 2) 30 second countdown with a beep every second before an auto off timer expires in a few locations (single device scene) 3) Confirmation beep in places where I trigger a program with a FastOn, FastOff or Fade control. In general these all work just fine. Like others, i see variation in timing with a sequence of beeps. I attribute this to variations in comms quality / other traffic from motion sensors etc. I exclusively use scenes for the beep as I believe there is less traffic involved than when addressing a device directly. (Maybe LeeG can confirm or bust me bubble on that). I completely agree that a variable duration beep and blink capability should be built into certain devices (KPLs and Switchlincs and Toggleincs mostly). -Xathros

Hi smokegrub- I can say that I haven't. I also have 2 ISY's in different locations, power sources and internet connections. First, I don't believe the location or internet connection play into this at all. Power if noisy or unstable could certainly cause issues with Insteon devices. Can you describe in greater detail the failures and the need for a factory reset rather then a simple air gap restart of the devices? -Xathros

No problem. Happy to help. Just take it slow and careful and you shouldn't have much trouble getting everything swapped over. Don't delete the old one till you have the new one all programed. You can look at the old KPL nodes and see what they are controller and responders to as you go along. Fix up one scene at a time then recheck the old nodes to make sure you didn't miss anything. Careful use of search and replace in the programs should resolve everything there for you. -Xathros

There is a find/replace feature when editing programs. This will help a lot with the editing. As for the scenes, they will need to be documented then edited by hand. I suspect the new and old KPL's differ by type (dimmer vs relay) and thus, no replace with... option. -Xathros