oberkc

Exactly!

I suspect you have the best solution. I am not sure in today's environment that I would trust a software-based ability to shut down a camera. Disabling power seems like the best option to me, and you have come up with a creative way of doing it. I have been abusing the best buy return policy. I have tried a FLIR Lorex camera, but found it, too, relied on the cloud. Even though I could see the image on my IPCamViewer, it was through the lorex servers. Camera returned.

It may be enough to change "control" to "status" of your existing program, but there may be some edge cases where the lights are turned on for some reason and mostion is never detected. Don't think variables are needed, but others might like them for some reason. Try something like: if status light1 is on or status light2 is on or status light3 is on then run next program else nothing next program: if status motion sensor is off then wait 10 minutes turn off all three lights else nothing (This approach requires that you have not disabled the OFF commands from the motion sensor)

I don't use the portal, but assume it is there as a bonus convenience for you to view your cameras remotely and securely. Does adding them to the portal give you an IP address for each camera? I use ipcamviewer to view all my cameras. Unfortunately, many of the latest generation of cameras are designed exclusively for use with the cloud, and that often makes them unavailable to many of the third-party apps. I continue to resist the use of cloud services for continued viability of a product (echo being my lone exception). One must be pretty selective with cameras today, unless one is happy using the camera app and cloud from the same company.

I know of no camera that would show up on the admin panel or that can be added to insteon scenes. I dont believe there is any connectivity between isy and cameras, short of creating a network resource.

1. Links from manual process? Residual links from prior system? Failing PLM or comm problems? 2. Not that I can think. 3. Yes. 4. 5. Some devices are part of more scenes than others?

I think you sell yourself short. I suspect she (and your son) use your system every day: light switches (and thermostats). You have created an automated home where the automation is invisible to most people. Is that not what most of us strive for? They don't use mobilinc because there are easier ways to control your home.

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.