oberkc

I must admit that I have not run into any programming limitations because of this, but (yes) it could drive separate programs or variables or some combination of the two. I have never "run out of programs" by creating too many, but have sometimes chosen to put related programs in folders for organizational purposes. I have, personally, found TRUE and FALSE to be sufficient as is and have never wanted for the ability to know when a program is in a wait state, but I may not be trying overly-complicated programs as you may be. There are some pretty creative folks around here. Perhaps you could post an example of what you are trying to accomplish and someone may think of an approach that you like better than the one you currently use. To answer your original question as to how to detect if a program is active, I would probably use something as simple as: if whatever condition you want then set active variable to x do something wait a bit do something else repeat, shake and stir set active variable to y else set active variable to y it seems to me that when active variable is x, the program is active. When it is y, then not.

"I am still having trouble determining how to programatically detect a Program who's IF logic is TRUE but is not actively Running when it should be. In the attached file screenshot you will see Program "Hall HAL Monitor 1CON" the program is true as indicated by its Color Status, however its WAIT condition is not active therefore the program will never perform the actions after the WAIT should have expired. In other words it is IDLE but TRUE if you look at it in Summary.​" Perhaps others have already explained this (but I missed it). A program will show status of TRUE if it ran THEN path last. That status will remain TRUE indefinitely, or until it runs again and runs the ELSE path, at which point it will show FALSE and will remain FALSE until it runs again...etc.., Unless interrupted, the wait statement likely ran, followed by the subsequent commands. The fact that it is TRUE but IDLE is not an indication that the program will "never perform the actions after the WAIT". In other words, a program does not have to be "active" to be true. The status is simply an indication of which path it last ran.

"For low action background devices they work just fine. eg. China cabinet light, Christmas tree lights." I use x10 only for temporary (holiday) stuff or outdoor applications where I still have those B&D modules. I argree that I would like a chime, but I never had any x10 versions of those, either.

With the ISY, you have a viable z-wave option, also. I have not used the ZigBee capability, but understand the device support is more limited. While I am 90+% insteon, I have started to incorporate some z-wave devices when I find good deals. I find this combination very good. I have not had the insteon failure rate you describe, either. If I were starting a new house, there is not question I would use the ISY-994 with z-wave. I would continue to use a combination of insteon and z-wave, and even a bit of x-10 devices I still have.

Shot in the dark....I recall that scene tests can be troublesome if any of the included devices are part of programs. As a result, it may be good to temporarily disable affected programs prior to the scene test. Is the IOLinc part of any programs?

Yes, much of the status tracking is assumed, based on signals from controllers and scene definitions. If communication is good, however, this will be accurate. Yes, "status" refers to individual devices and not to scenes. If you do not consider this tracking of status, then I guess we disagree somewhat, as you suggest. For my purposes, I have found this to be sufficiently accurate on which to base program actions. ,

Yes, "status" will reflect actual device status, regardless of how achieved. This assumes, of course, proper communications.

I believe you have the correct understanding regarding bridging the two phases. There is no magical troubleshooting that I am aware of, but certainly you should also be sure to avoid plugging in the PLM to an outlet or circuit with other electronic gadgets, such as computer, surge suppressor, ups, network stuff, etc...

I am unaware of anything that would cause a program, once working, to stop. I would focus on communications, corrupt link records, or device failure.

While I have no doubts that wireless garage door opener are designed with security feature and are less vulnerable than insteon, I remember not too long ago stories of military using frequencies that cause unwanted opening and closing of garage doors. Yes, they may be more secure, but they do present a vulnerability to those with the skills to exploit. The chances of a garage door opening uncommanded are much higher with the presence of an opener than for a door without. Furthermore, a door is more secure when locked than when relying on the opener to resist forced opening. But, neither would I control a garage door with insteon if I lived in a high threat area. Fortunately, i do not.

There is no such thing as "can't happen". One can take steps to minimize risk, but, ultimately, one has to balance and accept risk against other competing factors. One could make this argument about many features in a home. A wireless garage door opener, itself, is a vulnerability. Doors and windows are a vulnerability. Vinyl and foam are more vulnerable than concrete. Furthermore, an open garage door without insteon is less secure than a closed door with insteon. Does the fact that an IOLinc represent a new vulnerability automatically mean that I am not going to incorporate these kinds of things into my house? For me, the answer is NOT an automatic NO. Decisions like that are more nuanced than this. Nearly everything we do is a balance between competing priorities. Security is one priority. Convenience is another. The quality of living space is a factor. Cost is a factor. We all must make choices based on our personal tolerance for risk, the risk we perceive, based, in part, on where we live, our own habits and tendencies of those who live with us, and the weight that each individual priority.

I am also curious as to what you mean by an "x-10 controller". Is this nothing more than an x-10 switch that powers the lights? The program side of this should be pretty simple. It sounds as if you want something like: if control door sensor is turned on or control motion sensor is turned on then send x-10 command ON wait a little bit send x-10 command OFF else do nothing I am unaware of any condition where the ISY can find or lose a controller. It simply sends out X-10 commands.

