oberkc

Neither am I. I assume it was one of those requests that folks make from time-to-time that some believe makes things more intuitive or otherwise easier. Otherwise, I am having trouble seeing what I could accomplish now that I could not accomplish before the presence of this construct.

There is no problem with using the wait command, so long you understand the consequences. In some cases, the wait statement can actually be very helpful. The big thing is understanding that wait (and repeats) can be interrupted when the program triggers. Obviously, this makes it imperative that one understands WHAT causes a program to trigger and manage this.

I do not know whether it will "work" or not, since I do not know what it is you are trying to accomplish. The program above will simply turn the lights on as sunrise+30 and turn them off 12 hours later. Gary Funk's approach in post 6 would do the same thing, albeit with two programs. Unlike Gary, I prefer the single-program approach all other things being equal.

Your action from post 1 (adjust scene) will do nothing more than set a single controller/responder relationship. If, for example, you have a motion sensor as controller and switch as responder, the action would change the ON level of the switch from XX% to YY%. When that happens and the motion sensor triggers the scene, the switch will now go to YY% for a period of time, then turn off. In order for lights to come on to YY% for a certain period of time, then have motion cause them to go to XX% for a short time during that period, then back to YY%....you would need two scenes in my mind. One scene would contain all your security lights, with all having responder levels full on. The second scene would contain all your security lights with responder levels at 40%. Neither of the scenes need a controller device, so leave the motion sensor out of it. Then, you would have two programs: if time is from some time to some other time set '40% scene" to on else set '40% scene off if control motion sensor is on and first program is true then set '100% scene' on wait x minutes set '40% scene' on else nothing If you use the motion sensor as scene controller, then you loose the option to limit response to motion based upon time. (There are other practical considerations to using motion sensors as scene controllers, including response time (quicker) and maintenance (more painful) but I will skip that discussion at this point.) During the period of time you want motion response, you will always require BOTH a 100% and 40% level response option from your security lights for response to motion and quiet times, respectively. If you have specific questions about other approaches, please ask. If you had another approach in mind, feel free to offer it. Perhaps you can come up with a better way that I have not thought about.

I am not as sure that the approach you are taking is correct. Unless I am missing something (still very possible) you may require two separate scenes for this. Both scenes would have the same responder devices, but with different ON levels (40% versus 100%). Once established, use those scenes and a couple of programs to turn each on at the appropriate times and in response to motion. Changing the responder levels within a scene will do nothing more than cause that scene to react differently once it is commanded to be on.

Keep in mind that "moving" the PLM might be nothing more than keeping the PLM in the same general location, but plugged into a long extension cord from another outlet.

dBuss, I really appreciate you taking all the time to answer these questions. Many times, when I ask questions like this (in an attempt to probe and find more clues) I get no response. It often seems that folks often don't want help, or don't want to do the work, or don't want to listen. I am glad you got it working. Still, I would have expected the program to work (if a couple of hours off) and the log to show the program as having run.

I have had some issues with other devices (roku, TV) lately that were solved by the most simple of steps: reboot. Now that you have compatible UI and firmware, have you power cycled the ISY?

Besides not being sure why you break this into two programs, I don't see anything wrong programmatically. Is the first program disabled? Does the "Christmas Lights" scene turn on if you manually run (then path) the second program? Does the program log show the first program having run at 4:30 (and being true)? Does the program log show the second program as true and run at 4:30? Do you have any unsaved changes to either of these programs?

I have thought this to be a comms problem from the beginning. Unfortunately, I have no idea why the comms problem (if, in fact, that is what it is) would be present at one particular time consistently but not another. I will add, also, that I generally don't experience communication problems as a result of other insteon communications, as you suggest. As things in the house age, perhaps they are more interfering with insteon comms. Perhaps insteon devices, themselves, as they age, become more prone to being interfered with. I continue to believe this to be a programmatic problem. Perhaps a new insteon device may have more sensitive communication ability and may solve your problem. Certainly, it is not easy trying to find these sources of interference and a new device may be the least painful solution.

Interesting question. I do not recall any program action that could modify the settings of a z-wave device. In my specific case (schlage zwave lock) the only action I can perform is lock or unlock or query.

