kclenden

When the ISY executes a WAIT, it does two things. First it starts counting down the time you specify and second it watches the conditions in the IF statement to see if any of them change. If its time countdown reaches 0 before any of the conditions in the IF change, then the ISY executes the statements following the WAIT. But if one of the conditions in the IF changes before the countdown reaches 0, then the ISY stops executing the code in the THEN and reevaluates the IF and based on the results of that reevaluation either executes the THEN from its first line or the ELSE from its first line. So when your WAIT was set to 1 minute or 2 minutes, the 'MotionSensor - CarPort-Sensor' Status is On condition changed before the countdown completed and the ISY quit executing the code in the THEN and reevaluated the IF which then caused it to execute the ELSE. When the ELSE was blank nothing happened and thus the light stayed on. Once you added the OFF statement to the ELSE, it's execution resulted in the light going OFF. I don't know why the 15 second WAIT doesn't work if the internal timer of the Motion Sensor is actually set to 30 seconds. If you change the condition in your IF from 'MotionSensor - CarPort-Sensor' Status is On to 'MotionSensor - CarPort-Sensor' is Switched On then it won't matter how the internal timer of the Motion Sensor is set. The reason for this that Status can be either ON or OFF and thus when it changes from one to the other the WAIT will be interrupted and the IF will be reevaluated. But Switched On is a discrete event totally separate from Switched Off. So when the Motion Sensor changes from ON to OFF and triggers a Switched Off event, your Switched On condition of your IF doesn't change which means your WAIT countdown won't be interrupted and will ultimately reach 0 and execute the lines that follow it.

Or put another way, $Variable represents how many of your triggering events have happened. When it's before 7pm and before sunset, $Variable is 0. When the first triggering event happens (either 7pm or sunset, whichever comes first) $Variable becomes 1. Then when the second triggering event happens, since $Variable is greater than 0, you reset $Variable to 0 and execute the desired action.

That's interesting. You would think if the ISY was having trouble connecting to the SD card that errors would have shown up in more places than just outgoing emails and SMS. Did reseating the SD card involve rebooting the ISY? If so, could the reboot have been responsible for the fix? Were there any errors shown in the ISY error log?

There may be no right or wrong way, but some ways are definitely better. For example... This will work, but the second scene "Scn WGF Timer A - OFF" is not needed. Scenes can be turned OFF as well as ON. So your first scene "Scn WGF Timer A - ON" can be used two ways. First you can turn it ON which will light Button A, and turn off Buttons B-D. Second you can turn the scene OFF which will turn off all of the responders (i.e. Buttons A-D). So you can accomplish with your first scene (by turning it ON and OFF) exactly the same thing you can accomplish with the two scenes (by turning them ON). Even though using two scenes will work, I consider using only one scene better. Why? Because each device has only so much memory available in which to hold scene definitions. While you may never use up all the scene memory in the individual devices, you may eventually use up all the scene memory in the PLM because it holds an entry for every scene to which every device belongs.

Information about the various modules can be found in the wiki: https://wiki.universal-devices.com/index.php?title=Main_Page#Add-On.2FOptional_Modules_for_the_ISY-994i Both the ISY Portal Module and the Network Module are software. You pay for them online and then can pretty much install them and begin using them instantaneously. The ISY Portal is a subscription. You pay $23 for the first two years and then $12 each year thereafter. Once your subscription runs out, you no longer have access to the ISY Portal (or the Network Module that comes with it). The Network Module is a one time payment of $49. You have access to it until you choose to deactivate it.

A couple things to note before you upgrade: After the upgrade the username/password to access the Admin Console will be reset to admin/admin If you have disabled any programs in v4, they may not be disabled in v5. So you should make a note of any programs that you have disabled before upgrading The same thing may be true of programs you have set to "run at startup" so make note of those before upgrading Some people like to save a text version of all of their programs before upgrading. This gives them an easy reference to use after the upgrade. Simply go to the top of the program hierarchy in the Admin Console (in my case it's "My Programs"), right-click and choose "Copy to Clipboard". Then open Notepad and paste the results and save the text document. If you do this, it will also give you a record of programs that are "disabled" and "run at startup" since "[Not Enabled]" and "[Run At Startup]" appear to the right of the program name (or at least it does when I do this in v5). Here's a link to a summary of the steps JacktheRipper was kind enough to post when he moved from 4.7.3 to 5.0.14. The move to 5.0.15 should be similar but with a different firmware file:

Turns out you have another option. If you have the Network Module which can be purchased stand-alone OR comes with the ISY Portal Module, then you can CREATE/DELETE/APPEND TO files within the Web Server directory. This would allow you to create your own log file. From the wiki:

When you setup Master/Slave switch combinations (i.e. 2-way, 3-way, multi-way switches), the slaves don't have anything connected to the load. So not connecting something to the load is quite common.

I don't think it's a defect. I think you may have chosen the wrong command. If you're trying to have each of the devices come on to a 50% level, then the command in your program should be Set "Entry / Backdoor light" On 50%. What's actually in your program is a command that sets the device's ON LEVEL (i.e. what it does when you press the device's switch). Setting a device's ON LEVEL requires writing to its internal memory and thus why you're seeing the busy messages.

