kclenden

As Larry said, with these two programs you have setup a notification loop that begins when the temperature reaches 80 or lower and then keeps occurring every 15 minutes (plus the time it takes for the temperature to change by a degree). Not to mention that the temperature is probably never going to get up to 94 because you always turn the AC back on 15 minutes after the temperature got to 80. Why not have something like: Temp too Hot If Status 'Thermostat - Main' >= 94 (Temperature) Then Set 'Outlet-AC' On Send Notification to 'Yahoo' content 'AC ON Message' Enable Program 'Temp too Cold' Disable Program 'Temp too Hot' Else Temp too Cold If Status 'Thermostat - Main' <= 80 (Temperature) Then Set 'Outlet-AC' Off Send Notification to 'Yahoo' content 'AC Off Message' Enable Program 'Temp too Hot' Disable Program 'Temp too Cold' Else

Your programs look fine to me. If you hit the switch, then under the "Summary" screen you should see that "Garage Motion Timer" or "Laundryroom Timer" is "Running 'Then'" under the Activity column. When the lights go out 1 or 2 minutes later, are "Garage Motion Timer" and/or "Laundryroom Timer" still "Running 'Then'"? If so, then something else is turning the lights out. Either another program, or a link between the motion sensor and the light / switch.

You can sort of do this with the event viewer (at least in v.5.0.13C). The last two entries show me changing the value of a state variable from 0 to 1 and then back to 0. Only state variables, not integer, seem to appear in the event viewer, probably because they are triggering variables and integers aren't. While you can't choose to track just a particular variable, you do get a detailed log of when the variable changed and to what value.

The WAIT statement executes the specified wait, but also allows the IF to be reevaluated any time one of its conditions changes. So you need to move the commands under the THEN to another program that has no conditions in its IF and call that program from your existing THEN.

Yep, I read the page, but clearly missed it buried in the bullet points. Though even what's listed isn't very specific. Up to a 90 degree arc? Is that left & right? Up & down? And why "up to"? What will impact whether it's 90 degrees or only 60? And 30 feet detection is straight ahead, I assume. What about at 15, 30, 45, 60, 75 or 90 degrees off center (left & right and/or up & down)? Then I read the "SPECS" page where I expected to find it, but didn't, so assumed there was no reason to read the overview page again. My bad, I guess.

This isn't really an ISY question, but I know some of you have the 2844-222 so I thought I'd take a shot at asking a question here. What are the sensing specs for this Insteon device. By that I mean how far away can it sense motion and at what angles (left & right and up & down)? The Smarthome spec page for the 2844-222 doesn't provide this information so I realize that your answer will just be based on experience but that would better than nothing. It seems strange to me that a manufacturer wouldn't provide this information for one of their devices. How is a potential buyer supposed to know if the device will meet their need? Thanks for any response and trust that if I buy some and they don't match your specs, I won't blame you. I'll blame Smarthome.

I believe that two or more years ago the "All On/All Off" command was removed from many Insteon devices. So you're probably seeing your older devices respond to the "All Off" command and your newer devices ignore it. By design, I don't think devices ever sent a reply to "All On/All Off" commands because that could cause a huge flood of activity on the powerline all at once. So it's likely that the ISY just assumes that after it sends an "All Off" command that all devices have switched off so it changes the status of all devices to "Off". Then when you do query a device that is still on, its reply tells the ISY that it is still on and the ISY changes its status accordingly. If you want one command to be able to turn all your devices off, you'll have to create a scene that includes all of your devices. Then you merely turn that scene off.

What version of the firmware are you using? What is the model # of your switches. I'm currently on firmware 5.13B. I've tried the Admin Console page for both a 2477D dimmer and a 2477S switch and both the "Backlight %" and the "Options-No LED" have an immediate effect on the switch's backlight. If you're not seeing the same, you should try opening the "Event Viewer" from Tools->Diagnostics. With it open, try changing the "Backlight %". You should see three lines appear in the Event Viewer". One that says "Writing 1 bytes to devices". One that says "Memory: ...". And one that says "Writing 0 bytes to devices". You can also change the backlight programatically via the ISY. Within the THEN or ELSE of a program, choose the Action "Your Devices", specify which device from the dropdown, choose "Backlight" as the command, and then choose a %.

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