kclenden

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

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.