kclenden

The white-on-green "10011" icon indicates that the ISY has information to write to those devices. You should try right-clicking them and choosing "Write Updates to Device".

You didn't mention how old your PLM is, nor how old it was when this started happening. If the answer is 2+ years, then that combined with your symptoms really point the finger at a dying PLM.

If I remember correctly, when I wired up my Fanlinc, the old wiring was setup with a switch that controlled power to the fan and the pull switches on the fan controlled the motor and light. So I didn't have an option to wire the fan light to the keypad switch. Are you sure your load wire is just supplying power to the fan light and not the whole fan? If it is just supplying power to the light, I'd probably use the red load wire to control the fan light since direct switch control is going to be a smidge more reliable than Insteon traffic when operated locally than a scene, but in actual practice I doubt it matters.

But how do you get the value into the programs? When I enter "12.10", it puts "12.1" into the program.

I liked your idea for using two decimal places for looks until I saw what the ISY does with far right zeros (hint - same thing it does with far left zeros). So the 10th, 20th or 30th of a month ends up as MM.D. Should still work correctly but not as pretty.

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.