What problem are you trying to solve? The one where the motion sensor will turn on the lights bright, even when the mood scene is set? To solve this problem, you would have to first ensure you trigger the lights from the motion sensor via program rather than a scene with motion sensor as controller. One of the problems you may be running into is that battery devices, such as motion sensors, cannot be programmed without first putting them into linking mode. Your program may be correct, but you cannot make the changes to the motion sensor. You may want to consider pulling the motion controller out of your garage light scene and trigger the garage lights via program. This would allow you to create conditions for your motion sensor to trigger lights, such as lights already off, lights not at 61%, button D not on, etc.... I suspect you will have better luck with this approach.

And more differences.. CONTROL is triggered only by direct action on the device, itself. STATUS is triggered when device status changes for any reason, direct action or otherwise. CONTROL XXX (off, on, dim, bright, faston, etc...) is triggered only by receipt of XXX. IOW, CONTROL ON will not be triggered by receipt of an OFF command.

to access, there is LAN IP adress (192....), WAN address (173....), external port and internal port. Internal port points to LAN address, configured by your router. External port routes to internal port. WAN address is what one uses outside your own network. To access from outside, you may need to add a colon, followed by your external port number. With a web browser and on your own network, what happens when you try to access http://yourLANaddress:yourinternalport? Do you get to the ISY. If so, what happens when you open a web browser outside your network and access http://yourWANaddress:yourexternalport?

Yes, you correctly identified the cause and solution. These lights should turn off when both variables are 0. If you wanted to check state of something, one way would be to break this into two programs, where the first calls the second, the second is disabled (will not self trigger), and checks state before performing action.

I don't believe programs "runs constantly". If a program shuts of your lights, it is likely because one or mor e of the program conditions gets triggered by something. Perhaps you should post your program. Yes, there is a way to do what you want.

Program state reflects results of condition when last evaluated. If a program last ran three days ago, and executed the THEN path, the program status will be true and remain true until it runs again.

I would like to think it would be as simple as your original thought. I have not seen multiple IR codes registered from a single remote button press...for me it is just one press, one code.

Do you not have an ISY? If so, then you have something with X-10. Triggering an ISY program from an X-10 command from a transceiver would be an option to consider.

I see nothing in your front lights off program that would explain a program cause for your 'didn't shut off failure'. Are you sure there was power at the time? One thing I noticed is that the above program calls program 3 (if path), yet program 3 has no IF condition. You may want to change this to the THEN path. I suppose a bunch of queries could work, but it seems to me that it would be simpler to put an additional OFF time in your second program, as a backup, for times when storms and communication problem pop up: If Time is Sunset + 1 hour and 5 minutes or time is 2am <<<<backup! Then Set Scene 'Front Low Volt Lights' Off Else - No Actions - (To add one, press 'Action')

For something this simple, you could also try using "control" rather than "status" for the two sensors. This would allow keeping in a single program.

There is no doubt in my mind that there is a way. Unfortunately, I am unsure that I grasp what problem you are trying to solve. Furthermore, sensors are either open or closed. There is no such status as "while closing", so we have to work within the framework available. So, to put in different words....You want a program (or programs) to start watching for the entry door to trigger an action (turn on lights), but watch for that trigger only when the roll-up door is open, and for a short period after the roll-up door closes? Is this correct? Furthermore, once triggered, you want the lights to turn off after 15 minutes, unless one of the doors subesquently closes. Correct? As extra credit, additionally limit this trigger to times between sunrise and sunset? At a conceptual level, I think my solution would probably include logic such as: if time is sunset to sunrise (next day) and roll-up is open then watch for triggers (likely achieve by enabling trigger program or program folder, or using a variable) else wait short period (to allow for a period after door closes, ie "while closing") stop watching for triggers (likely achieve by disabling trigger program or program folder, or a variable) run trigger program (else path) (to halt 15 minute period when the roll-up door closes) the logic for the trigger program (enabled or disabled by the program above): if status of entry door is open (status used to halt 15 minute wait period if door is closed) turn on lights wait 15 minutes turn off lights else nothing Hopefully, this will give you some ideas. One problem you will have to consider is what you want to happen at sunrise if you happen to be in one of your 15 minute wait periods. The logic, above, would halt the wait and leave on the lights.

Stusviews' and my approaches are slightly different. Mine, potentially, offers a bit more flexibility regarding how you treat the two time transitions. Stusviews' seems to be a simpler and more elegant approach if you are happy in the way it naturally handles the midnight hour and sunrise if the door happens to be open. If this were me, I would probably pick stusviews' approach.

Well, then, my response might change, depending on how you want the system to behave at the transition times (midnight and sunrise). What do you want to occur if the door happens to be open at midnight and sunrise? Immediately close? Stay open? Start the countdown? Stop the countdown? To get the thought process moving, consider a simple program such as: If Status garage door is open Then Wait 5 minutes Run garage-open-close program (if path) Else Nothing The next step would be how to disable this program during the day. This could be done with program folders or another program such as If Time is from midnight To sunrise Then Enable first program Else Disable first program Depending on how you answer the earlier questions, you may need to add a couple of program steps. Hopefully, this will give you some ideas on how to tackle his type of problem.