oberkc

I would say that is not normal. No. Is kitchen cabinets device part of kplga scene? If so (assumed), what is the ON level defined for this device when the scene is selected at the admin panel device listing. Is it set to zero?

As an additional comment, mobilinc for android has a plug in for tasker app. If you are comfortable playing around with these types of apps, you could even add a couple of widgets directly on one of your home screens to set your house into a specific mode.

I dont control thermostats via ISY, so I am a little uncertain whether wht you desire would require a program, or whether it can be handled entirely via scene. (hopefully, another can verify whether thermostats respond to scene OFF commands.) Given that you wish to interject some timing into your startup sequence, however, tend to point to a program as a proper solution. The MAIN ON/OFF button on a six-button keypad is treated by insteon as a single device, one button turning the device (or scene) ON always, and the other button turning the device (or scene) OFF always. The status of this main button can also be used as a program trigger. Given the criticality of having water supply on prior to heating, I would probably introduce a series of programs to doublecheck that the water is, in fact, on. To handle the secondary buttons, I would probably use several scenes to control the interraction between the buttons. Mobilinc does not REQUIRE a monthly fee. I use mobilinc without subscribing to the connect service. Still, you can control what you want directly via the admin console or dashboard. For your situaton, it comes down to whether you find the user interface adequate, or prefer that of a specific app. What you want to do is well within the capabiliy of the ISY. Even the most basic version will be adequate.

"From what I have read so far in the forums, you can't command a "controller", only a responder. " Actually, one CAN command controller, but it will affect only the individual device, and not the entire scene for which it is controller, To remotely control a scene, the ISY has separate program statements for that. Besides the additional buttons, there is not benefit to going to the eight button keypad. Any button set as controller in a scene is, by default, also a responder in that scene. What you wish to achieve is relatively simple for the ISY and insteon. The most difficult part, in my mind, will be setting up a static IP address and port forwarding rules for the ISY.

When using programs to initiates a scene, turning on a scene controller will not work. Devices act as scene controllers only when when activated directly (manually). The program should activate the scene. I forget the exact syntax of the program statement, but dont believe it includes "adjust". It looks more like: Set scene 'morning time' to ON.

I believe Elk sensors can trigger ISY programs, which means they could, indeed, trigger lighting. Or notifications. Insteon door sensors could do the same thing, but it would be nice not to have two sensors on each door. My experience is that insteon door sensor batteries last a bit longer than a year. An alternative to insteon battery sensors would be a simple contact sensor wired to one of those Smartenit EZIO modules. No batteries required. I think there is one unit that can take up to four inputs.

I don't know about having everything in the same "family", but having devices that can communicate with your controller is nice, in my mind. With the ISY, you can easily speak to insteon and Z-wave devices, with an Elk security system, and (with some knowldege) darn near anything that speaks network. The advantage of this is, for example, the ability to push a single button and have your house turn into vacation mode...lighting schedules, water shutoff, thermostat settings, things like that. Or, exploiting security sensors to trigger lighting (no need for separate motion or door sensors). To me, the integration is all based on the controller device, in this case, the ISY-994. Cameras, on the other hand....I have never seen much value in that. The only thing that I can think of is that some apps offer the ability to view video feeds while simultaneously controlling insteon devices. Perhaps that is of some value, but it has little to do with integrating insteon communication with a camera. Furthermore, with some tablets offering split screen capability, one can simply run two apps, one for the video and one for insteon. Whether this is enough value for you, only you can decide. Personally, I don't integrate thermostats with insteon (not worth the extra dollars to me to save less than a minute per year). If I had a security system, I WOULD value using the sensors for double duty.

In my experience, the newest outletlincs do NOT have the sense current problem of the old versions. I have a very-low LED bulb in one outletlinc, and it shuts off completely. No glowing.

Sounds like it may be time to consider the possibility of a comm problem. A simple experiment would be to find an extension cord and plugging into an outlet on the same circuit as the keypad and temprarily plugging in the plm to that. Were that to solve the issue would be an indication of a communication problem.

"The ISY thinks the keypad is working properly; when I turn off the Living Room Wall Switch from inside the Admin Console, the button on the keypad shows off. But it is still lit. " That statement makes me suspect communication problems, or link record errors. I would be comparing link records between keypad and ISY, perhaps restoring the device if necessary. Do you have latest software for ISY?

The only concern I have with the hardware setting is that a door partially closed will show CLOSED from a sensor perspective. From a security perpective, I find this less desirable. Regarding the program, I am having trouble finding any flaw. I expect this program to do as your stated desires suggest. My inclination would be to start some basic troubleshhooting investigation. - does the light on the iolinc reliably reflect the garage door status? - does the status of the ISY state of the sensor reliably represent the state of the iolinc?

Hard to add anything. I think teken has said all that needs said.

If you are intending to use the program to trigger lights based on certain conditions, then take the sensor out of the scene, yes.

