kclenden

There you go exaggerating again. More like 3.25 years or only 3 years if you're rounding. ?

Is this the post you mean?

Thanks. I've only been using v5 for about six months, and I keep forgetting about some of the new features. Capturing the "Seconds since start of day" when a device is turned on, and then subtracting it from "Seconds since start of day" when the device is turned off would give you the number of seconds the device was ON. You'd have to account for possibly going past midnight, but that wouldn't be too difficult.

It depends on what you mean by usage. If you mean power consumption, then no. If you mean keeping track of how many times something is turned on/off, or how long something remains on, then yes. Without changing anything at all, you could use a macro to pull the information out of the ISY log. If you want it to be more interactive, you could create some integer variables, and then use programming to increment those variables while a device is ON, and stop incrementing when the device is OFF. Depending on how often you setup the programs to increment, you could track device ON time to the minute. Edit: You could even come up with crude power usage by measuring the power usage once, and then using that as a multiplier.

Old links won't be a problem if you perform a factory reset. From the Smarthome Quick Start Guide: "To reset the Power Line Modem to its original factory settings, unplug it from the wall outlet and wait 10 seconds. Press and hold its SET button, plug it back in, continue holding the SET button for 3 seconds and release. After several seconds, the Status LED will turn on, indicating a reset is complete."

Thanks for the update. Others with similar problems will benefit from your follow-up.

My understanding of Ramp Rate is that it represents the time to go from 0% to 100%. So if the light is already at 30% and you then command it to go to 100%, I would expect it to take only about 6 seconds (70% of 8.5 seconds) to get to full brightness.

The null is associated with the log type of Start. It means that your ISY rebooted. The only times my ISY has rebooted was either when I commanded it to reboot, or as the result of a power failure. Since you weren't there, I'm going to guess your ISY rebooted because of a power failure. The following six lines in the log show your ISY querying devices for their status. It's not actually commanding them to do anything, but just finding out what state there currently in. That's what the Status Off means. The On Level 100% and Ramp Rate 8.5 seconds mean that the switch is configured to come on to 100% with a ramp rate of 8.5 seconds if you actually tap it. Your ISY queries all of the devices for their status after a reboot because you have Query at Restart checked within the System box on the Configuration tab. If you uncheck that box, then the ISY will not query devices for their status each time it reboots.

UDI is usually pretty economical with their programming technique, especially given all the effort they've been devoting to get v5 to a production state. So I wonder if there isn't an underlying reason why the "on level" adjustment for a scene is present. Maybe it's allowed with Zwave or Zigbee? If it's allowed by another protocol, I could see why they left it in for Insteon, as limiting options by protocol would probably be low on the list of things to implement when you're trying to get out your first production release of a new firmware version.

I'm not entirely sure what your goal is, so I'll answer two scenarios: First, let's say you have three lights in a scene, and you set the scene to turn them on to 100% brightness whenever a switch is tapped, and then you tap one of the switches to turn on the lights. Now, while the lights are ON, you want to adjust their brightness to 50% at 10:30pm (i.e. bring all three lights down to 50% brightness). You can't do that with the scene that you used originally. You'd either have to send a command to each device telling it to dim to 50%, or you'd have to have a second scene already setup to turn those devices on at 50% brightness, in which case all you'd have to do is turn on that second scene. Second, let's say between 10:30pm and sunrise you want the three lights in your hallway to only brighten to 10% instead of 100% whenever any of the switches is tapped. Since the ISY isn't involved when any of the switches communicates directly with the lights, you have to "adjust" the scene ahead of time. That you can do by using the "Adjust Scene" option. Essentially, at 10:30pm, you would individually adjust the desired scene brightness for each responder (i.e. light) per controller (i.e. switch). So if you had a 3-way switch configuration controlling three lights, you have to make 9 scene adjustments. Once that was done, whenever any of the switches was tapped, the lights would come on at 10% brightness. Then at sunrise (the ELSE of your program above), you have to make another 9 scene adjustments to return the programmed scene level to 100%. In the example above, your lights and switches are probably synonymous (assuming each switch directly control a load), but the end result is the same.

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?