kclenden

Are you sure you got the alert as a result of the "sunrise" program? I ask because your "sunrise" program runs the IF (as opposed to the THEN) of your "Coop Door Open" program. Are there actually conditions in the IF of the "Coop Door Open" program and could they be the reason you get an alert on reboot?

When you setup a scene you must do several things: Define what happens when the scene is activated by the ISY (that's what your image above shows) Define what happens when the scene is activated by each of the controllers (e.g. when a switch is turned on) So in your case you should have defined what each device does when it's activated by five different controllers (the ISY, Dimmer1, Dimmer2, Dimmer3, Dimmer4). Have you done each of those steps? Edit: One other thing, if you turn a device ON, that is a controller in a scene, by using the Admin Console, that does not activate the scene in which the device is a controller. The only way to activate a scene is by either turning the scene on using the Admin Console (or program) or by physically turning on the device.

Clever. Still, it really shouldn't be necessary in this case.

So the "Last Run TIme" showed "Sunset + 10 minutes" and the "Status" showed "True"? If that's the case then I would make sure I had the Event Viewer open and set to 3 shortly before Sunset + 10 minutes. That will let you see what device communication happens at the time the program fires. Or you could change the "From" and "To" times to do some quicker testing.

Switched off refers specifically to receiving an "Off" command from a device so it won't matter whether the garage door is already open. I doubt it's a bug, but just in case I created a test program to see what happens on my system: New Program - [ID 00A2][Parent 0001] If From Sunset + 4 hours and 43 minutes To Sunrise - 10 minutes (next day) And ( 'ST-Overhead Light' is switched Off Or 'DR-Chandelier' is switched Off ) Then $sTest = 0 $sTest = 1 Else $sTest = 0 $sTest = 2 It worked exactly as expected - at 10:15PM the ELSE was executed even though one of my devices was already OFF. So my guess is another program is the culprit.

I don't think there is a way to make the time range not a trigger when used in a program. Creating a folder that uses the time range as a condition would in theory do what you want, as the state of a folder going from FALSE to TRUE does not trigger the programs within (i.e. the programs are now allowed to run, but won't until one of their own triggers fire). Why do you care if the program triggers every day at 10 minutes after sunset? Since you're using "switched Off" and not "Status is Off", it will just run the ELSE which is blank.

It's not different. "Between" is just another way to refer to the "From/To" programming construct which allows you to accomplish you're initial goal - turning two programs into one.

He also indicated that he uses them to trigger video/image capture so that's probably why he has them trigger during the day. Our cat causes my MSII to trigger the hallway light in the middle of the night while we're in bed. I think I'll try the masking method Larry posted above to see if I can cure that problem.

Most people new to the ISY don't think of using the "Between" condition. I think this is because they want something to happen at sunset and something else to happen at 11pm, but they don't want anything to happen in between those times. The reason "Between" works in this case is because the ISY has two types of conditions. The first are "trigger" conditions and the second are "evaluation" conditions. "Between" is both of those kinds of conditions. A program will only ever run if it is triggered to run. In the case of "Between" there are two triggers: sunset and 11pm. So at sunset the THEN will run (unless there are more conditions in the IF) and at 11pm the ELSE will run. At any time between those two, the program will not be triggered - so in this case if the program turns the light on at sunset and you turn it off at 8pm, the program will NOT be triggered to run and turn the light on again. Once a program is triggered by a trigger condition, evaluation conditions will impact whether the THEN or ELSE is executed. Integer variables are evaluation conditions. Their value can impact whether the THEN or ELSE is executed, but a change in their value will not trigger the program in the first place. "Between" is also an evaluation condition. If some other trigger causes a program to run, a "Between" will impact whether the THEN or ELSE is executed.

Good point. Though in my case, if it's an outside door, I almost always immediately close the door after opening it so ON and OFF would basically be the same. ?

I think I'm misunderstanding the problem. It appears that you're trying to add "Garage KL-A Yard Lite" to a second scene as a controller and the pop-up is telling you that "Garage KL-A Yard Lite" is already a controller in the "Back Yard Lite" scene and since a device can't be a controller in more than one scene, the pop-up is asking you whether you want to add "Garage KL-A Yard Lite" as a responder to the second scene. If you click "Yes", the ISY should go ahead and add "Garage KL-A Yard Lite" to the second scene as a responder. Is it not doing that?

I don't think he'll have a problem. His test is "And Control 'Front-Door / Front Door-Opened' is switched On". While "Status is ON" and "Status is OFF" are opposites "switched ON" and "switched OFF" are not. So the WAIT won't be interrupted when the door is closed and a "switched OFF" is generated. It's this nature of "switched ON/OFF" events that causes people to test for "switched ON AND NOT switched OFF" when they want the THEN to execute upon a "switched ON" event and the ELSE to execute upon a "switched OFF" event. So net, no need to switch to two program instead of one.

The issue with your AM Program is that you change one of the IF criteria (bolded above) within the THEN. You then execute a WAIT which allows the IF to be reevaluated, and upon reevaluation it transfers control to the ELSE. You really don't need to check whether the 'Front Lights and Porch / Front Lights' are OFF before turning them ON. Remove that test from both your AM and Evening programs and remove the two statements in the ELSE of the AM program and you'll be good to go.

