oberkc

Hey jerry, While I have never noticed programs, themselves, causing much delay, it seems to me your exeriments are petty conclusive. But...15 seconds!? Wow. It is almost hard for me to imagine that separating programs would introduce this kind of a delay.

"Normal" refers to the sensor state when sensor and magnet are separated. "Normally closed", then, is a sensor whos contacts are closed (zero resistance) when so separated. With the IOLinc, ON is when the sensor is closed. If you desire to install your sensor such that the magnet is seprated from sensor ("normal" condition) when the door is open, and an open door to be reflected by ON with the IOLinc, you would need, therefore, a NC sensor. Whether one way or another is backwards depends on viewpoint and installation.

Substitution variables. Not something I have ever used or needed, but I may try one out. I understand the "#" represents the address of the device that causes a program to run, correct? Thanks for the tip!

Nothing is jumping out at me as far as ideas to reduce number of programs. My only thoughts are to put all these into a program folder for organizational purposes only.

That is what most do, I suspect. Add an insteon motion sensor....door sensors.....fun times!

For me, remote control via phone is a minor concern. I don't have a lot of interest in such things. As others have mentioned, for android, it is the integration with Tasker that most excites me. This provides the ability to automate things based on cell phone conditions, such as location, connection to a car Bluetooth, things like that. But, for those few devices for which I occasionally control via cell phone (garage door, outside lights, door locks) I like the widgets that one can create, either through tasker or directly with mobilinc. I do not like the idea of opening an app and navigating through pages just to turn on a light.

Jeff, I use mobilinc app (android version) to gain access to my system. It DOES provide ability to rename states. I use it for doors and locks.

All you are trying to do is manually control an irrigation zone from a keypad button? Sounds like you have done everything correct to me, but make sure you added the KPL button as a "controller" of the scene. I believe controllers show up as red in the scene listing.

Yes, that would explain things. Also, if they come on at night and sunrise occurs before they turn off, they will remain on.

You can have multiple controllers in a scene, even if the controllers are motion sensors. Yes, the program can cause perceptble delays. You may also notice that you program, as written, may cause the lights to come on during daytime hours (edit...looks like this was caught before I could post). Using a scene to turn them on, however limits the ability to constrain when the lights respond, other than based on the built-in light sensors. You could not, for example, limit response to sunset to sunrise. Consider, also, the possibility that you could use a scene to turn them on, but a program to turn them off. In my mind, this can provide a nice combination of speed and flexibility.

Thanks for the clarifiction. While it might be doable with one (control on AND control not off) the point was more to point out that this is beyond the power of scenes.

If a keypad button is controller of a scene, turning on the button will turn on the scene and turning off the button will turn off the scene. As LeeG suggests, if you set a button to non-toggle mode (off or on) pressing that button will always turn it off (or on). If you are looking to turn one scene on with a button, and a different scene off with the same button, this will require a program.

Sounds as if this button is configured non-toggle OFF. Do you remember doing this? Assuming I understand correctly, your scenes look correct. When the scene name is chosen, this is as if the PLM is controller and the two buttons are responders, with levels for each. When a controller device from a scene is selected, only the remaining devices would have a responder level. When you chose the OFF button, only the ON button would have a responder level setting. as for (2), stusviews is, of course, correct. However, a little creativity may solve your problem. You could actually convert you 6-button to an 8, but leave the physical buttons in place. The old OFF button now covers "new" buttons 7 and 8 (or g and h). Using scenes, where g and h are always included and identicially configured, you could use the lower button to toggle things on and off, just like any other button. I find scenes to be quite powerful and effective. While I am not confident I understand WHAT you are trying to achieve, it sure sounds like scenes are a good option here.

more generically, the wait is aborted any time that a program triggers during a wait period and evaluates false (when wait is in THEN path). If a program is triggered and evaluates true, the wait is halted and the entire THEN statement starts anew.

try something like: if status sensor is open then wait 15 mintes send email else nothing

Naptown, I fear this is becoming more complicated than necessary. I don't believe that there is any need for waits or variables. Let's think this through a bit more. First thing, the only trigger we want is when based upon the geofenced area, right? Once we leave, then test the other conditions which define whether the house is secure, right? We have no need to trigger the program because doors or windows change state, correct? Next, is it correct to assume that matthewphone = 0 is away and that mollyphone = 1 is home? And that you only want notifications when both are away? Is it correct to assume that there are only two values possible for either variable, 0 and 1, meaning away and home? (Curious as to why you chose "= 0" for one condition and "not = 1" for the other condition?) Why not: If $Matthew_Allen's_iPhone_Home is 0 And $Molly's_iPhone_home is not 1 Then run next program Else nothing Next program (disabled) if Status 'Kitchen Slider-Opened' is On Or Status 'Basement Slider-Opened' is On Or Status 'Front Door-Opened' is On Or Status 'Garage Door Sensor Single' is Off Or Status 'Garage Door Sensor Double' is Off then send notification else nothing

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.