What problem are you trying to avoid? Is there some harm in turning on some lights that are already on? my understanding is that disabling a program (including putting the program in a folder that is disabled) would prevent any condition from triggering at any time. Since a WAIT statement would be interrupted when a condition triggers, if a condition is not triggered (disabled), the wait statement would not be interrupted. I am not sure I understand that question. Use a WAIT statement when you want to pause the program for some reason. This works whether the program is disabled or not. If you desire some condition to interrupt a waiting program, either write the program(s) in such a way that disabling is not necessary, or call it from another program. I cannot think of another option. In your case, I think I would employ a program folder, with condition: if $sXmasLightsOn is 0 then run the programs in this folder In the folder, put a program like this: If time is sunset Then Wait 30 minutes (Random) Run Program 'Outside Lights-Manual' (Then Path) Else - No Actions - (To add one, press 'Action') My understanding is that were the folder to become disabled during the wait statement, the program would halt.

Correct. A scene controller operated remotely will not trigger the scene. It is better to control the scene remotely, rather than individual devices, if it is the scen you desire to turn on or off.

stusviews has the solution I would recommend. I believe Gary Funks approach would work as well, but have the slight preference for stusviews' approach. your single program does not work because the condition "Control '.Fam Rm Rem - E (Movie Time)' is switched On" is triggered only by an ON command, and can never run false.

Yes, but it showed consistent activity up to that point of trying to log in. This suggests to me that it was doing something, at least, up until that point when you tried to log in at 4:53.

I am not going to be much help with the logs, but it appears to me that it logged events all the way through 5:01. This suggests to me that something, at least, was still working. Do you know the LAN IP address of your ISY? Is it a static address? Have you tried accessing the ISY via the IP address from a web browser during these moments? If you can, perhaps that would give access to other troubleshooting options, including looking at whether there is some program in a loop.

I am thinking same thing as I suspect is stusviews, Unfortunately, I am not much good with the log, so I tend to prefer the program status list. I sort them by 'last run time' and look for things that ran near the same time as this program. I would find the time to be there at sunset-30 and check immediately. Given that your devices respond to manual program activation, I tend to discount device failure as a cause. I still am having trouble believing that the program did not run (all indications from the admin panel are that it ran, and ran true). If nothing else shows up, my next instinct would be to change the program time from sunset-30 to something else. Alternatively, delete the program and re-create. Very strange.

The fact that the lights do not turn on is not necessarily conclusive evidence that a program did not run. Perhaps the program ran, but the lamplincs did not respond. Perhaps they turned on, but something else turned them off. Personally, I have never knowingly had a program not trigger and run when it should. This is why I suspect something else is going on. Were this me, I would check status at admin panel right after program run to see if three devices match actual status. If not, there is a problem with communications most likely. Failing that, I would be looking at the program log to see if there are other programs being triggered immediately after this one. Is it possible that the change in status of one of these devices is triggering a program somewhere? But, maybe there is some bug somewhere. I can only say that a program so simple like this one is one I use multiple times a day and it fires every time.

I agree with apostolakisl. This should work. The program should run. There are no ways it cannot run. Why do you think it is not running (is it based on lights being not on)? After it runs, what does the ISY admin panel say about the status of the three devices? Does the ISY believe they are on? Is it possible that something is going on near sunset that is not going on when you manually run the program? Is the ISY sunset time accurate for your area?

Hey, Jack. If the switch is turning ON to a scene command, but not OFF, I would tend to discount (for now) a faulty switch. I did not see it asked, but what is the load on the switch? Can you temporarily remove the load to see if the switch starts responding to scene-off commands? (I am wondering if the load is causing the communication problem.) I do not believe that this is a programmatic problem. It sounds like a classic case of the ISY assuming a switch responds, but does not.

Yes. You can also check status (true/false) of the program. If true, that is a pretty good indicator tat it ladt run THEN path to completion.

Programs are triggered by events, based upon the conditions. Programs do not automatically re-evaluate based solely upon completion of an action clause.

I suppose it depends on what you would like it to do, and whether "closed" = "off". It may also be affected if you are using the sensor reverse mode on the IOLinc. In general, if the query causes a change in status of 'garage closed', the program will re-evaluate. A program in a wait state that is re-evaluated will be halted and run from the beginning, based upon the newly-evaluated status (true or false).

Good question. I do not know for sure. Do you actually use all eight scenes, or could you get by with four?

Gary, Perhaps I don't accurately perceive these hubs, but I understand that few have the automation power of the ISY. Yes, they may better support Z-wave links and scenes, but lack the logical power of the ISY. Is this inaccurate based on what you know?