oberkc

I have found that the togglelincs are not the easiest on which to initiate the fast on. The two presses must be done pretty quickly. Perhaps that was the problem? For what it is worth, one could also create a programmatic solution to this problem that would allow greater time between the first press and second.

Togglelincs DO have a fast on command, including relay versions.

I believe there is a trial version of mobilinc (called mobilinc lite). It limits the number of devices you can control, but at least you will be able to determine if it works for you and you can get it set up properly. Are there other methods? Probably. Some have reported luck with tasker. You can access the ISY admin page on and android web browser, I believe. There is a whole section on the forum regarding third-party apps.

I think there is some confusion about the purpose of the "in scene set xxx/yyyy to 50%". The confusion is, based on my reading of this forum, pretty common. Let's take your first "set scene" statement, that runs after 4h30m. That statement: In Scene 'Bathrooms' Set 'Bathrooms / Downstairs Bathroom' 50% (On Level) will do nothing more than change the responder ON level of a device "Downstairs Bathroom" to 50% when responding to a controller device (or scene) called "Bathrooms". It will not actually cause the device to immediately change to 50%. Once changed, the next time the device (it could also be an ISY scene name) "Bathrooms" is commanded to be ON, the responder device "Donwstairs Bathroom" will turn to 50% level. Remember, a scene can have many controllers and many responders, with each responder having a specific ON level (anywhere from 0 - 100%) defined for each controller. If, for example, you have a scene called "Bathroom" that includes a device called "downstairs bathroom" where the responder level for that device defined at 50%, turning ON the scene will cause the "downstairs bathroom" device to turn to 50% (the defined ON level). Turning ANY scene ON will cause all included device to go to the defined ON levels, unique for each controller in the scene. Back to your first command after the 4:30 wait...all it did was adjust the level to which one device would turn ON if/when that scene was ever commanded to turn on (which did not happen until 8h30m after that. No. That statement would only cause the light to turn to the defined ON level, now 50%. While my initial reaction would be to think this might be the most convenient way, it is certainly not the only way. In fact, you could use your approach, but it would require several more program lines and have, in my estimation, little benefit.

Are you sure that is what you did? If you judged the outcome after 4 hours and 30 minutes, you might reach that conclusion, but you might also be wrong. Your program, as written, would not have any affect on actual lighting levels until 13 hours (4h30m + 8h30m). Your program will NEVER brighten back to 100% (all your statements set the levels to 50%), and I am curious which of the statements you expected to do so. When you say a "few" hours, do you not have a specific time frame in mind? My temptation would be to create a couple of scenes: Bathroom50% and Bathroom100% with obvious responder level settings. Create a program: If On Fri From 6:30:00PM To 11:00:00PM (next day) Then Set scene bathroom100% to ON Wait a few hours Set scene bathroom50% to ON Wait so many hours Set scene bathroom100% to ON and so on else nothing

Wait statements in a single program, or separate programs run at discrete times are the two options that come to my mind. I understand that you want a set of lights to "dim" (turn on to) 50%, then gradually (2 days?!) increase to 100%. Your program turns the lights on to whatever level they are currently set, then sets the responder level to 50% then turns the scene on then sets the responder level to 50% (again?!) then turns the scene on then sets the responder level to 50% (again?!) then turns the scene on. I see nothing that increases brightness levels to any value other than 50%.

Are you certain that the door will always be closed when the machine is running?

This is a powerful feature of insteon, where one can set dimmed (or off) ON levels that are unique to each controller device.

Only subsequent.

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.