Like I said earlier, I don't believe momentary mode has any effect when controlling the device directly. Regardless of mode, only an ON command will trigger it. Added: for the momentary modes to be enforced, one must be using scenes. If the use of momentary modes is important (such as limiting response only to OFF commands, or responding based upon sensor status), I believe the relay must be in a scene, and the scene be controlled, whether through mobilinc, a program, or an insteon controller.

The only scene in which is my relay is one where the keypad button is controller and relay is responder. If you have no need to control the relay via other insteon device, I see no need for a scene. Keep in mind that the various momentary modes may not be enforced if controlling directly. As I understand it, when controlling directly, only an ON command will actually trigger the relay. OFF will not actuate the relay. It is best for confirmation of this if this turns out to be important in your case.

Call me stubborn, but I continue to believe that this should not be necessary, and, in fact, is NOT necessary on my phone with mobilinc. I open mobilinc, select the relay, choose proper (on) command. Done. It is not dependent on the status of the relay, percieved, real, or other. Mine is android version. I can only assume you are on iOS and that it must be different in this regard.

For any given scene, there will be "controllers" and "responders". Furthermore, for any given scene, the PLM is ALWAYS, by definition, a "contoller". In your scene, therefore, you have two controllers. One is the motion sensor. The other controller is the PLM. Your scene has one responder device: the switchlinc. Remember also, with insteon, the response (ramp rates, ON levels) can be unique to each controller device. In your case, therefore, you can define a different switch respnse if your switch is responding to the PLM compared to the response to the motion sensor. Whan an insteon program commands a scene to turn on, the responders in that scene will respond at the levels defined for when the PLM is controller. When a defined scene controller (motion sensor, in this case) commands a scene to be on, the responder devices will respond based on the defined level for that specific controller which can be different than the levels for the PLM. So, construct for the given command is: In scene <scene controller> set <scene responder> xx%

I do not believe thay are the same. The "pro" refers to a specif version of an app. "Connect" is in reference to a service.

I dont know if it has been suggested, but I would definitely be checking the logs to determine if there are other programs, beyond the two query programs, that trigger around 0257. Imwould also exploit the find/replace function to be sure that I knew with certainty which programs include the IOLinc.

These are my fears, as well. Hypothesise...if a garage door is open and one commands closure, what happens when the door closes and the sensor (controller) changes state? Would it not issue a new ON (or OFF, depending on sensor) to the relay (responder), potentially causing the door to open again? While it may be possible to avoid this with great care applied to the momentary modes, I am missing the purpose in establishing this scene relationship and it appears to me to be all risk and little reward. I dont think we can discount this as a potential contributory factor. On the other hand, I am a little fuzzy on whether a query would cause the door to open solely based on the scene relationship. The query, I understand, potentially updates the ISY status and would not necessarily be the equivalent of a scene command, so I assume that this would trigger only programs, not scenes. Whether it is scenes or query programs or something else, unless there is good reason for having them and that the unintended consequences are understood and mitigated, simple is better. It may be time for blackbird to start fresh with this IOLinc. There appears to be a lot going on here.

It is getting late, and I may be having a brain cramp, but i dont think one wants the relay and sensor in the same scene. Would not one run the risk that the sensor triggers the relay? At my house, I have two separate scenes for eac button. One scene has button as controller and relay as responder. Then there is a second scene with sensor as controller and button as respnder. I have no scenes than include both relay and sensor.

In the same scene?

Point of clarification...do you want it to wait for one minute before checking again, or to send a notification if motion is sensed a second time, within 60 seconds of the prior motion detection. I am not sure that there is a way to "check again" for motion. The sensors will send out motion when detected and the odds of motion being detected EXACTLY after sixty seconds are next to impossible. The thing one can watch for is whether motion is sensed within certain time ranges or intervals. so...if motion is detected 70 seconds later, you want a notification? If 90 seconds? A half hour? Better, in my mind, is to see if you have multiple detections within a short period (minute sounds good), rather than random detections many minute or hours apart.

I like LarryLix proposal, but suspect there might be one extra step to the proposed "Motion Notify" program necessary: Motion Notify (disabled) If Control 'Motion Driveway - Sensor' is switched On <<<I would add these three lines so that, once enabled, the program will actually trigger Or Control 'Motion Patio - Sensor' is switched On Or Control 'Motion Front - Sensor' is switched On Then Send Notification to 'xxxxxxx@gmail.com' Else ----- I do not, because I don't desire to have notifications. If I did, however, I would take an approach like suggested by LarryLix.

Any reason to believe it won't work? Just beware...secure, non-secure, HTTP, HTTPS, mobilinc connect or not...these are common points of confusion. If you run into problems, don't hesitate to ask. The support from universal devices and mobilinc is the best. They will get it working for you and answer any questions you have if the various instructions and forum support can't get you going.