kclenden

Thanks for being so concise. Very helpful. I didn't know about the STOP command. When it stops a programs, does it stop execution immediately (i.e. no other lines in either the IF or ELSE clause are executed)? What happens if you try to stop a program that isn't running? Can you tell in the "Summary" screen that a program ceased execution because it was stopped and not because it completed? I think rather than the folder option suggested by oberkc, which worked perfectly by the way, it would be clearer if I simply used the STOP command in my program that turns on the Christmas lights.

I stand corrected. My confusion was with the concept of stopping a program by self-triggering it. In reality the self-triggering doesn't really stop the program, it redirects its execution from the currently running WAIT command in the THEN section to the ELSE section which in my case has no lines to execute and thus allows the program to stop executing because it has run out of lines to execute.

That's what I thought, but disabling a program also prevents the IF condition from ever being reevaluated once the program has been externally triggered. There's nothing wrong with how UD has implemented the "enable/disable" option for programs. It just works differently than I originally thought. Thanks for all the suggestions. For various reasons, that aren't obvious because I left out other details, I had consciously not implemented many of them from the beginning. I'm going to try the folder idea oberkc suggested as it comes closest to matching the separation of duties structure that I have setup for my programs.

I've always thought that a WAIT command will terminate and the conditions in the IF will be reevaluated if any of the conditions in the IF change. Usually that is the case, but after a couple days of puzzling over why my programs didn't seem to be working as expected, I've learned that disabling a program does more than just prevent it from starting on its own. It also prevents the IF statement from being reevaluated during a WAIT. I turn my outside lights on around about sunset. Instead of having them always come on at sunset, I use the RANDOM option of WAIT to have them come on within 30 minutes of sunset. This means that from the time the ISY decides that the lights should be turned on, and they are actually turned on, as much as 30 minutes can elapse. During all but about 6 weeks of the year, this 30 minute dead time is of no consequence. But during Christmas time, I also have the ISY turn on Christmas lights after sunset and I don't want the outside lights to come on if the Christmas lights have been turned on during the dead time mentioned above. The program I use to initiate turning the outside lights on is this: Outside Lights-Random On - [iD 009F][Parent 0054][Not Enabled] If $sXmasLightsOn is 0 Then Wait 30 minutes (Random) Run Program 'Outside Lights-Manual' (Then Path) Else - No Actions - (To add one, press 'Action') I have the program DISABLED because I don't want it to run any time $sXmasLightsOn is 0, but only when another program specifically runs it at which point I want it to quit running if the outside lights are already on, or are turned on during the up to 30 minutes of waiting. The ISY program that turns on the Christmas lights sets $sXmasLightsOn to -1. If a program runs the IF portion of "Outside Lights-Random On" and $sXmasLightsOn is not 0, the ELSE runs and the program stops. If a program runs the IF portion of Outside Lights-Random On" and $sXmasLightsOn is 0 then the THEN runs and begins to wait. During the waiting, if $sXmasLightsOn changes from 0 to something else, the wait continues and ultimately executes the next line and the outside lights are turned on. If I re-enable the program, the WAIT works as expected and reacts to changes in $sXmasLightsOn but the program runs any time $sXmasLightsOn changes back to 0 which is behavior I don't want. If you're still with me, thanks. Here are my questions. Is disabling a program supposed to also disable the reevaluation aspect of the WAIT command? And is there a best practice for using WAIT in a program you want to begin execution only when commanded by another program? I could add another state variable, say sExecute, to keep the program from running unless I specifically command it to, but this seems like a lot of overhead, and I'd need a separate variable for each program that I both want to only run when commanded and uses a WAIT that needs to react to changes in the IF. Appreciate any suggestions.

Having to replace the ISY would seem to be one time that having the PLM as a separate module is a good thing. All of the Insteon device associations are with the PLM and not the ISY.

Are you sure you used UPW2G100MHD1TO instead of ESX106M400AH4AA? I ask because the capacitors that I got when I ordered UPW2G100MHD1TO are twice as tall, and twice as wide as the original 6.8 uF 250V capacitor. Though I could probably make the leads fit, there's no way I'd ever be able to get the casing closed.

M6, As 30+ year IT veteran your attitude about not moving to a Beta version of software to solve a problem makes complete sense to me. Only if the release notes, or the the company's support staff told me specifically that the Beta software solved the problem would I move to that version. Instead I would try to understand, using the current version, what was going on. I also have Micro Module Dimmers that, like others have reported, work correctly when programmed under Options. I'm using firmware 4.0.5. Have you tried watching the Event Viewer at Level 3 when trying to program your MMD's from the ISY? When I do that, I note a couple things. * First, when I open the "Options" box there is no communication between the ISY and the MMD. So whatever the dialog box shows as checked or not checked is simply coming from the ISY's memory not the MMD. * If you click a checkbox, say the "Latching" checkbox, there is immediate communication between the ISY and the MMD. The ISY does not wait for you to click "Done" to update the MMD. It does so immediately when you check or uncheck a box. You should try this to see if the changes you make in the "Options" box are actually making it from your ISY to your MMD.

