oberkc

I do not see a way for your (or stusviews) program to execute the ELSE path. The program is triggered only by the OFF/LOCKED commands and, once triggered, will always evaluate TRUE. Perhaps I miss something here. I would expect you may need a couple of extra conditions in your program: If Control 'KPL Buttons / Becca KPL.B' is switched Off Or Control 'KPL Buttons / Michael KPL.B' is switched Off Or Control 'Front Door' is switched Key/Manually Locked ​ or Control 'KPL Buttons / Becca KPL.B' is not switched On Or Control 'KPL Buttons / Michael KPL.B' is not switched On Or Control 'Front Door' is not switched Key/Manually Unlocked Then Set 'Front Door' Lock Set Scene 'Front Door Deadbolt' Off Else Set 'Front Door' Unlock Set Scene 'Front Door Deadbolt' On

I note that both programs are triggered by, among other things, a common condition "control kitchen sink off". I do wonder if we have some loops going on here, but my best guess is that this is NOT a programming issue. Run your first program normally (tapping on necessary switches). Once run, execute the second program from the admin panel by "run>>then path". Do your lights turn off as expected, or do some stay on?

Certainly, there have been questions in the past from folks wanting to do this, so it seems certain that some do use the remotelinc as a garage remote. Equally certain is that range will depend on local conditions such as distance to nearest dual-band insteon device and material (brick, walls, boxes, etc...) between remotelinc and nearest device. I do not believe that there is any need for the ISY to "recognize" the presence of a device. I think it simply waits for a signal and, when it is present, the ISY reacts.

Different than what? Setting lights to come on at specific times are straightforward. Do you want them to come on at a certain time, or do you want to enable the motion trigger during certain times? If time is x then set device/scene on else nothing Are these the same or different lights than referenced in the first bullet? If you want different lights to come on with motion always, then I like to configure the motion sensor to send ON commands only, and use a scene with motion sensor as controller and lights as responders. To this, add a program: if control motion sensor is switched on then wait 3 minutes set scene off else nothing If you ever want to constrain operation of the motion sensor by other factors such as time, darkness, whatever, then you must use a program and NOT a scene. Program, above, would accomplish. Are these the same lights as triggered by motion, I assume? Are these the same lights as triggered by motion (include the switch as controller in the same scene)? Same lights as on the timer (create a scene with switch as controller and lights as responder)? suggesting same lights triggered by motion. If so, ammend program above as: if control motion sensor is switched on or control switch is switched on then wait 3 minutes set scene off else nothing would do so if controller in a scene Above suggestions would work whether gone for seconds or for days. Clearly, I am a little uncertain as to which lights are which, whether they are the same in all cases or different and my recommendations might change if I misunderstand what you are trying to accomplish. My suggestion is to start with a more limited set of requirements (such as coming on at certain time of day and working with switches) and see if you can get that working. If so, move to motion.

Yes, if you intend to use motion sensors in scenes to turn on/off other devices, then on and off both need to be enabled. Scenes also tend to be a little quicker responding and work even if the ISY fails. Als, you can use a combination (scenes to turn on, programs to turn off) if that suits your needs. I have found that, for me, I want to apply more contraints on motion sensors than available internally (such as the ability to override) so I tend to use programs.

Either option seems viable. The question that goes through my min is whic option introduces the least delay between motion and response. I suspect that might be option A. Consider, however, option C. What about creating four program folders, each enabled by one of the time ranges. In each folder, add a program: if motion sensed, turn light on, wait x, turn light off. The only uncertainty I have are whether the program wait would be interrupted if the folder is disabled during a wait state.

Yes, this strikes me as a comm problem. Watch the ISY status of a given device and see if it changes as you toggle it on/off. If not, I suspect you have the answer to your question.

Most troubleshooting, it seems, is trial-and-error. I tend to think this is still a possible explanation. In addition, it is very simple to test. Unplug the pinball machine, and plug in a simple incandescent lamp of some sort (or even leave it without anything plugged in). Does this solve the problem? Sometimes the best method is to eliminate the easy things first.

What teken said. Make sure the top is part of NO scene, or NO program, and it should stay in whatever state you want it.

I still cannot help but wonder if we are missing something, but I am out of ideas. It does seem unfortunate that this folder condition does not seem to work.

Yes, that I noticed, and saw those notes in the initial post. It was NOT a problem with grayed-out test button. In fact, the test appeared to work (as indicated by a little pop-up box yielding some results), but the hue light did not respond initially.

"Test" button was NOT grayed out. Pressing it, I originally thought, did not produce any change to the hue device. But, second time a charm. Subsequent devices work just fine from the test button. It is possible that the first now works, but I have not gone back to check. At this point, I would consider the instructions fine as is.

