apostolakisl

Checking the error log I see thousands of these with different port numbers but otherwise the same. The LAN ip of 192.168.1.8 is a DVR for my security cameras. I can't imagine how it could be connected to ISY. Fri 5/4/2012 3:21:32 "AM System -170001 [HTTP] 192.168.1.8:35072->80 " Fri 5/4/2012 3:21:32 "AM System -170001 0: GET-->/desc" Fri 5/4/2012 3:21:32 "AM System -170001 [HTTP] 192.168.1.8:35076->80 " Fri 5/4/2012 3:21:32 "AM System -170001 0: GET-->/desc" Fri 5/4/2012 3:23:03 "AM System -170001 [HTTP] 192.168.1.8:35086->80 " Fri 5/4/2012 3:23:03 "AM System -170001 0: GET-->/desc" Fri 5/4/2012 3:23:03 "AM System -170001 [HTTP] 192.168.1.8:35090->80 " Fri 5/4/2012 3:23:03 "AM System -170001 0: GET-->/desc" Fri 5/4/2012 3:24:30 "AM System -170001 [HTTP] 192.168.1.8:35100->80 " Fri 5/4/2012 3:24:30 "AM System -170001 0: GET-->/desc" Fri 5/4/2012 3:24:30 "AM System -170001 [HTTP] 192.168.1.8:35104->80 "

And assuming you want a true 3/4 way where all the switches control the device the same way, you need to set the ramp rate and on-level the same for local control and scene control. Click on the scene on the left side of the main screen, then click "apply changes to all devices" and set your on level/ramp rate where you want it. Then click on the first device listed under the scene in the tree on the left side of the screen. Click "copy scene attributes from . . " Then continue on and do that for each device in the scene.

I run my 994i and before that my 99i off of an ATX power supply that runs into a terminal block and distributes to about 10 devices. I forget the specs on the ATX supply but it is something like 20 amps on the 5v lead. Anyway, it works very well. I am going to assume that ISY has a voltage regulator. Typically voltage regulators step voltage down by converting some of the power to heat. So, it would be my assumption that using a high quality power supply that runs at the lowest voltage is your best bet since there would then be less heat. If your power supply isn't the best, then a higher voltage would be better. Cheapo power supplies aren't the greatest at maintaining voltage at higher amps and they also don't make the cleanest dc voltage either. But my bet is that ISY's power regulator cleans things up as well. But it wouldn't be able to fix a wimping out current/voltage situation from a cheapo power supply that is rated at 5v under the best of times.

You can put it in a folder that enables from 9pm for 2 hours as you had mentioned. You could also split it into two programs. The first program basically says If time is from 9pm for 2hours then enable program with the other stuff else disable program with the other stuff But having the program trigger every 10 minutes and run false isn't a problem for ISY.

Program 1 If Status 'Kitchen / Kitchen Fan-Light' is On Or Status 'Kitchen / Kitchen LEDs' is On Or Status 'Office / Office Fan' is On Or Status 'Office / Office Hutch Lights' is On Then Run program 2 then clause Else - No Actions - (To add one, press 'Action') Program 2 If No condition Then Disable Program 1 Wait 10 seconds Set 'Office / Office Desk Lamp' On Enable Program 1 Else - No Actions - (To add one, press 'Action') Program 3 If Status 'Kitchen / Kitchen Fan-Light' is On Or Status 'Kitchen / Kitchen LEDs' is On Or Status 'Office / Office Fan' is On Or Status 'Office / Office Hutch Lights' is On Then - No Actions - (To add one, press 'Action') Else - Enable program 1 - Stop program 2

How about this Program 1 If Status 'Kitchen / Kitchen Fan-Light' is On Or Status 'Kitchen / Kitchen LEDs' is On Or Status 'Office / Office Fan' is On Or Status 'Office / Office Hutch Lights' is On Then Run program 2 then clause Else - No Actions - (To add one, press 'Action') Program 2 If No condition Then Disable Program 1 Wait 10 seconds Set 'Office / Office Desk Lamp' On Enable Program 1 Else - No Actions - (To add one, press 'Action') Haven't tested it, but it should work

What Lee said plus a suggeston: When you name your variables, start all integer variables with an "i" and all state with an "s". This makes it easy while writing and trouble shooting your programs to know what you are dealing with. i.e. "iCountdown" "sCoundown"

ISY does get delayed as it executes commands, but I don't know how consistent it will be. You could try having it do some big mathematical formulas using variables and see if you can get a reproducable affect.

Or use a KPL to control multiple devices from the location.

