oberkc

OK. Is there a question here?

As far as "why" it could happen, this is considered a feature of insteon. For a given scene, you can have multiple controllers, and for each controller different responder levels. This gives one the ability, for example, to have a group of lights have have movie setting versus intermission, based upon which keypad button you press. As with many things, with features come added complexity. Treat the "scene" responder levels as those when reacting to the PLM as a scene controller. Please note, also, that when you selected the controller switch within the scene, there was revealed an option so set the responder levels as the same as the scene. This strikes me as a convenient feature of the ISY that keeps things nice and consistent for those like yourself that want a scene to respond the same way regardless if which controller triggered the scene.

Very strange. Same thing happens when you choose, from the device list, the fanlinc and mnually select the speed? Perhaps, as yoy probably suspect, there is some device failure or incompatibility here. These things have worked for me without any of these kinds of issues.

OK. Have you tried stusviews suggestion? What is not always clear is that, within a given scene, responder levels can be different for each controller. For example, in the "HIGH" scene, you may have the fanlinc response level set to high at the SCENE level, but with response level set to OFF when responding to button A.

Yes, sunny Springfield. Lots of nice places in VA. Hope you like it. If your intention is to use button B to toggle the fan motor, then why are you setting buttons A-D "to a setting"? Have you given up on the one-button approach? What about button A? I thought you said that this was for the fan light? Is this no longer true? Is button A still a controller for the fan light? Perhaps I am being counter-productive and simply need to back out of this as gracefully as possible.

Perhaps I am confused as to what David_Gilbert is trying to accomplish? Four buttons (High/Med/Low/Off)? One button toggling through the speeds? Both?

Perhaps, but the keypad buttons are a part of none of those scenes. (Unless you are talking about a second keypad.)

This is, in my estimation, likely caused by have the responder levels set incorrectly. What is typically missed here is that the levels must be set in multiple places, for the scene (itself) and for any controller devices within the scene. If you want a responder device to go to zero in response to a controller device, make sure you check the responder levels when the controller device is highlighted by mouse-click.

I think you are trying too many things at once. My understanding about the program originally suggested by stusviews was that its purpose was to control fan speeds from a single button. Is that your intention, or are you trying to control speeds via dedicating four buttons. Secondarily, if you are using scenes to control fan speeds, no program is needed. I suspect your scenes are fighting your programs. When you move the slider to "HIGH", the motor turns off?! That strikes me as very strange. I can think of no reason for this other than device failure. Are you sure there are no other programs triggered by "STATUS" of fanlinc?

David, I dont see anything in the program that would explain this behavior. Assuming you have double checke to confirm your pogram conditions are consistent with th recommendations, also be sure that you don have any scene relationships between the button and fanlinc (did you eliminate your original scenes?).

The WAIT at the end of the THEN or ELSE clauses will accomplish nothing, I suspect. I dont believe it will delay the running of the other clauses. I understand WAIT statements can be interrupted by a program trigger and will not cause any further delay, once a program is triggered during a wait period.

This ISY is the only real controller I have used. (While I once used some crude insteon software with a USB-based PLM, it was only timers that it provided.) My impressions of the Vera has always been that it tends to be more biased towards z-wave and less towards insteon. Still, I find the ISY pretty good for z-wave and unmatched for insteon. I understand that the z-wave support in the ISY is still growing and will only get better.

Certainly it is easy enough to distinguish between ON and FASTON in a program and take different actions as a result. I am not so confident that one can create a condition based upon 100% status, but only if arrived to by ramping up. That would be a bit trickier.

When in momentary B mode, the IOLinc will respond to ON and OFF commands. Whether this is correct depends on other goals and faxtors, but it seems unlikely to me that this (or the 2 second dwell time) is the cause of your problems. Still, try 1 second and see what happens if you are unsure. Could this be a mechanical issue with the door? Sometimes, door can physically bounce and cause the opener to sense an overload condition and halt. Does this ever happen when you press the wall switch?

I agree with MWareman for those in a high threat area, but you COULD get by with ISY and geofencing control of garage door in areas where you don't have thieves waiting for every opportunity. If an open door is a virtual guarantee of an intruder, I would not connect insteon or ISY to the door control. For those of us in less threatening environments, I think a location-based opening and closing of the door can be a viable option. I use a combination of factors to decide when, or if, to automatically open the door. The general logic is based on: a) location, that is, connected to home wifi also connected to car Bluetooth c) checks current status of door and sends a signal only if open. I would probably not use location, alone, as a condition for opening or closing the door. My experience is that the combination of Bluetooth and wifi location is pretty robust logic and does not result in momentary crossing signals. I also send a notification to my EMail account when the door has been automatically activated, so that I can check things out if one of those notices comes unexpectedly. Video cameras are nice for this.

Neither the program I suggested, nor xathros' timer program, would turn the light back on. xathros override program would re-enable the timer program when the switch is manually turned OFF.

I would think this issue comes up all the time: there is an extra box location somewhere...now, what can I do with it?!. Yes! Put a keypad or another switch and use it however makes sense in your house. So long that this box location has hot and neutral, put an insteon switch of some time and provide control of something useful.

I also subscribe to xathros' theory that if the lights are already on, there is little harm in turning them on. The opposite is also true, in my mind. If all you want them to do is turn on at a certain time, then turn off 2 hours later, what is the problem with a program such as: if from a certain time (such as sunset -15 minutes in your case) to 2 hours later (or sunset plus 105 minutes in your case) then turn on lights else turn off lights A program such as the one above will turn the lights on at a certain time (if they were already on, does it matter?). Two hours later, the program will turn them off (if somebody already turned them off manually, does it really matter?). I would like the option to keep the lights ON somehow. Check to see if the lights were manually turned ON and, if so, keep the ON until manually turned off. Xathros' example override program appeared to address this issue

Care to share? Once involved, I cannot help but be curious?

Normally, I would assume such behavior is caused by a scene relationship. Are you saying that these devices and buttons are no longer in a scene, that the groupings are cleared, and it still does this? Is there a scene that includes the "one button" as controller. Does that scene include "all buttons"? Are responder levels for all buttons set to zero?

So, you have removed the button groups. What is the problem that remains? Is there some unexplained behavior somewhere?

try first the parentheses. It is my hope that this will work. If so, you are done. But...yes...I like simple better than complicated, all other things being equal.

I have used groupings in the past, as well, but prefer scenes so I do not use them now. Never saw a problem, but never made changes or replaced such a device. Be sure to take advantage of the tools. Select the device in question and it will show the scenes in which it is a part. From the programs list, there is a "find and replace" option that is very helpful for finding where certain devices are contained in a program.

I understand. I suggest, however, that if your intentions are simply to "turn of lights" (per original post), then the only harm is that the ISY will send an OFF command to lights that are already OFF. To me, that is harmless enough. If your new program fails to achieve your goals, you might try this approach as an intermediate step. This could help troubleshooting.

Doug95630 I suspect you problems have less to do about motion sensor reliability and more to do with programming logic. Do you know about parentheses in programs? Try putting parentheses around the last seven lines of your program condition. Alternatively, what harm do you see in completely eliminating the last seven lines of your program?