oberkc

The theory is that "control" will trigger whenever either (or) either of the switches is turned on manually. When that happens, the timer program, if it is in a wait state, will halt, and the program run the ELSE clause (which has nothing in it).

The only other thing I can think is to choose the questionable device and "show device link tables" then "compare". If there are mismatches, once again "restore" the device.

For a given H button, have you looked at scene membership...."is controller of", "controlled by"? When you press the H button, do devices come on that are not listed in one of the scenes? Have you observed your program status list when you press the H button? Do any programs activate? Open an event viewer. Press one of the H buttons. Do you see any signs of an X-10 address? There is nothing in my experience where devices respond to other devices without a reason such as being in a scene, a program, or having X-10 addresses assigned.

I understand the scene test is not conclusive...only an indication of the quality of communication. Sometimes, too, the devices respond as expected, but the return confirmation fails. This would, I understand, cause a failure of the test. It is also, in my mind, something that should be corrected. Another thing that can cause a failure is if you have programs enabled that are triggered by the devices in the scene test. Make sure you disable any such programs. Finally, I have found it necessary to run a test several times, and am generally satisfied if it pass most. Do you notice any particular slowness in the response by your devices? Is it near instantaneous?

Other than those goofy, toyish buttons, I don't see anything remarkable. A button besides your bed that, when pushed, turns on some lights and coffee maker. A button by the front door that advises you when your daughter gets home. Did I miss something?

It sounds like you are wise and practical. I am with you regarding the price of devices. I expect that smart devices will not last as long as the dumb ones, so there will be a noticable cost maintaining your system as devices fail. Still, I enjoy conversations about this topic, and the general state of automation. Given the recent proliferation of protocols, and given things like the new apple "home kit", one capability I value highly (and suspect the marketplace will reward) is the ability to integrate different types of devices, beyond insteon. I suspect prices will come down on these as competition heats up. In fact, I was shopping recently and stumbled upon a random clearance table of stuff, and saw a couple of z-wave modules for about $20 each. Back to the ISY, as much as I have enjoyed this thing so far, I believe the potential is still relatively untapped. The introduction of the z-wave module for the ISY and the initial inquiry into the home kit and insteon/microsoft partnership can potentially be the biggest benefit of having an ISY. This could let you pick and choose from a wider assortment of devices (beyond insteon) and choose those that meet your needs for price and value. Over time, it could be cheaper overall for those with an ISY than those without if one is a careful shopper.

I would use a program. If Control switch is switched on Then Wait 10 minutes Set switch off Else Nothing

At the risk of repeating some of xathros explanation... Which is, as explained by xathros, what the CONTROL condition does. Well, that is why we are all here...to help each other see things. At the risk of repeating (think of it as emphasising): this is exacly how a CONTROL condition works. CONTROL only triggers when a device, itself, initiates an action. When the device state is changed indirectly, CONTROL conditions do not trigger. Please note in my suggested status program, I used a lot of CONTROL conditions. This was not an arbitrary choice, and should handle the concerns about which you speak. This could be true if one were using a STATUS condition, but not if using a CONTROL condition. I do not believe that this is the case, so long as you are willing to live with the limitations associated with a scene. It is only because you are trying to add conditions to WHEN and IF and HOW BRIGHT that force one into a program and contribute to the delays. Reading many of your responses, it seems to me that the struggles that you are having are due to an incomplete familiarization between STATUS and CONTROL conditions, and when programs are triggered. I am happy to elaborate further if you are interested in trying to make the ISY work.

I understand you may be finding that the ISY is more than you need and taking too much time to be worth it. Many enjoy the challenges and benefits. It sounds as if you are not one of them. That is fine. Having said that, it does seem like you are comparing apples to oranges. In my mind, you actually are trying to accomplish a relatively complicated set of criteria and responses, far beyond what the hub is capable of doing, and probably more than one should attempt on first try. It also sounds as if you are dealing with some issues beyond the programming. If I may offer a suggestion, why don't you try something a little easier to start with? Why not set up a simpler program to trigger upon motion, but to reset the timer when motion is sensed again? For now, skip the time constraints, the variable response levels, and the manual disabling (all things that I don't believe the hub can even do). Most of us, I suspect, learned by starting simpler, then expanded our reach from there. If interested in continuing, let us know. If not, have fun with the hub and the money saved. (saving money is always nice and, yes, this can get expensive.)

I think I would first create a very simple program that serves, simply, to act as a condition for other programs. if control switchlinc is switched on or control switchlinc is switched fast on or control switchlinc is fade up or control switchlinc is fade down or control switchlinc is not switched off or control switchlinc is not switched fast off then stop timer program else nothing This program is looking for manual presses of the switchlinc and will evaluate TRUE (runs THEN path) when the switch is manually turned on or brighten or dim, and will evaluate FALSE (runs ELSE path) when turned off. It will also stop any ongoing timer countdown if runs true. Create a timer program (probably needs to be done first, in order to create the first program, above). This program needs no conditions, but will be called by subsequent programs: if nothing then set switchlinc to 100% wait 10 minutes set switchlinc off else set swithlinc to 9% wait 10 minutes set switchlinc off From there, I would create a couple of programs similar to those suggested by stusviews: if time is from 3pm to 10pm (same day) and first program is false and control motion sensor is switched on then run timer program (THEN PATH) else nothing next program: if time is from 10pm to 3am (next day) and first program is false and control motion sensor is switched on then run timer program (ELSE PATH) Syntax is, I am sure, not exact, but I hope you can get some ideas. For the sake of time, I offer no commentary or explanation why I suggest this approach, so feel free to ask if the purpose of these is unclear, or if how this approach meets your needs is unclear.

I know that I am late to the party here. Been gone a bit, enjoying some time with friends. I would have thought that this could, and should, be done entirely with scenes. It may depend, however, on the age of your keypad device. I fear, however, I don't fully understand what you want to happen in a couple of scenerios. First, what do you want to happen to the lights and fan when press master ON? If, in fact, you want the lights to go on full and the fan to come on, this should work with scenes. This is what I am assuming. Second, if button A is on, and you press again button A, what do you want to happen? I will assume you want it (and the linked lights) to go off. Third, do you want anything to happen to the master button when you press buttons A, B, or D? Do you want it to turn OFF? Do you want it to stay in whatever state it started? I will assume such. Given these assumptions : - I would not use radio buttons. - Create a scene with buttons A and B as controllers and light micro as responder. For controller A, set Light ON level to 100%, set Button B ON level to zero. For controller B, set Light ON level to 65% and button A ON level to zero. - Create a scene with button D as controller and fan micro as responder. -Create a scene with Main button as controller and buttons A, B, and D and both micros as responders. For Main controller, set responder levels to A=100%, B=zero, D=ON, Light Micro=100%, Fan micro=on. - consider that there is also the possibility of configuring this keypad into an 8-button configuration and creatively modifying a frame and using large buttons across two to achieve very interesting possibilities. In response to a couple of your original questions: buttons can be manipulated by scenes. Set responder ON levels to zero, if need be. Yes, they would, depending on how you define "on". Thus my question: what DO you want to happen when you press master ON if not have the lights and fan come on?

I cannot help with problems specific to irule. for those...yes...probably better luck in irule forum.

Great point.

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.