oberkc

Interesting. It seems that most of the complaints about mobilinc that I read around here are of the android version. Personally, I am happy with mobilinc, but I use android and rely more on widgets and tasker than the actual program interface. Also, I use control from phone or tables very little. When at the house, I have yet to find anything more convenient than a well-located light switch. When away from the house, I find the need to control lighting limited to a few key devices. In case you do not know, many of the apps available are here: https://forum.universal-devices.com/forum/55-third-party-products In the end, I am with lilyoyo1. ISY is for automation. If remote control from a cell phone is a top priority, you may be better served with something else.

It may help to identify your "mobile/tablet". iOS? Android? Other? I have been happy with mobilinc (certainly don't find it "clunky or lacking overall" but I guess that is a very personal judgement) but there are other apps available. Some of those apps are unique to android or iOS. How much automation (versus remote control) do you employ? Are you satisfied using an app on a tablet (smartrules?) to handle the automation?

I suspect that this is consistent with other's experience. Certainly it is with mine. I had believed, up to the point of my system "failures" that devices such as the PLM either worked or didn't...failure was all or nothing. After seeing a new PLM greatly improve reliability of my comms and system, I had to adjust my beliefs.

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?