oberkc

Which is a great point. Really, there is no typing when creating a program. It may not be "drag-and-drop", but it is far from manual data entry. That is kinda visual, yes?

I would like to see some sort of visual programming be implemented for the 'average Joe people' (maybe in reality I am an average Joe). A drag and droip inteface. When I see these types of comments, I often get a chuckle. I am not even sure who is the average joe anymore. Is this the person who is helpless if the car breaks down and extent of household repairs is limited to changing of light bulbs? If so, then, yes, the ISY (and home automation in general) is probably not for such a person. When I hear folks asking for a more "visual" interface, it saddens me a little. Are these average joes the ones who cannot comprehend the written word and need pictures to understand things. It seems so many of the instructions I see anymore are all picture-based. Really!? Are we that stupid that the only thing we can understand are pictures? Part of the complications of programming is that computers are the ultimate engineer. They will do exactly what you tell them to do. Every time. But the downside is that they will do exactly what you tell them to do, and no more. One must be very specific. I am not sure that visual approaches will solve this unless some flexibility is lost. Enough of the political commentary...to your specific question.... The example program is a typical ISY example that is the solution to the question: if the switch is turned ON, to this....if the switch is turned off, do that. THe reason you need both is because the first statement is triggered (event) only by an ON command. The second is triggered only by an OFF command. If you want a program to respond to both, you must include statements that are triggered by both. To LeeG's response, I add that the CONTROL IS TURNED ON statement is triggered by an ON command. The CONTROL IS NOT TURNED OFF is triggered by an OFF command. When the first statement is triggered by the ON command, that statement is TRUE. At any other time it is evaluated, it is FALSE. When the second statement is triggered by the OFF command it is FALSE. Any other time it is evaluated, it is TRUE. So, lets say somebody turns the switch ON, triggering an evaluation of the entire (two statement) condition. The first statement is TRUE. The second statement is TRUE. Therefore the complete condition is TRUE (runs then path). If somebody turns the switch OFF. The first statement is false. The second statement is false. Therefore, the complete condition is false (runs ELSE path). The reason such constructs are useful is that it allows (contrary to your observation) single programs to achieve what would otherwise take multiple programs. Similar logic can be used to differentiate when a switch is turned ON from an OFF condition, versus when it is turned ON from an ON condition. As you get into this, it will become more intuitive. It is, simply, one has to learn a new language. It is necessary to understand precisely what is the meaning and consequences of each statement. Fortunately, the vocabulary is limited.

One of the things that could be unclear is that CONTROL triggers a program each time pressed, but whether or not the program condition is true is based on the entire condition. For example: if control switchlinc is switched on and time is from sunrise to sunset then ... else .... this program will be triggered each time the switchlinc is pressed ON, but would be false if outside the specified time range. As as further point of clarification, this program will also trigger as sunrise and sunset, but will also evaluate as false, since there was no simultaneous receipt of an ON command from the switchlinc (both have to be true for the entire condition to be true). Compare to status if status switchlinc is on and time is from sunrise to sunset this program would be triggered if the switchlinc changes status. The program condition would be true when the switchlinc is changed to ON and between the specified times. Unlike the first example, however, this program will evaluate as TRUE at sunrise if the switchlinc is ON. Sometimes, one has to just practice with things.

Mostly, I would describe the difference as what causes the two conditions to trigger and force an evaluation of the condition in which they are included. STATUS will trigger an evaluation upon any change in status, and for any cause of that change. CONTROL will trigger an evaluation only upon receipt of the specified command and ONLY when that command is initiated from the specified device. For example, CONTROL DEVICE X IS SWITCHED ON will trigger only upon receipt of an ON command from DEVICE X. Another factor is that, for condition evaluation purposes, STATUS will yield TRUE any time the specified device matches the stated value. CONTROL, on the other hand, will only yield TRUE when that specific condition is received (otherwise, it will yield a false value).