Sorry about that. You're not leaving out any steps. I was out of town when I replied, and was going from memory, which unfortunately wasn't quite complete. Changes to state variables are recorded to the Event Viewer but not the Log. The Event Viewer can be saved to a file, but using it to log values over a long time wouldn't be practical as you'd have to leave it running on a computer for a long time.

You are correct that most things only get recorded in the log if they change. The other thing to know, IIRC, is that only only state variable changes get written to the log (not integer variables). So you could create a state variable that you use to pass values to the log. Say you create a state variable called sLogVariable. Then whenever you want to make sure that a device value gets recorded in the log you need to do two things. First set sLogVariable=-5000 (or some other value you know the device will never report). Then set sLogVariable = the selected device value. By first setting it to -5000 you guarantee that when you next set it to the selected device value that you will be changing the value of the variable and thus it will appear in the log. Later when you process the log, you simply ignore the -5000 value when you collect data.

What the heck, let's expand just a little bit more... Only one instance of a particular program ever runs. So if you use a WAIT or REPEAT within a program, and the WAIT or REPEAT is terminated because the conditions of the IF are triggered, then the current instance of the program is terminated and a new instance begins to run. Likewise, if a particular program is running when another program executes a RUN command for that particular program, then the currently executing instance is terminated and a new instance begins to run.

I don't really have an explanation for the results you're reporting, but the fact that the scenes work correctly when triggered locally, but not when remotely triggered seems to imply that you don't have something configured correctly for that device's scenes in the Admin console. In actuality, the scene that it executed when you press a button locally is completely different from the scene that is executed when the scene is controlled remotely. When you look at the scene in the Admin Console, you'll see the scene name and then indented beneath it will be each device that is enrolled in the scene (responders and controllers). In my case all of the responders are shown in blue text and the controllers are in red text. If you click on a controller (i.e. red text) in the scene, you'll see the scene that is executed when you press a button locally. If you click on a responder (i.e blue text), you'll see what the responder should do when the scene is executed remotely. So for each scene defined in the Admin Console, all of the blue text represents what should happen when that scene is executed remotely and each red text represents what should happen when a local button is pressed. You should check all of the blue text for your scene in question to make sure that each responder is appropriately set.

You can't put it into SET mode from a program, so you just have to wait for it to wake up and then query it. It wakes up every time it detects motion. So create a program that executes a query whenever motion is detected. Here's the program I use: Record UH-MS Data - [ID 003F][Parent 0066] If 'UH-Motion Sensor.1 Motion' is switched On Then Set 'UH-Motion Sensor.1 Motion' Query Wait 5 seconds $iUH_Temp = 'UH-Motion Sensor.1 Motion' Temperature °F $iUH_Luminance = 'UH-Motion Sensor.1 Motion' Luminance % Else - No Actions - (To add one, press 'Action') You only need the first line after the THEN. That line actually executes the query and updates the MSII status within the ISY. I use the other three lines to capture certain sensor values to integer variables that I use in other programs. Creating this kind of program will ensure that the ISY has the latest battery level, or at least the battery level as of the last time motion was detected.

You haven't given a lot of details about the original program that works or the newer one that doesn't so assumptions are required... Assuming your original program is modifying a scene to change the brightness level from 100% to 20% between midnight and sunrise and that you're now trying to do that with a scene that includes a SwitchLinc and a Mini Remote as controllers and a LampLinc dimmers as responders then you're probably running into the problem that the Mini Remotes are battery operated and thus are asleep most the time. What that means is that when midnight comes and you try to change the scene settings, the Mini Remotes are asleep and the scene update fails. If that's the case then you should see the "1010" icon next to the Mini Remote in the device list indicating that a write to the device failed. In theory you should be able handle this situation by commanding a "Write Changes" to the device the next time it wakes up.