Using State variables can be very useful for debugging purposes. Whenever a State variable changes values it is recorded in the Event Viewer log. Thus by watching the Event Viewer you can follow all changes to the variable. But, as you mentioned, you need to make sure the State variable isn't being used to trigger other programs that might mess up your calculations. And, after debugging, I'd definitely recommend converting the State variable to an Integer variable if you're not going to be using it to trigger programs. Besides avoiding unexpected program interplay, I'd think fewer State variables would place less stress on the ISY's computing resources.

That doesn't sound strange to me. All I see in my "Event Viewer" is raw numbers. You can divide by 255 if you want to know the %. Now in the "Log" I do see % and not raw numbers.

Interesting. I wonder why it didn't work for @mmb with precision set to 0 and then worked when precision was increased. Wonder if it was actually the change in precision or deleting and then recreating the program that fixed it.

What did your testing show? When the precision was set to 0, did the program work for you as it did for me? I still have the variables that I setup for the test and they are definitely set to a precision 0 (as my original variable screenshot also shows). In fact, when I created the variables the precision defaulted to 0 and I never put my cursor in the precision field.

That was my thought initially too, so I setup the following program to test what happens if the precision is set to 0. The program worked perfectly. Besides, even in theory a precision of 0 wouldn't effect the "-= 32" operation. Precision Test - [ID 0044][Parent 002B] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $Temp_Current = 0 $Temp_Current = $Temperature $Temp_Current -= 32 $Temp_Current *= 0.5555 Else - No Actions - (To add one, press 'Action') The program above (with both variables being Integer and a precision of 0) gives -9 as the final value in $Temp_Current every time. I'm using v5.0.15A. Are you judging the programs success by the values you see via the SEND notifications? I don't know when variables are bound to output, but I'm guessing that's one problem you are seeing. It would be better if for testing purposes you created your variable as a STATE variable. Changes in state variables are shown in the Event Viewer. So you could open the Event Viewer and then run your program and you will see every time your variable changes value. Also, if you right-click on a program's name, and choose "Copy to Clipboard", you can then paste your program into your messages and we can see it in its entirety.

Thanks for sharing your complete journey. Often people don't close the circle leaving others experiencing the same problem to wonder if (and how) the problem was solved.

In general your process seems sound, but a couple items have me confused: #4 - It seems to me that after linking a switch to the ISY you should find two links in the Device Links table, not an empty table. There should be an A2 and an E2 link. #5 - If you deleted the switch in step #2, how do you later do a restore?

Your links table looks normal. For example, here is the links table for one of my motion detectors (my PLM is 40.52.35): Notice that the first six lines look identical except for the address of the PLM. The rest of lines in my link table are related to a scene that I have the motion detector in. Well it depends on what you mean by bad links. Links that start with 22 or 62 instead of A2 or E2 are links that have been deleted. Rather than actually delete them, the device merely marks them as inactive. It does this by setting the most significant bit to 0 (thus an A which is 1010 in binary becomes 0010 and thus changes to a 2 in hex and an E which is 1110 in binary becomes a 0110 and thus changes to a 6 in hex) So those aren't actually bad links. Then there are bits that control the SmartHop count which can change a leading E to an F or a leading A to a B (or change a trailing 2 to an A). While the ISY will show those as mismatched records, they aren't actually. They're merely records that the device changed after the ISY created them.

To me, this would seem to indicate that the links for the problem motion detector are not yet correct. If you right-click on that motion detector and choose "Diagnostics->Show Device Links Table" it will show you the links that are resident in the device. If the device is battery operated, you'll have to put it in SET mode first. Once the links have been displayed, click the "Compare" button. This will compare the links in the device with what the ISY thinks should be in the device. If the COMPARE comes back without any errors, and yet the device status does not change in the Admin Console, then I think you're going to have to relink the device to the ISY. If the COMPARE comes back with errors, then I'd suggest factory resetting the device, and trying "Restore Device" again.

I think it's safe to assume that the problems are related to the PLM replacement. From your description, it seems like the ISY is not seeing status changes from some of your devices (Motion Sensor, Light Switches). So for the devices that don't seem to be triggering your programs, are you seeing a change of status in the Admin Console? While your on the "Main" tab, and with the Motion Sensor selected, do you see the Status change from "ON" to "OFF" and vice versa? Likewise with the bathroom switches that don't seem to be activating programs. If you're not seeing a change of status in the Admin Console then there are still links missing in your devices.

Generally speaking, I would expect you to have at least two links for every devices. One is a responder link which makes the PLM a controller and the device a responder. This allows the ISY (via the PLM) to control a device. The other is a controller link which makes the device a controller and the PLM a responder and ensures that the when you manually activate a device, it sends its status to the PLM. Or at least that's how I've interpreted the purpose of those links. Additionally, for every scene a device is in, another link will be created.

You use the "Kitchen2.1 Motion" device to check for motion. If you right-click on "Kitchen2.1 Motion" and choose "Group Devices" then the other nodes will appear below, and indented. It's been a while since I added my motion sensors, but I think when I renamed the main node I chose "Rename all associated devices by replacing the prefix of each name with a new common prefix".