kclenden

I think that's true for most of the things people might want to program. But when it comes to having a selection of programs that you want to enable/disable based on a common set of conditions (admittedly probably an uncommon need), I'll take the simplicity of a folder any day. Reminds me of having to program in LISP in college. If you needed to process a list of items, nothing could be simpler than a LISP program. If you needed to do anything else, LISP would lead you down a dark, dangerous path that would almost certainly lead to derangement.

I often misunderstand things, though not intentionally. ? To me, your posts made it sound like using a folder condition to control the execution of programs should be avoided because it can cause a program to be "stopped dead". I was pointing out that there are lots of things that can cause a program to stop before it has completed, and so dealing with that uncertainty when it's caused by a folder going FALSE is really no different than dealing with it being caused by a power failure (or other causes).

You can test a program in a FALSE folder... you just have to make the folder condition TRUE. ? You pointed out the distinction between a program that was manually disabled and a program within a FALSE folder. The former won't be triggered automatically but can be manually triggered, while the latter can't be triggered at all. I like having two different capabilities. Besides, let's say that you were able to manually start a program within a FALSE folder - how does the system know when to stop it? If you start the THEN clause should it be able to call its own ELSE clause? If so, what happens if either the THEN or ELSE starts another program in the FALSE folder? Should that program run? What if the THEN or ELSE starts another program outside the FALSE folder, should that "external" program be able to startup up the same or another program within the FALSE folder? If you don't allow all those things to happen, then you can't really completely test all possible programs within a FALSE folder even if you can manually start one up. And if you do allow all those things to happen, then you're not really testing the IF clause of the folder because it should cause a program to stop when it goes FALSE. Edit: But I do agree that there should be some indication that the program didn't actually run when you try to start it manually.

At first I thought it seemed like a bug too, but when I thought through all the ramifications, I think the way UD has implemented it makes the most sense. Any time you have a sequence of instructions, especially when you include WAITs, there is a chance that only a portion of the sequence will be completed. This might be because of a power failure, a folder's condition becoming false, a program's conditions changing, or a program being halted by another program. In each case, it's important to know whether remedial action should be taken. If it should, there's generally a way to make it happen, whether it be via THEN/ELSE logic or a state variable that triggers the appropriate remedial program.

Creating a group of programs would certainly work. The ISY has the concept of folders as well and folders can have an IF statement as well. Programs within the folder only run if the IF of the folder evaluates to TRUE. So you could have a folder for each season, and then within the folder put all the programs you want to run while your on vacation during that season.

Building on larryllix's post, you could create four programs like that, one for each season. Then simply disable all of them (right-click on the program and choose "disable"). Then when you go on vacation, right-click on one of the programs and enable it. When you return from vacation, right-click on the program and disable it.

To put a finer point on the question... Are you activating the scene by running a program on the ISY? Or are you activating the scene by turning on a Zwave device? Or are you activating the scene by turning on an Insteon device?

I think you missed the train on the "painless swap" when you decided to replace the Dimmer with a Relay. The ISY will only allow you to replace a device with a similar device and a Dimmer allows commands that a Relay does not. In any case, you should first link the new device to your ISY. One you've done that, find your old device in the list and right-click on it. Hover the mouse over "Replace xxxx with >" (where xxxx is the name of the old device) and you will see a list of devices you can choose to replace it with. If the new device is listed there then you're golden, otherwise you'll have to manually change all programs and scenes that reference the old device so that they reference the new device.

I don't know the official answer, but the pattern I've noticed is: In the device list: Magenta colored devices are able to act as controllers and Dark Blue colored devices are only able to be controlled. In scenes: Red colored devices are controllers of the scene and Dark Blue colored devices are responders in the scene.

If you mean can it be done by merely configuring a scene in a specific way then the answer is no. MWareman points out how it can be done if the door sensor can be configured not to send OFF commands, but since you're familiar with that concept from motion sensors, I'm guessing you can't configure the door sensor to not send OFF commands. Luckily, in v5, UD has given us a way to alter individual links within a scene. Depending on how many door sensors and a how many switches you're talking about, you might find this to be a way to accomplish your goal. The idea is that when the ISY detects an ON from one of the door sensors, it removes the switches from the scene that was used to turn the lights ON. That way, when the door sensor sends an OFF, the switches are not affected. Later, when the ISY turns off all of the lights, it adds the switches back to the scene. The question comes down to timing. Generally speaking, if the ISY sees the ON command from the door sensor, so have the switches and they've already switched ON so it's safe to remove them from the scene. The next issue is how long it is before the door sensor sends an OFF and was that enough time for the ISY to communicate with all of the switches to remove them from the scene. If those bits of timing don't seem to be a problem, you'd also have to consider what might happen if multiple door sensors send an ON at the same time, but I think that could easily be handled in programming. With that all said, here is a program that would accomplish the above for one sensor and one switch. I'm using my motion sensor in the program since I don't have a door sensor: Timer - [ID 00A2][Parent 0042] If 'FY-Motion Sensor.1 Motion' is switched On Then In 'FY-Motion Sensor.1 Motion' Set 'FY-Landing (M)' To ignore Wait 10 minutes In 'FY-Motion Sensor.1 Motion' Set 'FY-Landing (M)' To On, 1 retry Set 'FY-Landing (M)' Off Else - No Actions - (To add one, press 'Action') And screen shots for the two commands above that altered the scene "Foyer Landing Lights" Edit: You'd also want to have a program that runs on STARTUP that restores the switches to the scene, if needed, just in case the the power goes out between the ISY removing the switches from the scene and later adding them back to the scene. Edit 2: My initial testing above was done with my motion sensor that is powered by USB (i.e. always awake). I just tried it with my motion sensor that is powered by battery (i.e. usually asleep). The attempt to restore the switch to the scene was only partially successful because apparently when the ISY removes a device from a scene, it must update the link tables on both the responding device and the controlling device. So if your door sensors run off battery, the method detailed above probably won't work.

