kclenden

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.

Here's a program that will flash a scene every second: MakeRoomUp - [ID 0071][Parent 0070] If $sMakeRoomUp is -1 Then Repeat Every 2 seconds Set 'MakeRoomUp' Off Wait 1 second Set 'MakeRoomUp' On Else Set 'MakeRoomUp' Off To make it work, you'd have to create a STATE variable called "sMakeRoomUp". You also have to create a SCENE called "MakeRoomUp" and add the B Button as a responder. After doing that, any time the state variable sMakeRoomUp is set to -1, the B button would flash every second. You could use the following program to set the variable: ActivateMakeRoomUp - [ID 00AD][Parent 0070] If 'Keypad-Button A / Keypad-Button B' is switched On And 'Keypad-Button A / Keypad-Button B' is not switched Off Then $sMakeRoomUp = -1 Else $sMakeRoomUp = 0 The biggest issue with this is that it takes a lot of Insteon communication to keep the button flashing. This will not scale to a lot of different rooms if they're all on the same electrical network. Also, I'm running the program using v5 of the firmware. I don't remember if v4 supports the "Repeat Every x" command. Edit: if v4 doesn't include the "Repeat Every x" command, you could use this program: MakeRoomUp - [ID 0071][Parent 0070] If $sMakeRoomUp is -1 Then Wait 1 second Set 'MakeRoomUp' Off Wait 1 second Set 'MakeRoomUp' On Run Program 'MakeRoomUp' (Then Path) Else Set 'MakeRoomUp' Off Edit 2: The ActivateMakeRoomUp above works so long as you turn it OFF when the B button is illuminated. If you try to turn it OFF when the B button is unlit, it will remain active and continue to blink. The program below takes care of that problem: ActivateMakeUpRoom - [ID 00AD][Parent 0070] If ( ( 'Keypad-Button A / Keypad-Button B' is switched On And $sMakeUpRoom is 0 ) Or ( 'Keypad-Button A / Keypad-Button B' is not switched On And $sMakeUpRoom is -1 ) ) And 'Keypad-Button A / HW-Keypad-Button B' is not switched Off Then $sMakeUpRoom = -1 Else $sMakeUpRoom = 0

Given that he refers to "small buttons" and then calls them button A and button B, I'd assume it's a six button kepad with the first two small middle buttons being used. Edit: But I do know what they say when you assume things.

That would be very strange. I can't even come up with a theory as to why that would happen. Now I'm gonna have to try it. ?

But couldn't you create a scene whose ON level for every device is 0% (or OFF)? Then when the scene is turned ON everything is turned OFF. And when the scene is turned OFF everything is turned OFF. So even though the scene is responding to both ON and OFF commands it's acting like it's receiving OFF commands.

Does the LED care about polarity? If so, do you have + and - wired correctly? Have you tried wiring the transformer directly to the LED?

Interesting. I would have sworn that I had opened the battery cover since linking my MS's. One of them is powered by USB, so I likely would have unplugged it before opening the battery cover, but the other one is battery powered. Maybe I haven't opened that one since linking it. I'll have to open it up and see what happens. ?

There are two things to consider about a program conditional: What triggers the IF to be evaluated What causes the IF to be TRUE (and run the then) or FALSE (and run the else) Whether the IF evaluates to TRUE or FALSE only matters if the program is triggered to evaluate the IF Let's consider what triggers the IF in your program to be evaluated: If it's 10:00PM Maybe if $Garage_Door changes to a value of 1 from some other value. I can't tell for sure because I can't tell whether $Garage_Door is a state variable or an integer variable. Only changes to state variables cause a program to trigger. A lot of people use a convention whereby they start a variable with an "s" if it is a state variable or an "i" if it is an integer variable. So depending on which type it is, your variable would either be $sGarage_Door or $iGarage_Door. You right-click on the program and choose "Run (If)" Now let's consider what causes the IF in your program to be TRUE: When it's 10:00PM AND when $Garage_Door is equal to 1 Based on all of the above, if we assume your variable, $Garage_Door is a state variable then the IF will trigger, and either the THEN or the ELSE will run and you should receive one of your two text messages under these to conditions: It's 10:00PM $Garage_Door changes to 1 from some other value If $Garage_Door is an integer variable (which is what I think you want), then the IF will trigger, and you should receive one of your two text messages, only once a day at 10:00PM. I'm unclear about whether you're saying that you tried the program and it didn't send a text message. If that's the case then I can think of the following possible causes: Your outbound communications are not working. You can check this by right-clicking on the program and choosing "Run (Else)". You have accidentally disabled the program. Disabled programs have a small red circle with a slash on their icon.

