oberkc

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.

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')