Here is how I do it. This particular style accounts for all the different things someone could do to the light switch to make it not be off no matter what the starting condition is. It also beeps for the last minute warning you the light is about to go off. The program resets the timer if someone does anything to the switch no matter what the starting condition or the finishing condition (except off). If Control 'Alexis Room / Alexis BR-Overhead L' is switched On Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fast On Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fade Up Or Status 'Alexis Room / Alexis BR-Overhead L' is not Off Then Wait 29 minutes Repeat 60 times Set 'Alexis Room / Alexis BR-Overhead L' 14 (Beep Duration) Repeat 1 times Set 'Alexis Room / Alexis BR-Overhead L' Off Else - No Actions - (To add one, press 'Action') If you wanted "fast on" to not run the program then you would need a second program to cover all bases. First off, delete the line about fast on from this program. Then write a second program that says If Control 'Alexis Room / Alexis BR-Overhead L' is switched Fast On Then wait 1 second stop the first program Else - No Actions - (To add one, press 'Action') The second program is necessary in the event that someone fades down the light but stops short of "off". If you dropped the "status not off" line which would be necessary to have the "fast on" not activate the program, then you would have to add "fade down". But if someone faded down all the way to off, the program would run and 29 minutes later it would beep at you unnecessarily.

Check your log and see exactly what time it is comming on and if there is any other activity associated with it.

My first inclination would be to make sure you don't have another scene where the link is active. When you click on the device a membership tree will appear on the righthand side of the screen. Please look over all of those and be certain that none of those scenes are the reason for your problem. For example, if there were a scene that the kpl was a controller for and the switchlincs were responders to, then what you describe would be the case. So, click on the kpl, look at all scenes that are under controller, then click on the switchlinc, and see if any of the those scenes are showing under repsponder.