Yeah, I reported that in a different thread. The ISY gives priority to Insteon communication, so lower priority tasks queue up until the ISY has no more Insteon communication to handle. I don't think that there is simply a delay in recording them in the log, I think they don't actually execute until the time displayed in the log.

I don't think the MS II has a heartbeat. I'm assuming this is because you can query it for "Battery Level". I'm guessing you have the MS II set to "Report: On Only". Since the sensor never reports OFF, the ISY doesn't know when the sensor internally switches to OFF, and thus the ISY always reports the state as ON. Interesting. My MS II doesn't show any status for "Tamper". It's not ON or OFF, just blank. This is for the same reason the MS II always shows a status of ON. The TriggerLinc sends an ON every ~24 hours on the "Heartbeat" node. It never sends an OFF. So the ISY always reports the "Heartbeat" as ON. The only way to know if you're receiving heartbeats from the TriggerLincs is to setup a program that looks for the "Heartbeat" node to be "switched on". I have a program that looks for the heartbeat to be switched on and then starts a 25 hour WAIT. If another switched on is received with that 25 hours, the count starts again. If one isn't received, the line after the WAIT sends me a text message saying that a heartbeat has been missed. That's what my TriggerLinc shows as well. This would indicate that the ISY has never received any kind of signal on the node from the TriggerLinc so I'm not sure what it's used for. Edit: I take that back. I think the TriggerLinc is basically the same thing as the current Open/Closed Sensor. Given that, I think the "Closed" node is supposed to work in what is called a "Multi-Scene" mode. In the "Multi-Scene" mode what is supposed to happen is that when the door is opened, an ON is reported on the "Open" node and when the door is closed an ON is reported on the "Closed" node. This gives you more advanced control over what happens when the door is closed. In the "Default" mode, since the "Open" node changes immediately when the door is opened and closed, if you have a light linked to the sensor it will come ON and go OFF immediately with the door state. A lot of people want the light to come on immediately when the door is opened, but not go off immediately when the door is closed. The "Multi-Scene" mode allows this because you can link the light to the "Open" node, but not link it to the "Closed" node. In this case the light comes when the door is opened, but does not go off when the door is closed unless a controller, like the ISY, turns it off. The problem is that the "Multi-Scene" mode cannot be programmed by the ISY. There are questions about whether the mode is even still supported by the sensor. My TriggerLinc acts like your three. Your fourth one is interesting. I'd be interested in seeing the program the fourth is used in because I don't know how it can be reacting to an OFF if your ISY never sees an OFF.

As you reported in another thread, the changes show up in the Event Viewer. I can confirm that I don't see the variable changes in my log. One thing to keep in mind, though, is that only a change to the variable appears in the Event Viewer. So if the THEN merely did $sTemp = 1 and you ran the THEN three times in a row, you would only see the first variable assignment in the Event Viewer and not the following two. That is why when I use a state variable to track program execution, I assign a value that I'm tracking and then immediately assign 0 (i.e. $sTemp = 1 followed by $sTemp = 0).

I always look at them in the Event Viewer so not sure if they show up in the log. But even without looking at the Event Viewer, you can look in the "Variables" tab, at the "Last Changed" time.

If you're willing to go to the trouble of trying to wire in a solar charger, couldn't you just create a supersized battery? Take six batteries and wire them in parallel and wouldn't it last six times as long? You'd still have to change batteries, but not nearly as often.

The only way you're going to know is to test it with a program. Set one variable in the THEN and another variable in the ELSE. Then you can check the time those variables are changed. Still, as mwester says, there's no guarantee that behavior won't change in the future. Case in point - there is currently a bug using "Sunset + x". If "Sunset + x" is before midnight then it works as expected (i.e. it runs every day at Sunset +x). If "Sunset + x" goes past midnight then it only runs every other day at Sunset +x.

Even easier... you don't have to do anything. I just tested this on my battery operated MS II. The next time the MS II wakes up (heartbeat or motion), the ISY will complete the calibration on its own and the red exclamation will disappear.

Um, wouldn't that be 49 years?