Never figured it out. When I added my second hue light, the test worked fine, as expected. I have no explanation regarding the first attempt, other than incompetence of some sort on my part.

To emphasize and repeat the others, I believe you will find the ISY-994 compatible with ANY insteon switch. I might watch out for very early versions of a few switches, but more for hardware reliability concerns rather than compatibility. At this point, I doubt that anyone would be selling as new any devices this old, however.

I fell prey, also, to the /1234 issue. When I read that, I took it as "optional" whether or not one left it in. For me, it was not optional. For me, also, running the "test" from the network resources did not actually result in the hue lights turning on or off (which I expected to happen). It was not until I actually put them into a program did they work. It took me a little while to discover this. When the "test" did not turn on the lights, I assumed it was some error in the resource, so I continued to look for errors, and re-ran some of the debugging steps instead. When those did not solve the problem, only then did I take the next steps of creating the program and discovered the resource was, in fact, fine (lights turned on!). Perhaps that could be clarified as to what to expect, or not to expect, from running the test step from the network resources page. Otherwise, all worked as well-described in the original post.

DualBandAid I just wanted to say thanks for the time you took to write this up. I have been interested in using some color in my lighting, and the hue strips seem to catch my eye, but I am not interested in anything that cannot be controlled by my ISY-994.. I cannot imagine how long it would have taken me to figure this out, and would not even have tried by myself. But...your instructions gave me enough hope that this would not have been the equivalent of a masters thesis for me that I gave it a shot. Now, I have some hue strip lighting that is triggered by my -994 and I am happy! I doubt that I will use hue for anything but a few color shots, so I will stay with the network resource. Polyglot is too funny a name for me to have to explain to others how it all works, so I will stay away from that for now.

To clarify...are you using the ISY-99, or the -994? I believe many of the newer insteon devices may not be compatble with the -99 since it was replaced by the -994 and is no longer supported.

If your folder is turning enabled and disabled, based upon the variable and condition, I have no explanations. I use folders with conditions, and they work flawlessly. - you have confirmed no external programs triggering those in the folders, ok. - are the motion sensors controllers in a scene that includes the devices commanded by the program? Last thing that I can think of is speculation. I know, for example, that a statement such as: if control "device" is NOT swithed ON <<<triggered only by ON command. Is it possible that your folder condition if variable NOT = 1 <<<could this be triggered only by a variable=1 condition, and not triggered when the variable equals a value other than 1? (I don't know for sure, but it may be worth considering.)

Is it possible that the programs are being called by another program outside the folder?

If you had a three-way switch connected to black/white/red, you should be MORE than 99% confident that white is NOT a neutral.

Extension cord and a couple of wire nuts?

I have no idea about "most" or average. Personally, I have well fewer than 100 programs, but I have no doubt those crazy guys can have orders of magnitudes greater than that. Useing the program folders and comments, it is pretty easy to manage, in my estimation. Which is another reason I prefered my original suggestion (remove the status condition) and do it in a single program. I suspect you will also find means opportunity to combine programs. For example I might have several programs to turn lights on any given day, but only one to turn all off. For the most part, I have not found this sort of thing to be a constraint.

Probably use an approach similar to haroldunger, but you would have to use two programs. The big difference is that the time condition is a single, discrete, time rather than a range. If time is sunset + 30 and status garage exterior is OFF then turn lights on else nothing if time is 1130pm then turn lights off else nothing One of the big things to be aware of is when a program action can cause the program to retrigger (as your original program did) and get in a never-ending loop. A simple and obvious example would be: if status LIGHT is OFF then turn LIGHT ON else turn LIGHT OFF While easy to see in this case, it is often hard to see when this is happening in more complicated programs. I believe it was happening in your case (but only between the time range specified).

This program is a little different than the original-posted program. Yours has a "if time is..." Ajax' program has a "if time is from/to". Your program works fine because there is only a specific moment in time that it can be true. Ajax program can be true over a period of several hours. Obviously, Ajax' program also has a non-empty ELSE path. There are several ways to approach Ajax program. One could use two programs. One could use a single program as he is trying. If the condition "status exterior light is off" turns out to be important, then it might be necessary to break his into two programs. But, the original intention seemed to be check whether the scene was on, instead using a device within the scene as an indicator. In my estimation, if a scene is ON, there is no harm in turning it on again.

It is because scenes have no status in insteon. Only devices have a status. Your program is, in effect, creating an endless loop. The program triggers, it changes the state of the device (as part of the scene), which triggers the program, which changes the state of the device, which triggers the program, which...well...you get the point. Remove the STATUS condition from the program. It really serves no purpose, anyhow.