I have my system run a query at 3:45 am every day. Last night, at 3:46:08 my whole house music turned on, waking us from our sleep. This has happened before a couple of times in the past few years. I do not understand the cause. I use a KPL button "music" to run a program that turns the music on (it is a "status" program). The button is part of "Family room over mantle". My assumption is that ISY thought the button was off, ran the query and found it to be on, updated it's status which triggered the program. Below is the log starting with the query start through the end of it. First off, is my assumption correct, and secondly, how can I avoid this? I know I could change the button to "control" but I use my Elk to turn the button on/off so I need to use "status". Although, I just realized now I have the Elk module I can re-write the program into ISY (from Elk), so maybe I just solved my own problem, but nonetheless, I would still like to understand better how this happened. Also, I see that the log reports that all of the buttons are 100% on the family room over mantle kpl. This is not the case. I think they were all off when I went to bed, this morning only the music button was on. I can not guarantee that this button wasn't on when I went to bed since sometimes my wife turns the music off manually (despite me asking her not to). Also, the Java console indicated that ISY thought they were on, when I did a manual query this am, it fixed them to "off". It would appear that the kpl sent back a false status report of "on" for every button. Scene:My Lighting Status Query Thu 2012/04/05 03:45:00 AM Program Log Family Room / Family Rm-Over MantleLt L / Family Rm-Over MantlePart Status 100% Thu 2012/04/05 03:45:22 AM System Log Family Room / Family Rm-Over MantleLt L / Family Rm-Over MantleMusic Status 100% Thu 2012/04/05 03:45:22 AM System Log Family Room / Family Rm-Over MantleLt L / Family Rm-Over MantleD Xmas Status 100% Thu 2012/04/05 03:45:22 AM System Log Family Room / Family Rm-Over MantleLt L / Family Rm-Over MantleE Status 100% Thu 2012/04/05 03:45:22 AM System Log Family Room / Family Rm-Over MantleLt L / Family Rm-Over MantleF Status 100% Thu 2012/04/05 03:45:22 AM System Log Family Room / Family Rm-Over MantleLt L / Family Rm-Over MantleG Status 100% Thu 2012/04/05 03:45:22 AM System Log X10 A2 Thu 2012/04/05 03:45:36 AM Program Log X10 A2 Status Request (10) Thu 2012/04/05 03:45:36 AM Program Log X10 A3 Thu 2012/04/05 03:45:36 AM Program Log X10 A3 Status Request (10) Thu 2012/04/05 03:45:36 AM Program Log X10 A4 Thu 2012/04/05 03:45:36 AM Program Log X10 A4 Status Request (10) Thu 2012/04/05 03:45:36 AM Program Log X10 A6 Thu 2012/04/05 03:45:36 AM Program Log X10 A6 Status Request (10) Thu 2012/04/05 03:45:36 AM Program Log X10 A5 Thu 2012/04/05 03:45:36 AM Program Log X10 A5 Status Request (10) Thu 2012/04/05 03:45:36 AM Program Log X10 A6 Thu 2012/04/05 03:45:44 AM System Log X10 A6 Status = off (2) Thu 2012/04/05 03:45:45 AM System Log X10 A6 Thu 2012/04/05 03:45:45 AM System Log X10 A10 Thu 2012/04/05 03:45:47 AM Program Log X10 A10 Status Request (10) Thu 2012/04/05 03:45:47 AM Program Log Keypad Display Text ELK-TX Thu 2012/04/05 03:46:03 AM System Log Scene:Music On 255 Thu 2012/04/05 03:46:08 AM Program Log Kitchen / Kitchen Intercom-Puck L Status 73% Thu 2012/04/05 03:46:34 AM System Log Kitchen / Kitchen Micro-Puck Status 73% Thu 2012/04/05 03:46:34 AM System Log Kitchen / Kitchen Corner-Puck Status 73% Thu 2012/04/05 03:46:34 AM System Log Master Bedroom / Master-Keypad / Mstr Bed Key A Kitchen S Status 100% Thu 2012/04/05 03:46:34 AM System Log Kitchen / Kitchen-Barrell Hall Status 73% Thu 2012/04/05 03:46:34 AM System Log Foyer / Foyer @ Music-Barrel Hall L Status 73% Thu 2012/04/05 03:46:34 AM System Log Scene:Master keypad A On 255 Thu 2012/04/05 03:46:34 AM Program Log Scene:Master Keypad B On 255 Thu 2012/04/05 03:46:35 AM Program Log Scene:Master keypad A On 255 Thu 2012/04/05 03:46:35 AM Program Log Scene:Master Keypad B On 255 Thu 2012/04/05 03:46:35 AM Program Log Master Bedroom / Master-Keypad / Mstr Bed Key B all off Status 100% Thu 2012/04/05 03:46:35 AM System Log Master Bedroom / Master-Keypad / Mstr Bed Key B all off Status 0% Thu 2012/04/05 03:46:39 AM System Log Scene:All Off Off 0 Thu 2012/04/05 03:46:39 AM Program Log Scene:Christmas Scene Off 0 Thu 2012/04/05 03:46:39 AM Program Log Kitchen / Kitchen Intercom-Puck L Status 0% Thu 2012/04/05 03:46:39 AM System Log Kitchen / Kitchen Micro-Puck Status 0% Thu 2012/04/05 03:46:39 AM System Log Kitchen / Kitchen Corner-Puck Status 0% Thu 2012/04/05 03:46:39 AM System Log Kitchen / Kitchen-Barrell Hall Status 0% Thu 2012/04/05 03:46:39 AM System Log Foyer / Foyer @ Music-Barrel Hall L Status 0% Thu 2012/04/05 03:46:39 AM System Log Scene:Master keypad A On 255 Thu 2012/04/05 03:46:39 AM Program Log Scene:Master Keypad B On 255 Thu 2012/04/05 03:46:40 AM Program Log Scene:Master keypad A Off 0 Thu 2012/04/05 03:46:40 AM Program Log Scene:Master Keypad B Off 0 Thu 2012/04/05 03:46:41 AM Program Log Master Bedroom / Master-Keypad / Mstr Bed Key B all off Status 100% Thu 2012/04/05 03:46:41 AM System Log Master Bedroom / Master-Keypad / Mstr Bed Key A Kitchen S Status 0% Thu 2012/04/05 03:46:41 AM System Log Master Bedroom / Master-Keypad / Mstr Bed Key B all off Status 0% Thu 2012/04/05 03:46:42 AM System Log

From xx time to yy time programs only spontaneously run at the xx time and the yy time, BUT only if the folder is true AT THAT TIME. If the folder is false at xx and yy time, nothing happens. The then or else clause will not execute. So if the folder is false at xx or yy time, nothing happens and the program status does not change and the then or else clause do not run regardless if it is between those times or outside of those times. You should just skip using folder on/off status. Just put the conditions in the if clause of each of the program If time is from xx to yy and status vacation keypad link button is on Then do something Else do something else (or nothing). The above program will test the if clause at xx time, yy time, and every time the button status changes. This will always be followed by either the then or else executing. I think this is what you are looking for. Skip the folder conditions here, there are lots of ways using folder logic can be inaccurate, the above program can't be tricked.

I highly suspect the condition If Control '0F.15.D6.G - Secure Lights' is switched On is the problem. As Lee mentioned, you should use status for that condition. Meaning that whenever that kpl button is lit up (no matter how it got turned on) it will turn the folder true and the programs inside will run. Also, though, keep in mind that if you turn that button on after the "from" time has already passed, those programs will not run on their own. With a "from to" program they only spontaneously trigger at the from time and the to time. In between those times, you need some other trigger to cause it to run. For example: If Status '0F.15.D6.G - Secure Lights' is On Then Run program . .. (IF) In this way, if the switch is turned on, the program will evaluate the if clause and if indeed it is in between those times, the then clause executes. And a note: as Lee mentioned, using "control switched on" logic never evaluates to false. In fact none of the "control" conditions ever evaluate to false. They serve as a "trigger" to a "true" outcome only. In other words, their value is in triggering a program to run the "then" clause. The only time ISY pays any attention to an "if" clause containing a "control" statement is when it happens. In other words if you have "control switched on" as a condition, turning the switch off (or dimming it, or fast on, or fast off) is simply ignored. Turning the switch on cuases the if clause to evaluate (and assuming there is nothing else in the cluase that is false) it runs the "then" clause. Think of "control" commands as a way to trigger the if evaluation, not as a true/false controller.

