Xathros

That was actually mountainman3520 but I can post some examples as well if needed. Variables add a layer of complexity but add so much flexibility that it is well worth it. And as mountainman said above, The ISY makes it pretty easy to deal with. -Xathros

Maybe it is set with a REALLLLLLY long ramp rate? -Xathros

Hello mountainman3520- Many of us us the same approach as you have. It does make things more flexible. -Xathros

In the above program, the if contains " Status 'Main: Basement Control' is not Off". The first step in the Then says "Set Scene 'Scene: Basement 3Way' On" . Since this scene contains "Main: Basement Control" and that device now has a Status of On, the If is re-evaluated during the 2 second wait and the program runs false (Else). Nothing after the first On command is executed. Breaking it up as follows: Original Program If Status 'Main: Basement Control' is not Off And Control 'Main: Trigger Drive-Opened' is switched On Then Run Program BasementFlashLeaveOn Then Path Else - No Actions - (To add one, press 'Action') New Program: BasementFlashLeaveOn If Then Set Scene 'Scene: Basement 3Way' On Wait 2 seconds Set Scene 'Scene: Basement 3Way' Off Wait 2 seconds Set Scene 'Scene: Basement 3Way' On Wait 2 seconds Set Scene 'Scene: Basement 3Way' Off Wait 2 seconds Set Scene 'Scene: Basement 3Way' On Else - No Actions - (To add one, press 'Action') Now the first program triggers if the basement is on and someone trips the driveway sensor. It calls the second program that has nothing in the If section. The second program runs the flash and is is not interrupted by the if re-evaluating because it has no If section to re-evaluate and nothing to re-trigger it. Make sense? -Xathros

Some additional thoughts on Status Vs Control: Battery powered Controller Only Devices (TriggerLinc, MotionSensor, RemoteLinc etc) don't really have statuses as they are not queryable. Their status is assumed by the ISY based on the last Control event received from them. As a result, the ISY will show the status of these as blank until a control event is received from them. Responder only devices (IOLinc Relay Node, Appliancelinc, possibly the Outletlinc) CANNOT generate Control events as they are not controllers. -Xathros

The difference between Control and Status is that Status will trigger anytime the Status of a device changes (On, Off, Brighten, Dim, Main Mode Heat, Cool etc) by either changing it at the device or via scene or program or linked device. Control on the other hand will only trigger when the device itself is manually controlled (KPL Button presses, Switchlink Paddle presses, Trigerlinc triggered by door opening). If you turn o a device with a scene or linked device, the target device does NOT generate a control message. Status=100% is the same as Status=On. This was changed not too long ago to avoid confusion with dimmer type devices. Before a dimmer at 50% would not be "On" in a status test. Only 100% would = Status On. Removing the On from the status test forces us to specify the onlevel and avoids that confusion. -Xathros

Actually, I think only "Main: Basement Control" would be an issue there as the driveway trigger is watching for Control rather than Status and turning on/off a Scene does not generate a control event. Solution: break the program into 2 programs. Move the then section of the above program to a second program and call it from the then of the first. This way when the If in the first program reevaluates, the second program is unaffected. -Xathros

I think you still need the "FKPL B is Off" in the programs too. Having it in the folder only will enable the programs when the Buttons turns off but won't trigger them. What this means is the Setpoint wont change when you turn the button off until the next timeframe trigger. Including the KPL test i the programs will Enable the folder and trigger the programs when the button is turned off. In this case, it probably makes more sense to remove the folder condition unless you plan to have other Home only programs in there. -Xathros

Clarance- The integer (or State) variables do not maintain their values through a restart or power loss. You can fix this however by updating the Init value anytime you changes a variable's value. $i.myinegerMvar =+1 $i.myintegerMvar Init to $i.myintegerMvar The "Init To" sets the "Initial value" that the mvar will have on startup. Otherwise the mvar will be initialized to whatever you devined when you created the mvar (0 is the default). -Xathros

First thing I would try is Right click the primary node of the KPL and select query Insteon engine. Then try setting a different set of values (3 Off 15 On) and see if it works. If not then I'd try a factory reset on the KPL and a restore device. Test again. -Xathros

That one wins the prize! Thanks LeeG. -Xathros

I've been quite happy with my Venstar+Insteon Adapter for the last 2.5 years. Smarthome voluntarily recalled and replaced replaced my Insteon adapter last year even though I hadn't had any problems with it. -Xathros

Or, at 12:01am set a variable to 0. Everytime the door opens, set the variable to 1. At 11:59pm check the variable and alert if it is at 0. If it is as busy as you say, you could probably move the test and alert up to Noon or earlier for quicker response and a time of day when you would be more likely to run and replace a battery. -Xathros

