oberkc

I use mobilinc, as do many, along with the many who seem to use agave. I do NOT use mobilinc to view or control cameras. I use IPCamviewer. There is no subscription. Unfortunately, it seems many of the cameras are moving to cloud-based, which can introduce difficulties with using a generic camera app. This can limit your choices of cameras, but I have learned to work around it. I have never felt the need to have cameras and home automation on a single app.

There is a "find and replace" option in the program listing. Right-click on "my programs" then go through the dialog boxes to identify the keypad button in question. From there, it should identify any program that includes that button. Optionally, check the program summary list immediately after controlling the scene. If a program ran, you should be able to identify it as being the one last run at the time you pressed the button.

It may also help to be very specific on your use case here. While it may be possible to “control” (in some way) the camera with ISY, you wont be viewing the video while doing so. If your desire is to be watching video while sending PTZ commands, I am not convinced that this is the best solution.

Also, be aware that there is a new device coming at some point. It is called the "Polisy". I understand it would be a turnkey device that would be in place of the RPi computer, already loaded with the necessary software. I believe the camera node server and blue iris are two different things. Blue iris is separate software one runs on their computer to monitor (among other things) security camera video.

Yes, the timer would halt and the ELSE clause run.

Perfect!

Yes. Details are important in this game.

Okay. Assuming button a always sends on commands and button be always sends off commands? If so, I would create a single scene with button a, button b, switching to, and keypad button, all devices would be as controllers. Ensure you remove them from any other scene in which they may be involved. Verify proper response levels for each controller in the scene. Obviously, button b would not need to be concerned with responder levels, since it always sends an off command. If button b is configured and, set the responder levels to button b controller as zero, or off.

That is disappointing. I have been contemplating doing a similar thing at my house and assumed I would use a program such as you have tried. Perhaps I will give a shot and try to figure it out. Certainly, a programmatic approach should work as well. The problem with a programmatic approach in combination with an existing scene is that the light will first respond at the scene level then ramp down to the lower program level. That might be unacceptable to some.

This might cause some complications. Since, in this mode, each button toggles between sending ON and OFF commands, hitting the button for the ON scene might turn it off half the time. I don't recall, but the remotelinc might be configurable to be in "non-toggle" mode, much like a keypad button. I would have to check the manual to be sure. If so configurable, this might be a good idea for this application. Alternatively, depending on your use for the other remotelinc buttons, you might also consider putting it into 4-scene mode. Have you seen the "cookbook" and wiki? My initial thoughts would be to create a single scene, with all four devices (switchlinc, keypad button, remote button1, remote button2), all as controllers. Configure the responder levels (ON, RAMP RATES) as desired, including the second remotelinc button ON level to >> 0 (or off). Verify that the responder levels to each of the controller devices are configured similarly. If you are having intermittent problems, I would initial consider communication problems. It may not be a configuration issue. When things work "sometimes", I tend to suspect interference with insteon communication. I would expect that this would result in the KPL not controlling the other devices when trying to turn them off. What are your thoughts for setting it up this way? As a rule, any given device can be controller only of a single scene. It cannot be controller of multiple scenes. Given this, you could create a bunch of scenes, one for each of the four devices, a single scene (with all as controllers) or somewhere in-between.

Not sure I am following everything. (it is late and I am not in the mood to think too hard at this point.) My initial question: in what mode is your remotelinc? If I recall correctly, it can be set to four-scene (two buttons on/off for each scene) or eight scene (eight buttons, all toggle on/off). Setting this up will likely depend on how you have your remotelinc configured, and which buttons you are using to control the scene.

I could be wrong (did not test it out), but this looks pretty straight-forward compared to the v4 approach. Create a program action, your devices, set [device in question] , on level > xx%. Doing so creates an action that looks like: Set 'device' on level xx%

If you are on ISY software v5, yes. If on v4, no (at least, not simple).