Lee tells it pretty well, but just a littel extra tidbit, you can set the if clause to be from time a to b OR time c to d. . .and so on. The basic jist is that you can only have two temp settings in one program, but many time slots to be set to one or the other.

You can also do this from the scene itself. Go to the scene on your tree on the left and then click on the device sub-tree under it. Click "copy scene attricutes" button and it will make the "applied local" settings match the scene settings. Keep in mind that Insteon lets you do set your scenes up in a multitude of ways. 1) Pushing a button on a switch will always cause THAT SWITCH (and the load attached to it, if any) to do as is set for that switch as an individual. This means that it will ramp up at the rate specified to the on level specified for THAT SWITCH as a solo device. Any scene the switch is a part of is irrelevant. 2) If a switch is controller for a scene, it will trigger all THE OTHER devices in the scene to do as stipulated in the scene. Each device in the scene can have a unique ramp rate/on level or you can click the button "apply changes to all devices" and ISY will automatically set them all the same. 3) If a switch is a responder only to a scene, it will ramp rate/on level as directed in the scene when the scene is activated from whatever controller you have set (either another Insteon device or as part of an ISY program). Again, localy pressing that switch will make it behave as per the local settings for that switch. But, as a scene responder, locally pushing the switch will not trigger the scene.

I think you have something screwy with your switch. It should be quite challenging to push the air gap and I have never even come close to accidentally causing it to go in. I would talk to SH about that. Also, you might just pop your button covers off and make sure it is on straight and there isn't something in there that is pinching up against the air gap button.

After thinking about things, I recall having the light mis-behave the day before I upgraded. Then I remembered we had a thunderstorm the night before with a power failure. I watched the status of my lights on the ISY console. It was failing to track changes in most of my lights when applied locally. Queries worked instantly. I tried power cycling the ISY and the PLM and now it is tracking everything again. So, perhaps the ISY and/or the PLM got into some screwy mode during the power failure and a clean power cycle fixed it. ??? It does not appear to be the 3.2.1 upgrade I don't think. ALSO: One of my KPL's that used to glow at a low level when the buttons were off, now shuts the buttons down to black when off. This coincided with the other issues. I was only able to fix this with a factory reset.

I just downgraded to 3.1.17 and it is still doing it. I deleted the "home and away" stuff off of the somee.com server just in case it had something to do with it and that didn't fix it either. It is happening 100% of the time now, except, it never does it twice in a row. In other words, if I turn the light on to any level, then off, the program runs and it goes to 25%. If I turn it off from there, it does not run. Also, If after the program runs and it goes to 25%, I then ramp the light up to 100% and turn it off, it does not run. This is very frustrating!

After upgrading to 3.2.1 from 3.1.17 the "if status off and switched off" problem is back. About 50% of the time now when I turn off a light that is on, the program of this style incorrectly runs. If Status 'Alexis Room / Alexis Bath-Cans L' is Off And Control 'Alexis Room / Alexis Bath-Cans L' is switched Off Then Set 'Alexis Room / Alexis Bath-Cans L' 25% Else - No Actions - (To add one, press 'Action')

My install went just fine. I like the "=random". Can't you change all of them to something nice and self explanatory like that?

I haven't done any true testing of this, but I noticed one day that the outside temp was not showing on my Elk keypads. So I checked the program status and that program was not running. There are no mechanisms to make that program stop running once started except for a manual stop (which I didn't do), so I assumed it was a power failure with a failed "run at startup". There had been a power failure the day before. So I added the 1am for 24 hours line and yesterdays power failure rebooted with the program running, so I will just leave it alone.

Do you have a comment on why my program several posts above did not run after a power failure until I added the "if" clause stuff? My understanding is that if you have "run at startup" enabled with a blank "if" clause, it executes the "then" clause at startup. As it is currently written (as it is above), it does execute at startup. We had some big time thunderstorms last night and the power went out at some point during the night, and the program was running this am. I do not have the "catchup programs" checked, I have the grace period at 15 minutes.

True, if you were home, awake, and actually thought to go check it. But my bet is the "Perhaps it was just simpler, cheaper".