Since removing the bulbs made the noise go away, I would try new bulbs. Or use some of the bulbs from your other outside lights that haven't caused a problem before. I have seen incandescent filaments, especially as they age, cause noise before. If new bulbs still cause noise, then as gatchel suggested, perhaps the electrical circuit for the problem switches runs through the attic near the antenna.

Phrasing the info from LeeG another way: WAIT works in conjunction with the IF statement. If the IF condition changes from TRUE to FALSE during the WAIT then the execution of the THEN halts. For this reason, people often break up the IF and WAIT into two separate programs. In your case when the IF was true the THEN would execute another program. The other program would not have an IF condition, but merely have Set 'Main Floor / Driveway Spot Lights' 100% followed by WAIT 10 minutes followed by Set 'Main Floor / Driveway Spot Lights' 50% in the THEN section. AND The ISY can execute other programs while transmitting commands but will not send out more Insteon commands while the powerline is busy. Your blinking of the outside lights is probably monopolizing the powerline so that any other program that is executed cannot send Insteon commands. Try creating a program that merely sets the value of a variable and run it while your blinking light program is running. I think the variable setting program will run, and you'll see the value of the variable change.

The only specific information that I know is stored in a device, but not reported or reset by the ISY is the X10 address of a device. That wouldn't account for the weirdness you were seeing, but could explain seemingly random on/off/dim done by devices. It certainly wouldn't surprise me if there was other non-visible information stored in devices. The consensus I've seen from the forum is that after installing a new device, the first thing you should do is to perform a "factory reset" on it, and then move on to adding it to the ISY.

What you say mostly makes sense, except at the boundaries, like device startup. The single program in the folder does execute when the keypad buttons are pressed, even after a reboot of the ISY. So let's step through it: [*:1qlysf8t]ISY is rebooted [*:1qlysf8t]The INIT values for both $iKeypad.Lock and $iAway.From.Home are 0, so both default to 0. [*:1qlysf8t]What is the value of the folder IF condition? Either it defaults to something, or it gets set to something upon first execution. [*:1qlysf8t]I press the "AWAY" button on the keypad and the button LED lights up [*:1qlysf8t]The SYNCH program runs and turns the LED light off. The program should not have run because $iKeypad.Lock is 0 (not -1). The fact that it ran means either the folder IF condition defaulted to TRUE or it was evaluated to be TRUE (which doesn't make sense) when the program IF condition was evaluated. Since it doesn't make sense for the folder IF condition to evaluate as TRUE, I'm going to assume that the folder condition defaults to TRUE and never actually gets evaluated because the condition does not contain any sort of STATE component. To me, it makes more sense for the condition of a folder to evaluated whenever one its programs is triggered by a state change. The program becomes a STATE trigger for the folder. It doesn't make sense that the folder IF condition would default to anything, TRUE or FALSE, and then just stay that way. I will try adding the keypad button change to the folder IF condition in addition to the check of iKeypad.Lock. If that fixes the issue then I can be pretty certain that the folder IF condition does indeed default to TRUE and never get evaluated.