To the other replies, I will add/emphasise (if not already clear from Mwareman's post) that one needs to worry about programs halting only when there is a WAIT or REPEAT statement. Otherwise, programs will run to conclusion and not be interrupted when a condition is triggered.

What do you want to happen if it is sunrise and light if ON? Do you always want the light to be ON, starting at sunrise, regardless of the state prior to sunrise? What do you want to happen if sunset and light is already off? Stay off? If so, one program is fine. if from sunrise to sunset then turn on light else turn off light There is no harm in turning ON a light that is already ON, and OFF a light that is already OFF. Keep things simple, I say.

I second the suggestion to get the z-wave version. While I have been happy with insteon and intend to continue using it, every once-in-a-while I see zwave devices that are good deals. It is nice to be able mix and match and take advantage of sales and clearances. And, at the risk of starting another discussion about security, I prefer the options with z-wave-enabled locks.

I use the same approach as larryllix. Just be aware that when you call the second program, make sure to choose IF path: Run second program (if path)

Your understanding that single-band devices should not be affected by RF issues is the same as mine. That "monster" power strip concerns me. Is this a surge suppressor or some type of power conditioner? I think it a possibility that this could be a contributor to some comm issues. You may want to consider replacing it with a simple power strip without any electronics or suppression capability. I would also tend to filter UPS in general, regardless of circuit, as a preventative measure. Once filtered, I would keep the power supply of the ISY on the UPS rather than move it to the same circuit as the PLM.

I have found the built in log of the ISY sufficient for any desire I have to track device activity and history. Yes, it can be exported to an excel file. I did nothing to enable this, it tracks these events without any action on my part, so I consider it automatic. I perceive that it tracks every communication event, either to or from the ISY.

Does it run at the same time every night? If so, perhaps this might be a clue as to the cause. (Specifically, I wonder if ithis is being triggered by a nightly query or some other programmed event.)

My experience is that programs, themselves, do not fail. I consider it more likely that the ISY/PLM is no longer seeing the communication from the switches. This seems to be supported by the fact that your event viewer is not seeing the commands. I would treat this as a communication problem. I also believe you can focus on two major possibilities: - something is messing with your powerlines or RF comms - link records in switch, PLM, or both become corrupted. For the first concern, ensure you have a good, clean circuit on which your PLM resides. No other electronic gadgets allowed, unless filtered (my rule). Be sure, also you have good communication between legs of your electrical system. For the second, my temptation would be to peform "show links table" option for one of your switches and "compare". If there is a mismatch, make a judgement about whether the mismatch is due to loss of links on PLM side or device side. It seems there is lots of talk around here lately regarding PLM failures and the loss of link records. I understand your PLM may actually show NO LINK RECORDS when these begin to fail. So...yes, this could be another bad PLM. It could also be one of those random, unexplainable things that happen from time to time. Restoring the PLM or the device can often solve these. I am not absolutely confident about this, but the fact that your device responds to queries suggests to me the link records are intact and you should focus, instead, on pure comms issues. I would not spend any more time trying to fix the program, itself. I don't believe this is the cause of your problems.

I see no programmatic reason why your program would cease working. My experience is that programs ALWAYS run. The only problems I have experienced is when the ISY does not see accurate device status for whatever reason, and programs don't trigger as a result, or that a program runs, but something interferes with the communication with the device commands from the program. Given what you have described, I would check a couple of things. What time does the ISY think it is? I recall examples where the clock time on the ISY can be inaccurate. When you ran the IF path of your program, did the program listing show that the program last ran at that time? If so, does it show TRUE or FALSE? If FALSE, this suggests that it ran the ELSE path, rather than the THEN path. What happens when you manually run the THEN path, with the same conditions that you originally ran the IF path? Does everything respond as you expect? I suggest this to check to see if the ISY is not communicating to the devices, for some reason. Definitely check the ISY status of the '07.2 Den Bk A Patio Lanterns / 07.2 Den Bk G Garage Door'. It may be lit, but something may have prevented this information from reaching the ISY.

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.