oberkc

I recall also that, when triggered, insteon (battery) devices have a window of opportunity through which they can be programmed. I thought ISY would take advantage of this window, but am not confident of this. I would also suggest that this is a good reason to use programs (rather than scenes) to trigger events from battery devices. One can easily change programs without needing to update link records in those battery devices. None of my battery devices are scene controllers. I also am not overly concerned with the delay associated with programs.

"Adjust scene" is the wrong command for a keypad button. Secondary buttons can be either ON or OFF. If you want to turn on/off a scene, select "your devices>>>SceneA>>>on (or off)"

Yes, as expected. Since the only thing that would turn it off is your program, and that program is triggered only by motion, then motion is a necessary condition for it to turn off automatically. You would need additional logic to force the light to stay on when manually activated. Yes. Sounds like a good intellectual exercise. It is, basically, the same thing, accomplished in two different ways. Smarthome used to call these scenes. Perhaps they still do. I think I have seen them called links. Unless you are a real insteon geek, best leave the scene creation to ISY.

Still thinking comms problem and still waiting on results from earlier suggestions and thoughts. Something is interfering with insteon communications. Unfortunately, it is often not easy to identify the culprits. Moving the PLM can sometimes yield a clue (and still waiting for you to do this, I think). When the easy stuff is tried without success, the only way I know to identify a problem is to unplug suspect gadgets (TV, theaters, UPS, surge suppressors, LV lighting, power supplies and chargers, old fluorescent fixtures, etc....) and see if this solves the problem. Yes, it is tedious and PIA. IN case it has not been asked...you have confirmed communication between the legs of your electrical system, correct?

The plain English terminology was because I did not know the exact names of the devices involved and hoped you could interpret that correctly. Your program (then path) should turn on whatever device is "shower light MB" on, wait two minutes, then turn the same device off. Is this what you want in response to motion (from sunrise to 11pm)? If so, then this program is correct. The "set off" command simply turns off the device called "shower light MB". It has no effect on the motion sensor. One cannot "freeze out" commands from the motion sensor, short of removing it from the ISY or removing the battery. The motion sensor commands come always, based on configuration you have set for it. You cannot turn a motion sensor on or off. The motion sensor will do what it does. This is why using scenes here won't work. Scenes are direct links between two or more insteon devices and any device linked to the motion sensor will turn on when the motion sensor sends an ON command. And, to repeat, there is no way to temporarily disable a motion sensor. The whole purpose here is to use a program as an intermediary between the motion sensor and the responder devices. There is no scenes between the motion sensor and responder devices. There is no wiring between the motion sensor and responder devices. Using aprogram gives you the ability to decide how and when to respond to your motion sensor, when it sends the ON commands. Sometimes (between sunrise and 11pm) you want something to happen. Other times (between 11pm and sunrise next day) you want nothing to happen. In the end, the program you posted will trigger at sunrise, at 11pm, and any time the motion sensor sends an ON command. Once triggered, it will evaluate based on the total logic in the condition. If triggered between 11pm and sunrise, it will ALWAYS evaluate FALSE, and run the ELSE path. When triggered at sunrise and 11pm, it will always evaluate false (lack of simultaneous ON command from the sensor). When triggered by ON commands between sunrise and 11pm, it will evaluate true (and run the THEN path). If your lights (shower light MB) are coming on between 11pm and sunrise next day, it is NOT because of this program. I can suggest again that you disable this program to see how this changes things. If you disable the program, and force motion in front of the sensor, what happens? Do the lights come on? I suppose it is possible that there are links between the motion sensor and shower light MB that are unknown to you or to the ISY. (There are stories of devices coming from smarthome that have residual links. Or...links were created with another hub, or manually somewhere along the life of the two devices.) Perhaps it is time to remove the motion sensor and shower light from the ISY, perform a factory reset on both (clearing out any possible links), and re-add. Short of that, you could "restore" both devices and see if that helps. If you are in doubt about your program, you can manually trigger the condition (right click>>run (if)), or run either action (then or else). When you do this, does it perform as you expect? Manually trigger the condition (run (if)) after 11pm. Does the shower light MB come on?

Outstanding! A couple of other options to investigate: 1) does your program have any unsaved changes? (When the program is highlighted, look for the little green arrow bottom left.) 2) is there another program causing the light to go on unexpected? (What happens if you disable this program? Do you see any programs being triggered at the same time when you look at the program summary page?)

Scenes, if there, cannot be stopped or suspended by programs. I do not believe your program would cause the light to come on after 11, so I cannot help but suspect there is something else going on, whether another program or a scene. From the admin panel, select your motion sensor. Along the right, it will show you any scene of which it is a part. Let us know what you find out. If it is not part of any scene, check to see if other programs are triggered by the motion sensor.

If your motion sensor triggers the lights on after 11pm and before sunrise, it is not because of the program. Twice I have mentioned the need to ensure that the motion sensor is not a controller in a scene. Do you understand this? Do you know how to confirm this? Have you confirmed this?

I would use "control" rather than "status". It appears that you used the correct "node: (which is "motion sensor"). The Low battery node will trigger when the battery is low. The Dusk-Dawn node will trigger based upon ambient light. No, there need not be a command to turn off the motion sensor. In fact, one CANNOT turn off a motion sensor. Did you ensure you have not added the motion sensor as part of a scene? I cannot speculate on why your program did not work. Feel free to post it and we can look and see something.

I understand that the motion sensor II is not fully implemented yet (due to lack of interface definition). For now, the program solution should work just fine, so long that you can see ON commands from the sensor at the times that you want motion to trigger an event.

If, on the other hand, you are willing to rely on programs entirely rather than a scene (programs can introduce a perceptible delay (about 1sec) in response to motion) then the solution is a little more straight-forward. First, set jumpers as per larryllix suggestion. Second, ensure that the motion sensor is NOT a scene controller. Third, create a program such as (depending on need): if control motion sensor is turned on and time is from dawn to 11pm then turn on light wait a period of time turn off light else turn off light

I would be more curious what affect the mute button has on data transfer.

I was not referring to the stop "command". I understood that there was a question about how to stop (generic term) execution of THEN or ELSE clauses of a 'time from...for' condition. I was trying to propose that one can disable a program around the time when the else clause would normally trigger and that would, effectively, stop the else clause from happening. Equally, one could disable the program at the beginning time and prevent the THEN clause from happening. For example: if time is from 12:10:10 to 12:10:20 then disable the test program else enable the test program would have halted the ELSE clause of the test program.

Actually, I assume one CAN stop either (then or else) by disabling the program.

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.