You could create a program, let's call it "Override Thermo" above the "Thermo Heat" folder. Put your override instructions in the THEN section of the "Override Thermo" program. Next add the condition "If Program 'Override Thermo' is False" to the folder "Thermo Heat". Now the programs in the "Thermo Heat" folder will only run if the ELSE clause of the "Override Thermo" program was the last thing that program ran. If the last thing that program ran was the THEN clause then the programs in the "Thermo Heat" folder will not run. So now if you manually run the THEN clause of the "Override Thermo" program all of your other thermo programs will stop and not run again until you run the ELSE clause of the "Override Thermo" program. You could even add IF conditions to the "Override Thermo" program if you want automatic control of how long the override will be in effect (e.g. From 6:00:00PM on 2019/02/12 To 6:00:00PM on 2019/02/15). As larryllix said, if the folder condition for the "Thermo Heat" folder causes the programs within to stop, there's no guarantee were they'll stop, though I believe it will be at a WAIT or REPEAT statement as UD has said program execution is atomic, but even if that's not the case, the chances of them stopping anywhere other than a WAIT or REPEAT would be very low.

I can't tell what you're trying to show in the Event Viewer log that you supplied. The lines above the --- test Test Results --- show devices reacting to a scene command. The last of the 09:10:20 PM lines actually shows the Living Room Plugin turning ON as the result of a scene command. The lines below the --- test Test Results --- show device 2E 7B 40 throwing an error when you try to link it in a scene. So are you trying to show the results of activating a scene? Or are you trying to show the results of attempting to create a scene? My guess is that the Links Table for one or more of the devices in your scenes is not correct. For each of those devices, you should try right-clicking on it and choose "Diagnostics>Show Device Links Table". Once that completes, click "Compare". If any records appear with a "record mismatch", then right-click on the device and choose "Restore Device". After you've checked all devices in your scenes, try turning the scenes ON and OFF again.

Practice makes perfect! Good job.

But there's nothing in the ELSE so in this case it won't matter. For future programming, ABLE1 will probably want to know about the pitfalls of changing the value of an IF conditional within the same program.

I'm curious why you would use a third scene? It wouldn't seem to get you anything that you didn't already have by simply turning one of the other two scenes off. But it would use up more links in the PLM table which has a limit of about 1000, IIRC, and we have seen people run out of room in that table. What benefit am I missing?

I agree with both larryllix and sub-routine - you need the time range on your "Turn On From X10" program. It was only the two programs that didn't also include "X10 Received" in the IF that didn't need the time range. Also, sub-routine's comment about scenes will definitely make things look more coordinated. Simply create two scenes, maybe call them "Sconces at 30%" and "Sconces at 100%". Then drag all five switches into each scene and make them responders. Finally, select the 30% scenes and click each device in the scene table and set its ON level to 30%. Then do the same thing for the 100% scene, but obviously setting the ON level to 100%. Then in your programs you merely need to turn on the "Sconces at 30%" scene when you want the level to be 30% and turn on the "Sconces at 100%" when you want the level to be 100%. When you want the sconces to be off, you can turn off either the 30% or the 100% scene since they both contains the same devices.

