Scenes not Working?

[SteveSBE]

A few days ago about 1/2 of my motion sensor (2420 sensors) programs stopped working. One of these sensors run the program below. After some research I determined that the motion sensors seem to work and makes the program's if statement true. The log file even shows that the device is on (255 code). But the lamps are not on.

 

For the program below I found out that the first "set scene" statement does not turn on the lights but the remaining set scenes turn them on/off as programmed. The motion sensors' settings are: Timeout = 0.5 sections; LED = 0; Darkness = 128; Sensing mode = checked; On only mode = unchecked; Night mode = Checked.

 

Is there an obvious problem I'm not seeing?

 

I also found a lot of messages in the error log. I put the repeating statements below the code example. There were about 1,500 of these statements in the error log from midnight to Noon today. Could these be the issue and if so, why are they being produced?

 

Thanks,

 

Steve

 

 

Program

If
        Control 'ms Stairs Down-Sensor' is switched On
Then
        Set Scene 'sf Stairs Hall Woodstove / sc Stairs Hall Woodstv Day' 100%
        Stop program 'p Stairs3 MS FR On Day'
        Stop program 'p Stairs3 MS Top On Day'
        Wait  1 minute
        Set Scene 'sf Stairs Hall Woodstove / sc Stairs Hall Woodstv Day' Off
        Wait  1 second
        Set Scene 'sf Stairs Hall Woodstove / sc Stairs Hall Woodstv Day' 100%
        Wait  29 seconds
        Set Scene 'sf Stairs Hall Woodstove / sc Stairs Hall Woodstv Day' Off
        Wait  1 second
        Set Scene 'sf Stairs Hall Woodstove / sc Stairs Hall Woodstv Day' 100%
        Wait  10 seconds
        Set Scene 'sf Stairs Hall Woodstove / sc Stairs Hall Woodstv Day' Off
Else
   - No Actions - (To add one, press 'Action')

Error File Statements (a sample)

 

Sat 2014/10/11 05:27:55 AM    System    -170001    [HTTP:0-22]: GET-->/currentsetting.htm
Sat 2014/10/11 05:27:55 AM    System    -170001    [Auth:-10104] 192.168.2.10:50495->80, Num=3
Sat 2014/10/11 05:27:55 AM    System    -170001    [HTTP:0-22] Closing socket normally
Sat 2014/10/11 05:33:46 AM    System    -170001    [HTTP:0-22-5] 192.168.2.10:50749->80
Sat 2014/10/11 05:33:46 AM    System    -170001    [HTTP:0-22]: GET-->/currentsetting.htm
Sat 2014/10/11 05:33:46 AM    System    -170001    [Auth:-10104] 192.168.2.10:50749->80, Num=4
Sat 2014/10/11 05:33:47 AM    System    -170001    [HTTP:0-22] Closing socket normally
Sat 2014/10/11 05:36:30 AM    System    -170001    [HTTP:0-41-5] 70.194.133.70:2229->443
Sat 2014/10/11 05:36:31 AM    System    -170001    [HTTP:0-41]: GET-->/rest/vars/set/2/12/0
Sat 2014/10/11 05:44:28 AM    System    -170001    [HTTP:0-22-5] 192.168.2.10:51213->80
Sat 2014/10/11 05:44:28 AM    System    -170001    [HTTP:0-22]: POST[1]-->/services
Sat 2014/10/11 05:44:28 AM    System    -170001    <s:Envelope><s:Body><u:GetSystemStatus xmlns:u=
Sat 2014/10/11 05:44:41 AM    System    -170001    [HTTP:0-22-5] 192.168.2.10:51224->80
Sat 2014/10/11 05:44:41 AM    System    -170001    [HTTP:0-22]: POST[1]-->/services
Sat 2014/10/11 05:44:41 AM    System    -170001    <s:Envelope><s:Body><u:GetSystemStatus xmlns:u=
Sat 2014/10/11 05:44:41 AM    System    -170001    [HTTP:0-22-5] 192.168.2.10:51225->80
Sat 2014/10/11 05:44:41 AM    System    -170001    [HTTP:0-22]: POST[1]-->/services
Sat 2014/10/11 05:44:41 AM    System    -170001    <s:Envelope><s:Body><u:GetSystemStatus xmlns:u=
Sat 2014/10/11 05:44:44 AM    System    -170001    [HTTP:0-22-5] 192.168.2.10:51228->80
Sat 2014/10/11 05:44:44 AM    System    -170001    [HTTP:0-22]: POST[1]-->/services
Sat 2014/10/11 05:44:44 AM    System    -170001    <s:Envelope><s:Body><u:GetSystemStatus xmlns:u=
Sat 2014/10/11 05:44:45 AM    System    -170001    [HTTP:0-22-5] 192.168.2.10:51230->80
Sat 2014/10/11 05:44:45 AM    System    -170001    [HTTP:0-22]: GET-->/currentsetting.htm
Sat 2014/10/11 05:44:45 AM    System    -170001    [HTTP:0-22] Closing socket normally
Sat 2014/10/11 05:44:54 AM    System    -170001    [HTTP:0-22-5] 192.168.2.10:51262->80
Sat 2014/10/11 05:44:54 AM    System    -170001    [HTTP:0-22]: POST[1]-->/services
Sat 2014/10/11 05:44:54 AM    System    -170001    <s:Envelope><s:Body><u:GetSystemStatus xmlns:u=
Sat 2014/10/11 05:45:04 AM    System    -170001    [HTTP:0-22-5] 192.168.2.10:51277->80

 

[LeeG]

A similar problem was seen by another user.  The problem was the result of the motion sensor sending the remainder of the motion On Scene messages at the same time the Program was issuing the Set Scene.  Insteon terminates one Scene when two Scenes are running at the same time.  The solution was to add a Wait 1 second before the Set Scene statement.

 

