oberkc

There is no adding range extenders, nor no need to add range extenders. Plug them in, they start extending.

I can speak mostly about mobilinc, but I believe this applies generally. Apps that integrate with ISY use the insteon scenes and programs from the ISY controller. From an insteon standpoint, the app are little more than an interface to the devices, scenes, and program created by the ISY-994. The bigger point is that video camera images do not rely on anything from ISY integration, unlike anything insteon. As others have pointed out, the ISY (via network module) CAN provide some integration between camera triggers (motion, night) and can potentially control cameras, but this has nothing to do with viewing of the imagery from those cameras.

Normally, I would agree with xathros on this one. However, I suspect you have some factors that come into play here that are making normal methods not best here. I am in a similar situation as you. While have had fanlincs for a while, I recently installed my last one, and, for the first time, have interest in control via moblinc. (Unfortunately, I use the android version, which I don't believe has a "dashboard".) The problem that I am running into is that I want to use the interface that appears associated only with the fanlinc directly, which is the ability to set the fan on HIGH, MEDIUM, LOW, or OFF without having to navigate to multiple scenes. I want, simply, to select the fan, and be presented with the options to select any speed, or off. I suspect this is your desire, as well. Mine shows up as a nice slider on android. There appears to be no slider interface when using scenes...there is no such thing as a MEDIUM scene setting, or HIGH, or....etc. Given this, I am having trouble finding a way around using a program such as the one you have created. Your approach, assuming a desire to exploit the mobilinc interface for the fanlinc, is the best I have come up with so far. As an aside issue, if your concerns are unconstrained by mobilinc, you can actually sync buttons and speeds with a single scene. Create a scene with the four buttons (ALL AS CONTROLLERS) and the fanlinc as responder. For each of the controllers, you can set the remaining device responder levels, and they can be different for each controller. Choose the HIGH fan button as controller, set the other buttons responder levels to zero, and the fanlinc to high. No need for separate scenes.

They would be set up on your mobile app directly, without any intervention on the part of the ISY controller.

There is not doubt in my mind that the ISY can handle this. I think, too, that you will find that it is not so hard to create these programs. I have a couple that are very similar. There is already a series of programs that turn the variable to zero when the switch is manually turned off. Expanding that series to include other switches as input conidions would work. Alternatively, I could see a program such as this one working, (at least for zeroing out the variable), but you would still need similar programs to the original series to set the variable to 1. I simply see this as an extra program...but, yes, it could work. I tend to agree with this, but some tend to want to minimize insteon communication traffic. This may be where we depart. There needs (in my mind) to be three variables, for three lights. I thought we wanted to judge to turn the lights off on an individual basis, if one was on originally and the door closes, turn off the other two and leave the one on. This is why there are three programs...on for each light.

I am not sure, but believe that the outletlinc was designed without being capable of being a scene controller. By what means do you intend to turn on the outletlinc?

not so much a disagreement but misunderstanding on my part. I did not understand your meaning of "manually". As I believe you have figured out, I think you will find xathros' suggested program will not toggle a variable change when the Light1/2/3 are changed as a result of a scene command. Consequently, you will need additional conditions for this. Yes, there is a STATUS condition which would trigger upon any CHANGE in status, regardless of reason (whether direct control, scene control, program, etc). Unfortunately, it would also trigger when the sensor program triggers a change in status, which is something that one needs to avoid in this type of scenario. It is not the lack of a global condition that is the problem, rather, it is because of the need to be more specific about which causes of status change should trigger a variable change. Because you want the variable to change only when someone physically pushes a button (either directly, or through a scene relationship) and NOT via the door sensor program, STATUS would not work here. Furthermore, use of CONTROL has the benefit that it would restart the timer should the sensor send another ON command during a wait period.

All interesting questions, but this was not part of the stated requirements. In my mind, questions like this are good to ask oneself when deciding how you want your system to respond. Without thinking too much, I would be concerned about using status for the variable trigger, because the sensor program itself is going to cause a status change. Since mserrar only wanted to disable the response when the switches were directly controlled, I think "control" is the better approach at this point.

mmmmm...do you think? One of the difficulties I see here often is that folks post a program and ask why it doesn't work, without stating clearly what it is that they want it to do. It is difficult answering such questions without an understanding of the purpose of the program. Sometimes, you find out, they really haven't given it enough thought. I am glad you have thought about your requirements to this level of detail. xatrhros' response was near exactly what I would have suggested, except for a few trivial variations. Your requirements were certainly more complicated than I had first envisioned. One question... xathros: Should your "lastly" program variable condition be equal to 0 rather 1, to indicate that the switch was not manually turned on?

This error suggests that something is causing communication problems between the ISY/PLM and the IOLinc. I do not believe this has any relationship to the soldered connection to the remote.

I assume that the can lights and toilet lights are different devices? The lack of an ELSE statement is, in my estimation, not a factor here. The first thing that comes to mind is that the toilet lights are changed to something below 61% while this program is executing, thus halting the execution during one of the wait statements. Given your broader understanding of your system and use, is this a possibility?

I should probably clarify the use of variable versus program as a status indicator. There could be a difference in using programs versus variables as a program condition, depending on whether you want to use that condition as a program trigger. Depending on whether your variable is integer or state, it can act as a trigger or not. Programs as a condition do trigger, I believe, a program evaluation upon change of state.

If all you want to do is turn some lights on when the sensor status changes to ON, and turn some lights off when the sensor status changes to OFF, then I suspect my little program would work. If you have additional constraints or conditions, let us know. One thing you can use as a program condition is the status of a program (true or false). The program I posted itself can, thus, act as a status indicator for your sensor. This program will evaluate TRUE (then clause last ran) when the sensor is on, and FALSE (else clause last ran) when the sensor is off. There is little need to create a variable for this if you don't want to.

I don't believe there are "nested" conditions. Out of curiosity, what is the purpose of the variable? Is it a state or integer variable? What is wrong with a simpler program, sans variable: if If Status 'sensor' is On Then Set 'Light 1' On Set 'Light 2' On Else Set 'Light 1' Off Set 'Light 2' Off

Ok. Then it sounds to me as if the scene definitions are wrong, most likely. My guess is that the responder levels are not quite right for some of the controllers in some of the scenes. Remember, a scene can have multiple controller devices included, and responder levels can be different for each of the controllers. For a given scene, select one of the controllers and view the responder ON levels. Select another controller in that scene. Are the responder levels the same?

So you are doing it by a program? Feel free to post it. Otherwise it is just speculation. These buttons are not part of any scenes?

Well, I must have misunderstood. I would, then, be checking scene definitions (checking all responders to all controllers) and double checking to be sure you have none unexpectedly triggered by any of the keypad buttons. I am not sure that i can be much more specific unless I know how you intend to configure your keypads. One button for the light? One button for each fan speed? One button for off? Each speed button pressed turns the others off?

I believe it works just as you hope. If a button is lit, it is on, regarless of how it became so.

In which case, you may be risking damage to your fanlinc by powering it from the KPL. I would definitely be checking this out and ensuring that the KPL is NOT receiving power through the KPL.

It really should not be difficult to reconfigure a couple of wires to provide constant power to the fanlinc. Simply remove the wire that is currently connected to the kpl red wire and reconnect it to the wire that is connected to the kpl black wire. Cap the kpl red wire.

I am sorry...I meant to ask if the keypad is a dimmer version...not the fanlinc.

I suppose it is possible, but is sounds like an unecessary complication and risk. Are you concerned about the difficulty of wiring and supplying unswitched power to the fanlinc? Is the fanlinc in question a dimmer version? This could be a problem.

I suppose it depends on how you have established the relationship between keypads and fanlinc. Are you doing this all with scenes? Part of your description makes me wonder if you have some programs in play here. Also, in the scene relationships, check the ON levels for all the responders to EACH of the controllers. Are some of the ON levels zero? It also sounds as if you have the fanlinc powered by the one keypad. Is this possible? Are you certain you have uninterrupted power to the fanlinc? What is connected to the red wire of the wall-mounted keypad?

Yes, i saw the changes, and the fact that it was now apparently working as expected.

I would ask what you mean by "first two conditions". Which is the first condition? Which is the second?