I'm pretty sure that you can't restore a v4 backup to a v5 system. So either you're going to have to upgrade your old system to v5 and take a backup (assuming it's stable enough) or you're going to have to downgrade your new system to V4, restore a backup, then either continue using v4 or upgrade to v5.

I don't think this is correct. My 2844-222 MS II is a controller only, but when I display it's link table there are 11 entries. When you think about it, there minimally needs to be a link recorded in a controller that ties it to the PLM. If that didn't exist then the PLM could not control the device (e.g. configure it). And direct links between a controller and responders need to exist so that cleanup messages can be processed. Your screenshot shows red exclamation points next to your old Remotelinc. This means the ISY can't communicate with the device, which makes sense since you said you no longer have it. Chances are the ISY would need to write to the old Remotelinc links table and and since it can't (because it can't communicate with it) the ISY does not present the "Replace" option.

I've not done a "Restore ISY" before, but my understanding is that it only restores the ISY (e.g. Programs, settings, etc) and not actually the underlying network (i.e. PLM and Devices). You'd use "Restore ISY" if your SD card failed, or you replaced it for some other reason.

The Admin Console does not have connectivity with those devices. It has connectivity with the PLM and the PLM has connectivity with those devices. When you link a device to the ISY, you're really linking the device to the PLM. When that happens, four tables are built: 1) A table of links in the device, 2) A table of links in the PLM, 3) A copy of the table of links in the device held by the ISY, 4) A copy of the table of links in the PLM held by the ISY. What has likely happened is that the table of links in your PLM was corrupted. This would mean that when the ISY tells the PLM to talk to a device, the PLM can't do it because it doesn't have the correct entry in its table that links it to the device. This would also mean that if a device sends a status update to the PLM, the PLM ignores it because without the correct links in its table it doesn't recognize the device. So you do a restore device which means the ISY uses its copy of the PLM table and device table to rebuild the entry for that device in the PLM and rebuild the table of links in the device. These rebuilt links would also include links for any scenes to which the device had been enrolled. A corruption of the PLM table of links could be a symptom of a failing PLM, but it also could be a symptom of a one-time event like a power surge.

To turn KPL buttons ON/OFF (other than the A button), you have to create a scene into which you add the button(s) as a responder. Then you simply turn the scene ON/OFF.

Definitely go directly to 5.0.15. You'll want to look at the 5.0.15 thread, but after monitoring the threads for the last few versions it seems like the key things look out for have coalesced around just a few things.

Yes. Edit: Added suggestions... A couple things to note before you upgrade: After the upgrade the username/password to access the Admin Console will be reset to admin/admin If you have disabled any programs in v4, they may not be disabled in v5. So you should make a note of any programs that you have disabled before upgrading The same thing may be true of programs you have set to "run at startup" so make note of those before upgrading Some people like to save a text version of all of their programs before upgrading. This gives them an easy reference to use after the upgrade. Simply go to the top of the program hierarchy in the Admin Console (in my case it's "My Programs"), right-click and choose "Copy to Clipboard". Then open Notepad and paste the results and save the text document. If you do this, it will also give you a record of programs that are "disabled" and "run at startup" since "[Not Enabled]" and "[Run At Startup]" appear to the right of the program name (or at least it does when I do this in v5). You might also want to review the 5.0.14 upgrade thread to see what other people have said about upgrading. Comments like the following are spread throughout the thread and provide insight about things that might not be as clear as they should when you begin:

That makes sense. So I did a little exploring in the Admin Console and found, at least in v5 of the firmware, that you can directly check the status of a folder. Simply choose the "Program" option and scroll down until you find the folders. Here's a screenshot: So make that the condition for your email program which then can be inside, or outside, your folder.

Haven't tried it, but couldn't you just create a program within the folder that has exactly the same two conditions as the folder and put commands in the THEN of that program?

If you're running v5 of the firmware, yes. Here's the program I use: Record UH-MS Data - [ID 003F][Parent 0066] If 'UH-Motion Sensor.1 Motion' is switched On Then Set 'UH-Motion Sensor.1 Motion' Query Wait 5 seconds $iUH_Temp = 'UH-Motion Sensor.1 Motion' Temperature °F $iUH_Luminance = 'UH-Motion Sensor.1 Motion' Luminance % Else - No Actions - (To add one, press 'Action') In the Admin Console, while editing the program, you have to set "Action" to "Variable" then click the arrow to the right of the assignment operator (e.g. "=") until you get a list of devices then choose the device and the parameter.