oberkc

First, i am not sure that I can accurateli infer you full intention fron the program. Is it your intention to turn the fan from low to medium when you press the remote OFF?! Personally, I would probably use scenes to control the fan via keypad and a program to relate remote commands to the scenes. One think that appears suspicous is your parenthesese. (I believe the last one is in the wrong place...should be ahead of AND statement.) I am also suspicous that, somehow, your variable is defined as a STATE type, but without seeing all your programs and knowing what buttons you pressed, it would be speculation on my aprt why your other programs would be running

Mango, if you decide to try the program solution, I want to emphsise the last pont made by larrylix: make sure the buttons are NOT in a scene that includes the iolinc as controller.

Well, broken is relative. Insteon is a known commodity. Broken, to me, suggests that it does not do something that it claims to do. This is like claiming that since insteon does not wash your car, it is, therefore, broken. There are no claims made about scene commands such as discussed. Perhaps a better way of putting is it that insteon is not well suited to meet everyone's desires...not suited for all purposes. Of this, I am more confident. This could be done with a program(s). Then, one would have create the echo>ISY command relationships. There may be some around here that can help with that. I am not one of them.

Yes, it could be done with logic. Yes, trigger reverse is an option. Both have subtle downsides. I prefer the alternate sensor. This is a topic that comes up pretty regularly.

From a purely intellectual and logical perspective, one would want to do this for the same reason that one would want to set a scene members level to something LESS than the pre-defined ON level. If we accept that there are times that one may want to turn on a scene a reduced values, it seems logical that there might also be times that one might also want to turn them on at increased levels, no? Fortunately, I find stusviews assessment spot on....nothing is broken. The insteon design allows for this by allowing the creation of multiple scenes. Pre-define scenes at the levels desired and call it a day. I would add, also, that insteon DOES include the options to redefine scene responder levels, correct? Given this, another question that could be asked is why echo cannot properly interpret a request to set set scene levels to something other than pre-defined levels is not properly executed using the tools at hand...ie, when is the echo going to get fixed? Ultimately, neither insteon, echo, or the ISY is "broken" in this case and expectations of any being fixed are misplaced. Instead, there are existing methods to solve this problem and that is: scenes and more scenes.

Without providing detais and explanation, your best bet is likely going to be to replace your sensor with a different type: normally closed, or NC. I dont believe they are very expensive.

Perhaps I misunderstand your problem, but I have not experienced a case where a program ran but the ISY status did not update. From where are you observing the status? Admin panel? Mobile app? But then, like larrylix, I don't use "fadeup" commands.

No need. Barring comm problems, status is maintained automatically. Switches report status when changed. Programs will update device status.

Further thoughts....is it possible that other program or insteon activity is happening between the separated programs? Might this activity delay the response of the subsequent programs? Have you ever opened an event viewer while executing the goodnight action?

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