I only use a scene to control the KPL buttons - not the IOLincs. I have 3 8 button KPL's and 2 garage doors. I have created 2 scenes. The first contains all of the G buttons as responders the second contains all of the H buttons as responders. All of the G&H buttons are in NonToggle-On mode. I have door actuator programs that watch for a Control On coming from any of those KPL buttons and respond by Turning On then Off the appropriate IOLinc. The IOLincs are in MomentaryA (I believe but will have to double check that). The Off is simply to clear the relay On status in the ISY and has no functional value for me. I use a Mobilinc Favorite to "RunThen" of the appropriate garage door program. This does a nice toggle Open/Close. I have another set of programs that watch the IOLinc sensor and set the KPL G&H scenes based on the sensor status. I have a few more programs that are called by the door actuator programs and if the door is open when called, will wait for 20 seconds then send me an alert if the IOLinc sensor shows that the door has not closed. I have another thread: http://forum.universal-devices.com/viewtopic.php?p=87673#p87673 on the Mobilinc aspects of this that includes some of my programs and configurations. -Xathros

If you turn the relay back off with a program, the ISY status will update accordingly and Mobilinc will see that as well. That way, your next press in Mobilinc will be an On. I use mobilinc to run a program that does the IOLinc On-Off and KPL scene activations for me. -Xathros

Hi Jerry- I believe this is the normal behavior of th IOLinc module. In momentary mode, the ISY turns the relay on (and sets the status as On) then the IOLink turns the relay off after the preset timeout period. Since the relay node of the IOLinc is a responder only, no message is sent out to update the ISY's status. This is really not an issue as it doesn't affect the operation of the IOLinc. If you prefer to see the relay node as Off, as do I, you can add a "Wait 5 seconds" after you set the relay On and set it back off (which will only update the status as reflected by the ISY). -Xathros

Exactly! -Xath

Yes! As long as all of your thermostat programs include a From-to time range AND the KPL-Button status in the If section. What happens when you toggle the KPL button On or Off is every enabled program that includes the status of that button in it's IF section is triggered and evaluated. When turning off the KPL-G "Away" button, the single Thermostat-Away program is triggered and runs false (else) since the button is now off. All of the other Home Thermostat programs trigger most run false because you are outside of their time range and one will run true because you are inside it's time range AND KPL-G is Off. It is important to note based on you above comments that while the Away mode button is on, the Stat will stay set at 62 for however long the button is on-. Hours, Days ... Years, does not matter. The other (home) programs will still trigger at their start and end times but will all run false until the KPL button is turned off. I do something similar but my house has three modes: Occupied, Vacant and Away. Occupied = Your Home mode. Vacant I suspect = your Away and Away for me means for an extended period (Vacation, weekend away etc). Vacant locks my doors, sets back HVAC to moderate levels, enables security cams. Away sets back the HVAC further (keep pipes from freezing/fish from boiling), locks doors, enables security cams AND runs some randomized lighting to simulate occupancy during the evening/night. My Occupancy/Vacant status is automated - Away is set via program from my iPhone. -Xathros

Thanks for the complement Lee! JSP0511- It sounded to me like you wanted your thermostat to be at 62 for the duration of the "Away mode". If that is the case, then you will only need one extra program (as I posted above) to handle the stat while your away. If you want multiple timed set points while away, then that may require more programs. You can either build those programs to include the status of the "Away" KPL button as I did or you can create 2 program folders (One for away and the other for home) and set folder conditions based on the KPL button status ("If Status KPL-G is On" for the Away folder and "If Status KPL-G is Off" for the Home folder). The second approach (folders) may be cleaner if you are going to have a bunch of different setpoints / times of day while in away mode. Either approach will net the same functional results. -Xathros

Using one of your programs as a basis - modify the rest as follows: Week Day- If On Mon, Tue, Wed, Thu, Fri From 7:01:00AM To 3:30:00PM (same day) And Status 'Main Floor / Thermostat / Thermostat - Main' is Mode Heat And Status KPL-G is Off Then Set 'Main Floor / Thermostat / Thermostat - Main' 57° (Heat Setpoint) Else - No Actions - (To add one, press 'Action') Then add some away programs: Away-Thermostat- If Status 'Main Floor / Thermostat / Thermostat - Main' is Mode Heat And Status KPL-G is On Then Set 'Main Floor / Thermostat / Thermostat - Main' 62° (Heat Setpoint) Else - No Actions - (To add one, press 'Action') Away-Lighting: If Status KPL-G is On And Time is From Sunset +1 hour To Sunrise -1 hour (Next Day) Then Set scene Foyer Light On Else Set Scene Foyer Light Off -Xathros

Sorry, thats all I have for ideas on this one. Will have to wait for Michel. -Xathros

Look behind the applet window. Is there an ISY finder window? If so, use that to add the IP address of your ISY then connect from there. -Xathros

LeeG- Based on your previous findings, that is pretty much what I expected. Although, I would have expected the single query duplicate to be marked as such. I wonder if the PLM sees things differently if one ACK arrives on the powerline and another arrives via RF. -Xathros

I do understand the limitation. I highly suspect that this wasn't a problem before the advent of Dualband devices. It was when I added my 2 Fanlincs that I started noticing double responses to various events. (Motion detectors triggering twice in the same second, RL2 buttons registering twice etc). I don't see any way to resolve this beyond a delay to allow the duplicates to pass. I wonder if UDI could either insert delays between queries to the nodes of multi-node devices or shuffle the order of queries such that no two nodes of the same device are queried in sequence in the 3am query. -Xathros

I wonder if the same conditions can be detected with other multi-node queryable items like KPLs or Fanlincs. Really seems like a design flaw in insteon not carrying a node id in the ACK message. -Xathros