Feel free to try my suggested program, or not. Yes, a variable solution could work, but this will add additional layers of complication and programs that (in my mind) are likely unnecessary. Yes, I understand your problem, and it is my hope that the use of "control" condition would solve this problem. Your description leads me to believe that your program is based upon a "status" condition. Of course, you have not posted your program, so this is all assumption. Another feature you have not mentioned is whether you want the lights to automatically turn off and under what conditions. I did not address this in my suggested program.

You left out some details (are you using an IOLinc sensor for status? Is ON=OPEN? Posting your programs?) Remember, also, that for most Insteon devices, there is a difference between a "control" condition and a "status" condition. These two conditions trigger a program differently. For your situation, a program a simple as: if time is from sunset to sunrise (next day) and control 'garage door' is set on then turn on lights send notification else nothing

Consider the possible causes, then devise experiment to test for each. - Is the ISY seeing on/off of sensor? If not, consider communication problems - if seeing on/off, is program triggering? If so, is it triggering TRUE? Check admin console program listing, and identify when last run and status. - if triggering and executing TRUE (then), are you still not getting notifications? Manually run THEN action from admin console. Still not notifications? Consider possible error in program or notification settings. Have you saved your program?

The only place I know to get the various versions is to go to the “current releases, betas, and bug reports” topic. Scroll back far enough and you will find the announcements for the various versions. i doubt that it is required to get 5.09 as an intermediate step to the latest version. Instead, you can expect a bit of work in making the transition from 4.x to 5.x. Hopefully, others can correct me if I am mistaken.

I did not even recall having to create the scene. I thought you could create such an action for any individual device, whether in a scene or not. I guess I remembered incorrectly.

My understanding from your original post was that you desired to change the response of the light when you manually activate the switch (local response). I am not sure that this would be done by creating a scene. In version 4 of the software, however, programmatically changing the local response rates of a device was done via an action to a scene. IIRC (I am no longer running v4 software so this is all from memory), if you were to create an program to run at a certain hour, choose an "action>>>adjust scene". In the first scene box, choose your specific device (not an actual scene, but the individual device). In the second scene box, choose the same device. In the action, choose the on-level (or ramp rate or whatever) that you want to be in effect at that certain time. If you want to change both ramp rates and on-levels, you would create two actions.

First, this may be different syntax depending on whether you are on software v4.x or v5.x. Second, this is from memory and I think from v4 software. In general, to change the local on level for a switch, you use the scene action that goes something like: in scene (name of switch) set (name of same switch) level to xx% I think the approach is similar in v5 software but the wording is a bit more intuituve.

I have not noticed that as much. I guess I notice more the other side (my perception of overuse of variables). Perhaps I am seeing what I want to see and the other side makes less of an impression? First-world problems.

Paul, the original purpose was to have a separate "close" and "open" statement to be used by alexa. I believe that the point was to tell alexa to close the door and, if the door was already closed, to do nothing. Alternatively, telling alexa to open the door would not cause a door already open to be closed. no problem I don't believe that this is a contributing factor. Should not use latching. Since you tried momentary C without success, I would stick to A or B. This is how I do it, using a keypad button as scene controller and relay as scene responder. I did not think you wanted to do this. I suppose you could create a single-device scene with only the relay as responder. Have your program command the scene. Perhaps this is a good idea. I have always had a recollection that the IOLinc modes were only in effect as scene responder, but others have corrected me when I bring this up. But, I have come to the age where I remember things that did not happen and don't remember things that did happen. In the end, I would stick with your two programs as is, but disabled. Call those programs as needed from Alexa. See if this works.

On the other hand, I generally prefer to use variables only when other practical solutions don't exist and to use as few programs as possible to get the job done. I believe that noremac's problem can be solved with a single program and no variable, so this would be the choice I would make if true. It seems to me that many use variables where none are needed.

My fault. These programs must be disabled. What is likely happening is, when the sensor changes state, it triggers both programs. You only want these programs triggered by a call from your echo alexa, not self-triggered.

Depending on the mode (momentary), the IOLinc can turn itself off and respond only to ON commands, only to OFF commands, to both, or can be configured to "latching" mode.