kclenden

If you have a smartphone, you could install the free Fing app (https://www.fing.io/). It will map the network that your phone is connected to and show you information about all the connected devices. The map it builds is much more complete than most router's "connected devices" screen.

I think to get feedback you're going to need to post the programs that you've setup to accomplish this goal. Or, at the very least, describe the basics of what you have setup (e.g. 1-a program with 2 dozen OR elements checks to see if the status of a device is ON and changes a state variable from 0 to 1 when one or more is; 2-a program monitors that state variable and if it is a 1 the KPL button is lit; 3-another program monitors the KPL button and if it is switched off a scene with 2 dozen devices is turned off and the state variable is set to 0). If you give that kind of information, people will be able to give you feedback.

I'm not running V5, so don't know the answer but would find it hard to believe that the ISY would need an internet connection to access system variables. I'd be more likely to believe the program didn't actually run. You don't have the program disabled, do you? Or have it residing in a folder with a condition that would prevent it from running? What's the program's "Last Run Time" listed in the Admin Console? What's its "Status" listed in the Admin Console?

Wow! Almost two years, and you still wrote a followup. I wish everyone would do that. From my reading of the forum over the years, it seems that there are no guarantees about the order statements execute within a program unless you use overt WAIT instructions. Especially if you're launching programs right after each other. It also seems to be true when it comes to setting variables and evaluating those same variables (you have to guard against race conditions). Edit: To be more precise, it's not that lines in a program aren't executed sequentially, it's that some of them are not atomic (i.e. the line that runs another program completes when the other program is queued to run, not when the other program actually starts running). So if two non-atomic commands execute one after the other, there's no guarantee which will actually get to complete first. One more edit to add a link to a discussion about the atomic nature of the THEN clause in which apostolakisl talks about having done experiments with math equations dependent on order of execution and not always getting the same results: https://forum.universal-devices.com/topic/22557-are-a-series-of-statments-within-a-then-clause-still-atomic/?tab=comments#comment-220515

You can create a third program that checks in the IF whether the switch is switched off. In the THEN portion of the program STOP Deck 2. That will cancel the WAIT because the whole program is stopped. You could also set the switch off in the THEN but shouldn't have to because the only way the third program gets run is if the switch has been switched off.

Just reread you opening paragraph. What if you changed to something like "And NOT 'ZW 003 Multilevel Switch' is switched Off"? That should evaluate as TRUE all the time except when the switch is actually turned off, at which time the WAIT 10 MINUTES should be broken, the IF reevaluated and then the ELSE executed. But you'd still need to add "Set 'ZW 003 Multilevel Switch' Off" after the WAIT because when the time limit of the WAIT expires the programs just stops, it doesn't automatically execute the ELSE.

Well nix that. You're changing the state of the switch in the program so that would cause the IF to reevaluate immediately and the run the ELSE. But still I don't understand what you're trying to accomplish with evaluating whether the switch is switched OFF.

I haven't used V5 yet, but in V4 you choose CONTROL or STATUS for switches. CONTROL means the physical act of the being switched OFF or ON. STATUS means the current state of the switch. It looks like you have used CONTROL so it will only be true at the instant someone turns the switch OFF. I think you want to use STATUS which will be true any time the switch is in an OFF state. Also, in an earlier program you were using a variable. Have you read about the difference between STATE and INTEGER variables. Which type you choose can have a huge impact on how your IF functions.

I'm running 4.3.26 and have seen AA mismatches (where they appear in the device table but not the ISY table). I just tried restoring one of those, not because I'm experiencing any problems, but to see if it would result in an AA record in the ISY table, but it did not. Before: After: If I understand linking correctly, when you look at the Before links, the first link (A2 00) says that the device, in this case a switchlinc, is a responder to the PLM. This allows the ISY to query the status of the device, via the PLM, at any time. The second link (E2 01) says the device is a controller for the PLM. This means whenever the device is used it will send its status to the PLM which allows the ISY to always know the status of the device. When you add a device to your ISY, it will always create those two links. The third link (A2 11) in my Before, says that the device is a responder in my "ALL Off" scene. The fourth link (AA 00) shows up as a mismatch between the device table and the ISY table. It would appear to indicate that the device is a responder to the PLM with smarthops set to 1. It seems to duplicate the purpose of the first link (A2 00) but with "broadcast for cleanup" activated. I guess it gets created whenever the device is activated and encounters transmission errors while communicating with the PLM. If it does duplicate the purpose of the (A2 00) link, I don't know why the device didn't just update the (A2 00) link instead of creating a new one. Of course none of this explains why the AA record sometimes appears in the ISY link table. Edited: to add my linking understanding, or lack there of.

I don't know. Perhaps in V5, ISY has implemented new code that captures the Smarthops bit when doing a restore so that the device doesn't have to recalculate them. Perhaps the OP can shed some light on this by telling us whether AA appears in any ISY link tables that haven't been involved in a restore operation.

LeeG has addressed this particular issue multiple times over the last couple years. Here's a link to one such time https://forum.universal-devices.com/topic/18122-links-table-record-mismatches-keep-reappearing/?hl=record#entry166265 Search for "Link Table" with LeeG as the author if you want to see others. To summarize, the E2, A2, and AA that you see in the Link Table are part of the Record Control Info. The Record Control Info is one byte that breaks out as: Bit 7: Active Bit 6: Controls Me Bit 5: 1 Bit 4: Smarthop Bit 3: Smarthop Bit 2: 0 Bit 1: High Water Bit 0: 0 The two Smarthop bits are manipulated by the device as it learns about how well messages travel over your Insteon network. They start at 00 and ratchet up to 11. So an A2 record has the two Smarthop bits set at 00, while an AA record has them set at 01. Likewise an E2 record could become an EA record if the Smarthop bits change from 00 to 01. The key here is that if the device changes the Smarthops value, it doesn't tell the ISY. So when looking at the link table, an A2, AA, B2, and BA all mean essentially the same thing except that the Smarthops go from 00 to 01 to 10 to 11. Same for an E2, EA, F2 and FA record.

The "Outside Lights-Random On" is run by a sunset triggered program. There are other programs that turn on the outside lights as well. One is linked to a keypad button and turns them on immediately. Another is linked to a motion detector and, like the original program, turns them on a random amount of time (0-10 seconds) after motion is detected. Another is linked to an Open/Close switch and turns them on immediately when a garage door is opened. Actually, in all cases, the programs don't actually command the outside lights on. Instead they set state variables and there are a couple programs triggered by those state variables to turn on specific scenes that include the outside lights. Normally, when the lights are commanded on they come on at 35%. If the motion detector or open/close sensor trips, they are command to full brightness for a random number of seconds and then return to 35% (unless they aren't on, like during the day, in which case nothing happens).

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.

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)?