Thanks Lee - that matches my understanding. What I had setup was a folder that merely used an integer variable to control whether the programs it contained are allowed to run, but not to actually trigger them. The programs themselves are triggered by keypad button CONTROL statements. Here is what I first tried: For simplicity sake, I created one program that uses both the THEN and ELSE segments like: Away Button Synch If ( Control 'FR-Keypad-Button A / FR-Keypad-Button E' is switched On Or Control 'FY-Keypad-Button A / FY-Keypad-Button E' is switched On Or Control 'KI-Keypad-Button A / KI-Keypad-Button E' is switched On ) And ( Control 'FR-Keypad-Button A / FR-Keypad-Button E' is not switched Off Or Control 'FY-Keypad-Button A / FY-Keypad-Button E' is not switched Off Or Control 'KI-Keypad-Button A / KI-Keypad-Button E' is not switched Off ) Then Set Scene 'Away Mode' Off Else Set Scene 'Away Mode' On This program runs when the keypad is locked and an attempt is made to change AWAY status. If the button LED is turned off, this will turn it back on, or if it is turned on, this will turn it back off. for the code above to function correctly, it must only run if the keypad is locked, so I added a condition to the folder containing the program like this: Folder Conditions for 'Keypad Button Synch' Add conditions to limit when programs in this folder are allowed to run. If $iKeypad.Lock is -1 Then Allow the programs in this folder to run. For some reason, even when $iKeypad.Lock is not -1, the program within it executes making it impossible to change the status of AWAY. To make it work, I took the condition off the folder, and created two programs: Away Off Button Synch If ( Control 'FR-Keypad-Button A / FR-Keypad-Button E' is switched On Or Control 'FY-Keypad-Button A / FY-Keypad-Button E' is switched On Or Control 'KI-Keypad-Button A / KI-Keypad-Button E' is switched On ) And $iKeypad.Lock is -1 And $iAway.From.Home is 0 Then Set Scene 'Away Mode' Off Else - No Actions - (To add one, press 'Action') This program runs when the keypad is locked and an attempt is made to turn AWAY on. The button on the keypad will light up so it must be turned back off. and Away On Button Synch If ( Control 'FR-Keypad-Button A / FR-Keypad-Button E' is switched Off Or Control 'FY-Keypad-Button A / FY-Keypad-Button E' is switched Off Or Control 'KI-Keypad-Button A / KI-Keypad-Button E' is switched Off ) And $iKeypad.Lock is -1 And $iAway.From.Home is -1 Then Set Scene 'Away Mode' On Else - No Actions - (To add one, press 'Action') This program runs when the keypad is locked and an attempt is made to turn AWAY off. The button on the keypad will shut off so it must be turned back on. I don't understand why my first attempt did not work. How often are the conditions of a folder evaluated to determine whether it's programs should run? Is it every time the conditions of the program itself are evaluated, or at some other interval?

Thanks. So I'll continue to use my solution that simply changes the LED state back to what it should be. This brings up another question... Has anyone else seen strange results when using integer variables as the condition controlling a folder? I have a variable called iAway.From.Home and if I use it as part of a program's IF condition it works correctly. However, if I put that program in a folder, and then I use the iAway.From.Home variable in the IF condition of the folder, I see programs running when they shouldn't.

I have an 8-button keypad. I'm using two of the buttons to control the state of the house. Specifically one button allows me to tell the ISY that I'll be away for a while, and the other button allows me to tell the ISY that I have guests. I have a third button that I'm using to "lock" the keypad so that someone doesn't accidentally turn off the "away" and/or "guest" buttons. I have successfully programmed the ISY to ignore pushes of the "away" and "guest" buttons when the "lock" button is ON. My problem is that I haven't been able to get the keypad to ignore pushes of the "away" and "guest" buttons when the "lock" button is ON. By that, I mean that if the "lock" and "away" buttons are ON, and I push the "away" button, the ISY still knows that "away" is active, but the "away" LED on the keypad shuts off. So, is there a way to program the keypad to not change a button's LED state based on the physical pushing of the button so that the LED only changes state based on ISY programs? Or must I create a program that monitors the button push, and sets the LED state according to the state of specific ISY variables (basically turning the LED back ON after the button push has turned it off)?

One thing to consider about the "variable" examples given above is that they don't account for something being on at say 20% and something being on 100% which would definitely impact power consumption. You could certainly address this with some additional programming. Another way you could track this is by simply using the ISY log. If you export it to Excel, you can sort by Insteon Device and Time. Then with some simple formulas you could arrive at a rough calculation based on the time differences between different states of the device. The added advantage of the Excel method is that you can use past data (everything accumulated in the log) and don't have to wait to accumulate new data.

Actually, variables can also contain negative integer values. I use -1 all the time because my formal computer training always represented TRUE with a -1.

gwarthur - I use a 2443-222 to control my bathroom light fixture and its local status is always communicated to the ISY. After installing it, I also used the "New Insteon Device" option to link it to the ISY. Not because the automatic linking didn't work, but just because I wanted to try the "New Device" option. So our setups should be pretty similar. Have you tried right-clicking on the device and choosing "Diagnostics->Show Device Links Table"? Then try clicking the "Compare" button to see if the device links table matches the ISY links table. If the ISY is not seeing the 2443-222 change states when it is manually switched, it seems like either you have a communication problem between the 2443 and the ISY, or the links table for the 2443 and the ISY are not correct.

I don't have a KeypadLinc, but couldn't you just pull the button cover, put some black electrician tape on the back of the cover, and then put the button cover back on?

If you have the PLM unplugged, and you're entering the MAC address (in lowercase as xx:xx:xx:xx:xx:xx) in both the userid and password fields, and you're still getting an "authentication error" message, then I'd conclude that you have the wrong MAC address. I use a program called Fing to find devices on my network. It shows their IP address and MAC address even if they have a static IP. Here's a blog post about it http://blogs.computerworld.com/19793/fi ... ur_network. It's free, so you might try using it to determine if you have the correct MAC address.