The other user Program had been running successfully.  It appears that Program execution is running faster allowing a Scene overlap that did not exist before. 

[SteveSBE]

I'll try that although I'm not sure I should do that for this sensor/program because these are lights used light a set of stairs and I already get a delay of a 1/2 to 1 second because I'm controlling these lights with programs...I may have to re-think my design of these programs. 

 

What about all the error codes? Could that be causing issues?

 

Steve

[LeeG]

The HTTP errors should not affect this Program, the Insteon network over the powerline and the IP network are very different.   I am not familiar enough to help with the IP side except that some of the HTTP contact involves an application that is using REST commands to work with variables.

 

As far as the motion sensor perhaps having it operate in On only mode and have it use a Scene to turn On the load directly and use the Program to flash the load and turn the load Off

[oberkc]

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?

[SteveSBE]

LeeG -- That is what I had in mind and will do that in the future when I have more time to think it through. I also have manual switches and want to turn off the motion sensors when the manual switches are in use and need to figure that out. (I think that's why I used programs to turn them on rather than making motion sensors a controller in the scenes.)

 

Oberkc - I can control the scene from the Admin console and yes, I previously ran a scene test and it passed. On running the "run then" command...I'm not sure what I would use to identify a "failure mode" as the then takes no action.

 

I should let you both know that now that I've put in the 1 second wait before the first scene things seem to work fine but

 

I've run out of time today to work on this and won't have time for a couple weeks to get back to it but I will re-think things when I next get time and restructure my programs to handle the manual switches better (so the programs like my example don't turn off the lights while my wife counts on them being on...which is not a good thing for her...or me). I've bookmarked Oberkc's technique for disabling motion sensing programs when manual switches are in in use...

 

Thanks both for responding and helping.

 

Steve

[oberkc]

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?

[LeeG]

If the first thing is a simple Scene On and that does not turn On the Responders comm is the issue.

[LeeG]

If the Scene On never works check the Scene responders On Level to be sure not set to 0% On Level.

[SteveSBE]

If the first thing is a simple Scene On and that does not turn On the Responders comm is the issue.

 

The responders turn on occasionally. The ISY shows them on but they are not on the first Scene On. I put the "wait 1 second" before the first Scene On statement and it is better. Time will tell if that's the case.

If the Scene On never works check the Scene responders On Level to be sure not set to 0% On Level.

 

I did do that and they show they are at the % I set up in the scene.

[SteveSBE]

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?

 

The ISY does indeed see the motion sensor. The ISY also shows that the devices in the scene are on...it's just that they are not.

 

The other two programs are two other programs run by other motion sensors. I turn them off so the one that triggers its program is "in control". Maybe that is the problem.

 

I'm trying LeeG's "wait 1 second" statement in front of the first Scene On statement and that's seemed to help...but only time will tell.

[LeeG]

PLM initiated Scenes are not ACKed so the ISY is marking the Responders as they should react, not knowing how they actually reacted.

[oberkc]

 I turn them off so the one that triggers its program is "in control". Maybe that is the problem.

 

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?

[SteveSBE]

PLM initiated Scenes are not ACKed so the ISY is marking the Responders as they should react, not knowing how they actually reacted.

 

 

I didn't realize that. Hate to start a new topic within this one...but why can't that be done? It seems it would add better information for reliability and help for troubleshooting to know if something actually worked... 

[larryllix]

I didn't realize that. Hate to start a new topic within this one...but why can't that be done? It seems it would add better information for reliability and help for troubleshooting to know if something actually worked... 

"Insteon Protocol Bible" definition. Besides, which unit would ACK and say the transmission was received OK? I have an "Every Light" scene that contains a few dozen devices. If the operation is very important use an individual command.  It could be done but see sentence one.

[SteveSBE]

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?

 

I can answer some of your questions...

 

I'm starting to think it is a communication problem. I'm finding some MS programs work now that didn't before. Seems like there is something happening communication-wise.

 

I'll need some time to check if my dual-band devices are on both legs of the electrical system.

 

I'm not sure what your asking me to do per your question "If you run an extension cord to outlets in other rooms and circuits to your PLM, does the performance change?". Are asking me to run an extension cord to my PLM?

 

Finally... My PLM is about 8 feet from a surge protector and the ISY is about 3-4 feet above the same one. However ALL my surge protectors run through filters. Would that be enough to filter out interference? The major electrical units that might cause interference that are not filtered and run frequently are 2 refrigerators and a furnace. (I really wish there were sensors for determining those "interferers".)

 

Thanks,

 

Steve

[larryllix]

I can answer some of your questions...

 

I'm starting to think it is a communication problem. I'm finding some MS programs work now that didn't before. Seems like there is something happening communication-wise.

 

I'll need some time to check if my dual-band devices are on both legs of the electrical system.

 

I'm not sure what your asking me to do per your question "If you run an extension cord to outlets in other rooms and circuits to your PLM, does the performance change?". Are asking me to run an extension cord to my PLM?

 

Finally... My PLM is about 8 feet from a surge protector and the ISY is about 3-4 feet above the same one. However ALL my surge protectors run through filters. Would that be enough to filter out interference? The major electrical units that might cause interference that are not filtered and run frequently are 2 refrigerators and a furnace. (I really wish there were sensors for determining those "interferers".)

 

Thanks,

 

Steve

Unplug them and find out.

Most "surge protectors" do not protect against surges at all by definition. They are mostly  spike clippers that short out high voltage spikes at the top of the waveform. These are probably doing nothing behind a filter that should remove most of the them anyway.

 

However, there are some that actually smooth out spikes and glitches with real filtering components and they can be a problem to Insteon signals.