Above is my analysis of your linking attempt. It appears that messages between the PLM and On/OFF Module are getting through without a problem. Here are the steps represented in the Event Viewer: ISY asks the Device about its INSTEON Engine Device replies that it doesn't recognize the address of the PLM ISY tells the device to enter linking mode Devices says OK ISY tells the device to add the PLM address to its DB Device says OK ISY tells device to exit linking mode ISY asks the Device about its INSTEON Engine Devices again replies that it doesn't recognize the address of the PLM ISY asks the Device about its INSTEON Engine Devices still replies that it doesn't recognize the address of the PLM ISY gives up I can't quite tell from your posts exactly what you've tried, but here's what I think you've tried: Bought a 2635-222 and it wouldn't link at house #1 (tried three different ways - with address & auto discover, with address & device type, without address but actually pressing SET on device - and you've tried plugging this device into outlets that worked before as well as the same outlet as the PLM) Bought a second 2635-222 and it also wouldn't link at house #1 Took the second 2635-222 to house #2 and it linked without problem Brought back a 2635-222 that has been working at house #2. What did you do with this device? Were you able to link it at house #1? I don't think the issue is with the ISY. It can only react to the messages that it receives and according to the Event Viewer it never receives a message that tells it the device's INSTEON Engine. So it would seem either the PLM or the On/Off Module are at fault. It can't hurt to try Sub-Routine's suggestion to try manually linking a Switch to the On/Off Module. But based on your experience having a new On/Off Module that won't link at house #1 but will link at house #2, my guess is that the Switch will successfully link to the On/Off Module. And if that's the case, then Smarthome won't let you return it. Then I guess your next move would be to contact UD support and have them look at your Event Viewer results.

It might also be helpful to know what version your PLM is at each house, as well as how old they are. Just use "Tools>Diagnostics>PLM Info/Status" to get the version.

That video doesn't apply to the OP's problem. You'll note early in the video, Steve mentions that the PLM is not receiving any SRX records. If you look at the OP's Event Viewer log, you'll see SRX records. The device is clearly talking to the PLM. The issue is that the ISY doesn't seem to understand the device's response. You can see the ISY try twice to link with the device, and each time the responses contain exactly the same data. If there were a communication problem, either there would be no responses, or you would expect the responses to be different because of line noise. That's not happening. So it seems like the ISY really can't determine the device's Insteon Engine from the response it's getting from the device.

Scenes do not respond to %'s. If you tell a scene to come on at 30% or 100%, the same thing happens - the scene comes on to whatever level it was defined. So if you turn a scene on at 30% and then later turn it on at 100%, you won't see any difference. You can setup a scene with the sconces set to come on at 30% and then setup another scene with the sconces setup to come on at 100% - then turn on the 30% scene followed later by turning on the 100% scene. Then you'll see a difference. Paulbates had you change the conditions in your two programs not because they would help the X10 issue, but because the time range was superfluous. The end of the time range does nothing. If you want programming efficiency, then make use of the ELSE clause for your OFF command like: If From Sunset To 11:00:10PM (same day) Then Set 'Sconce Lights' On Else Set 'Sconce Lights' Off That program would replace your two programs.

The Event Viewer indicates that the device is responding to the ISY. And those responses are consistently the same so I don't think this is a communication problem. The Event Viewer makes it look like you used the "Link Management>New INSTEON Device" menu option, and typed in the address of the device, but I can't tell if you used "Auto Discover" as the "Device Type". If you did, I'd suggest specifying the exact device type:

I don't have the zwave module, but I have been considering adding one. From reading the forum, the answer to your question is that it's not necessary for you to upgrade. However, if you want to take advantage of any of the Zwave+ features available in new devices, you'll need the 500 series or later. Additionally, it seems like there is some pain when converting from the 300 series to a new series so if you're going to use Zwave+ features it might be worth $40 (depending on the enjoyment, or lack thereof, that you get out of setting things up) to skip setting up under the 300 series and then later converting to the 500 or later series.

The username and password are reset to admin/admin.

Then perhaps the issue is communication related. The MS II is an RF device that depends on a powerline device to hear and pass on its communication (unless it's close enough to the PLM). What is the closest dual-band device to the MS II? If you start the Event Viewer and set it to Level 3, when you see communication from the MS II, how may "Hops Left" are there? If it's directly communicating with the PLM, it would be 3. If it's relying on another device to pass on its message then "Hops Left" would be 2. If they are consistently 1 or 0 then you have a communication issue. You also might try factory resetting the MS II. Remove the battery; hold the set button and reinstall the battery; continue holding the set button until the MS II stops beeping; when the reset is done the MS II will double-beep. Then put the MS II in set mode (hold the set button until the LED starts blinking) and perform a Device Restore from the ISY.

How long have you had the MS II? Any chance the battery is low? Assuming the section of video with you waving your hand is continuous, the LED is not acting like mine does. I have a "timeout" of 10 seconds. After the LED flashes once, it won't flash again for 10 seconds. According to the Options screenshot you posted, your "timeout" is set for 30 seconds. I wouldn't expect the LED to flash again for 30 seconds after it first detects motion. Though you said that the only thing you changed out of the box was Motion>Report, so it's possible that the ISY is just showing the default "timeout" and not how your MS II is actually set. Still, the minimum "timeout" is 10 seconds, so I wouldn't expect the LED to flash any more than every 10 seconds and yours definitely flashes more like every 3 seconds.