Make sure you have the PLM disconnected from the ISY. If it's connected, you'll get an authentication error. Make sure you enter the MAC address in lowercase. If you use uppercase, you'll get an authentication error.

I'm a newbie, but my guess is you need to use CONTROL instead of STATUS. CONTROL checks whether a button was pressed. STATUS checks whether a device is ON. I think your programs as written check whether the button light is ON or OFF and then turn the scene ON or OFF. Thus never changing the actual status. Of course when you change to CONTROL, then you'd need to add an AND to check if the STATUS is ON then in the THEN you could set the scene OFF and in the ELSE you could set the scene ON. With that I don't think you'd need the second program. Hmmm... Maybe you shouldn't get rid of the second program. If you do what I suggest, I reckon the ELSE is going to fire any time the button isn't pressed. So probably you just add the CONTROL statement to both of your program IF statements change the THEN statements to set the appropriate scene, and leave the ELSE portion blank in each. Can't wait till I get my 2313S so I can actually start programming.

Michel - thanks for the reply. I can understand why the ISY wouldn't let you add/delete/modify links and scenes while in "Safe Mode" since it can't update the PLM or Device tables, but why doesn't it let you add/delete/modify folders and programs? Do programs actually run while the ISY is in "Safe Mode"? I think I read somewhere else in the forum that the ZigBee version of the ISY doesn't enter "Safe Mode" when the PLM isn't present. Is that true? I tried the "Terms" link again, and it works now. Thanks.

I'm just a newbie, but based on what LeeG has previously written, aren't you missing a couple statements (show in red below)? And as to why the Family Room Light switch gives 100%, perhaps the ISY already thinks the level is set to 30% and thus doesn't actually change it? Maybe changing all the 30% to 35% would get it to change the values when the THEN is run, then you could change it back to 30%? If From 3:00:00PM To Sunrise - 1 hour (next day) Then In Scene 'Hardware / Family Room Light' Set 'Hardware / Family Room Light' 30% (On Level) In Scene 'Hardware / Family Room Light' Set 'Hardware / Family Room Light Slave' 30% (On Level) In Scene 'Hardware / Family Room Light Slave' Set 'Hardware / Family Room Light' 30% (On Level) In Scene 'Hardware / Family Room Light Slave' Set 'Hardware / Family Room Light Slave' 30% (On Level) In Scene 'Scenes / Family Room Lighting' Set 'Hardware / Family Room Light' 30% (On Level) In Scene 'Scenes / Family Room Lighting' Set 'Hardware / Family Room Light Slave' 30% (On Level) Else In Scene 'Hardware / Family Room Light' Set 'Hardware / Family Room Light' 100% (On Level) In Scene 'Hardware / Family Room Light' Set 'Hardware / Family Room Light Slave' 100% (On Level) In Scene 'Hardware / Family Room Light Slave' Set 'Hardware / Family Room Light Slave' 100% (On Level) In Scene 'Hardware / Family Room Light Slave' Set 'Hardware / Family Room Light' 100% (On Level) In Scene 'Scenes / Family Room Lighting' Set 'Hardware / Family Room Light Slave' 100% (On Level) In Scene 'Scenes / Family Room Lighting' Set 'Hardware / Family Room Light' 100% (On Level)

I just received an ISY-994i PRO: Model: ISY 994i 1024 Platform: ISY-C-994 Version: 3.3.10 Build Timestamp: 2013-01-17-01:13:50 It boots up in "Safe Mode" because I do not yet have a PLM. I've ordered a 2413S but it seems they are currently in short supply. So I figured that I would play around with the ISY-994i a little and get used to the programming while I wait on the PLM. I am able to create Variables, both static and integer and then save them. I am also able to update the Config settings like "Location". I am able to create new Folders and Programs, but when I try to save them I receive "[HTTP]]". I thought maybe the JAVA console would give me more information, but all it shows is "Error sending save program request: 'My Programs' id=1". So am I unable to save Folders and Programs because the ISY is in "Safe Mode"? Or will I still have this problem even after I receive a PLM? If "Safe Mode" is the culprit here, what else does "Safe Mode" restrict? By the way, if someone from UD happens to read this, when I first went into the "Admin Console", it wouldn't let me proceed until I agreed to the "Terms". The problem is when you click on the "Read" button to actually read the terms, it takes you to "http://www.universal-devices.com/prod-disclaimer.pdf" which throws a 404 - page not found error. So where do I find the terms that I've agreed to? Thanks for reading and any suggestions.