oberkc

Poor communication can cause wrong status.

I know that some of my module LEDs "flutter" during insteon traffic. I can't say that I have noticed any of my switch LEDs doing the same. Furthermore, I have not had one lock up as a result. If a factory reset does not solve the problem, I would tend to guess hardware failure of some sort.

Yup. On the other hand, if you wanted random, unexpected can be good at times. Alternatively, you could make these times relative to darkness or sunset if lights coming on at EXACTLY the same time every day is too obvious to the would-be intruder.

I like to keep things simple. Fewer programs are better (to me) than more programs. if time is from 6:00pm to 7:00pm (same day) or time is from 8:00pm to 9:00pm (same day) or time is from 10:00 to 11:00pm (same day) etc... then turn lights on else turn lights off Obviously, adjust times to suit.

Your "stop" statement halts execution, I believe. It does not stop a program from subsequently triggering and restarting. As a troubleshooting step, temporarily disable these two programs and see if this solves the problem. Without seeing them, it would be wild speculation on my part to conclude that these are an issue. I think we know, however, that it is not a motion sensor failure. It is not a failure of communication between motion sensors and PLM. The program appears to run. Despite passing the scene test, this still sounds like a possible communication problem. Do you have dual-band devices CONFIRMED on both legs of your electrical system? If you run an extension cord to outlets in other rooms and circuits to your PLM, does the performance change? Is your PLM plugged into a surge suppressor or UPS? Near any of these?

Steve, Sorry...I was unclear. If "run then" results in the same symptoms (what I called failure mode) where the "first scene" initially fails to respond, but the rest respond acceptable. The way my mind works, my earlier questions were simply trying to isolate the cause...is the program faulty? Is the scene faulty (or corrupted)? Is the ISY seeing the motion sensor commands? Has the motion sensor failed? Runing the "run then" command was, to me, trying to confirm that a normally executing "then" path results in the same problems. If so, then I would conclude that this is likely not caused by failed motion sensors or faulty communication between motion sensor and PLM. Other things one can do is to watch the event viewer to see if the ISY sees the motion sensor. Since you stated that the program shows TRUE at the proper times, I have tended to discount problems with motion sensors. Since your program does little other than turn the same scene ON and OFF, but only some of the scene commands appear to fail, I tend to discound faulty or corrupted scene links, so this leaves (in my mind) intermittent communication. Other possibilities: are there other programs that include this scene, either as conditions or responses? What are the two "p stairs...." programs? Could halting these cause your first scene command to appear to fail?

I cannot help with the error statements. If, in you example program, it runs runs (shows true) but does not work as expected, what happens if you select the program and "run then"? Is the failure mode repeatable? If yo select the scene, itself, from the device list, can you reliably control it from the admin console? Since it appears that you have an intermittent problem, I would tend to suspect marginal communications. Have you ever performed a scene test on this scene? Does it pass?

My perceptions from this log is that you have pretty darn good communication. Hops left=2 suggests, I understand, there was little need for retries and retransmissions. Given this, it is hard to imagine how you can improve your delay by improvements in this area. As for my experience, I would guess that time between detection and lights are aroudn a second..

I suspect that you at going to find your understanding of the "control not switched off" to be inaccurate. This will be triggered only by OFF commands, and run the ELSE path when triggered. If you care to confirm, turn on that switch and see if your program responds, if at all. I think you will Ind that it does not. Apostolaksl and larrylix has, in my mind, the best solution for your stated requirements.

I have a couple of concerns. First, you may want to try: Status is not off As your program condition. "Control is not switched off" will trigger only upon receipt of an OFF command from the switch. Second, I suspect your program will require breaking into two pieces if status is used.

Another thing that I like about scenes is that I find them easier to deal with than programs as I make minor adjustements to my lighting environment over time and as my needs change. If I invoke scenes only as part of my program, then making the changes to scenes will automatically be captured without program changes.

Sorry. I was in too much of a hurry. Perhaps when smokegrub returns, he can clarify which of us is confused.

Because this, in my mind, does not do what you are asking. You said you wanted a program that, for a period of five minutes after G is on, watch for a door sensor and, if triggered, send a notification (without mentioning the need for a delayed notification). Your program will trigger a notification (but the notification will not be sent until 5 minutes after the fact) anytime the door is triggered while G is ON (regardless of whether G has been on for less than five minutes. This may be what you want in your mind, but I believe Stusviews more accurately reflects what you asked for in your original post.

That would be my conclusion, as well.

As I understand STATUS conditions, any change in status would trigger the program evaluation.

I tend to agree that your first program should work, assuming that I understand your requirements. I suspect issues other than the program are in play here. What happens when you choose the program>>run then? Does the keypad turn off? When the main KPL is off, what is the status of the program? Is it TRUE?

Yes, since you are using "control", Both would need to be there, separated by an 'or'.

My first instinct would be to make sure your ISY software is latest (though having worked before suggests that this will not solve your problem). You did remove the device from the ISY before readding, correct?

I am curious why you have "Run Program 'kitchen day light action' (Then Path)" in two programs. I see that you also have "Run Program 'kitchen night action' (Then Path)" in two programs. I suspect these two programs can, at times, fight each other. Perhaps taking these actions out of the reminder program will help reduce your problems?

The best settings are, partially, dependent on how one intends to control the IOLinc. Other settings are more universal. One most certainly should use momentary mode. Whether using A, B, or C depends on other factors. Personally, i use a keypad button to trigger the door, set to non-toggle ON mode, withIOLinc set to respond to ON commands (momentary C?). Some settings are dependent on how you have the sensor wired and the type of sensor. Status of the relay is not always accurate. The relay is not a controller capable, so it does not transmit status. Displayed status is typically the last command sent...not necessarily accurate. I do not find relay status to be anything useful. Regarding mobilinc, i believe it is best to use scenes to trigger. Look at the sensor node to determine door status.

If you have no scenes, then I believe the scene test difficult. I recall it being something like tools or diagnostics. Mi cannot access my control panel right now to verify. I am sure you can find it in the wiki if you care to check out.

One- or two-second delays may be the result of marginal communications. Have you ever performed scene tests? Do they generally pass?

I think I once asked such a question, and the answer was "no". I have no recently explored newer versions of mobilinc, but I have not noticed this capability having been added. I use android version. May be different in iOS.

The physical indications from the switch gives me concerns. It is certainly strange to me that you would have multiple failures so quickly. I would certainly be looking for any unusual conditions....high voltage....noisy devices....high loads. My temptation would be to perform a factory reset on the switch. If the switch begins to behave normally after that, try a restore from the ISY.

Is it possibly a wiring problem? Are these intended to be part of a three-way installation, or did they replace devices that were?