Strange Behavior with State Variables

[ds7771]

Hi all.  I am stumped.  

 

For a long time I had been using "flag" programs functionally as state variables.  For example, I have a couple of motion sensors in the basement.  I wrote a simple occupancy program to turn on the basement lights when either motion sensor is switched on.  I saved the state of the motion sensor using the flag program--sensor on means "true" and sensor off means "false".  

 

Recently I decided to switch from flag programs to state variables.  Should behave the same way, right?   Wrong.  After switching to state variables, the programs looked correct on paper, but did not switch off the lights.  The state variable changed correctly. ISY correctly reported that the lights were in an off state.  And the logs confirmed the that states did indeed change, and the new state did in fact trigger the lights to an off state.  Everything looked good, but the lights were still on.  This happened many times more than randomly, but not all the time.  Maybe 50%.

 

After much frustration, I decided to try adding a 5 second delay after the state changed before the program was triggered.  That seems to have fixed the problem.  I conjecture that the ISY processes changing flag programs more slowly than changing state variables.  Due to this lag, changing flag programs leaves sufficient time for the PLM to sort through the communications that are going on at the same time.  However, changing state variables is processed more quickly which causes a bottleneck in PLM communications.  Some communications are lost in transit, hence the failure of lights to actually turn off even though ISY logs show them off.  For some reason this only happens with this particular basement light switch. I am guessing the basement switch just has poor communication in general.

 

I hate it when I don't know why things happen.  Does this sound reasonable, or am I missing something else?  Anybody else  have this experience?

 

Thanks! 

[larryllix]

I don;t think PLM communications are a problem passing each other in transit so responding to a trigger with an output shouldn't be a problem for the ISY/PLM process.

 

However...

Battery operated devices send out several repeated commands unsynchronised to the 60Hz. powerline and without respect to other Insteon  signals. Now we have your fast program trying to output an Insteon signal while the MS is still sending out it's insurance signal repeats....problem.

 

Most of us use direct inks (scenes) between MSes and lights for the ON portion and let ISY detect this event and turn the lights off. ISY makes managing these links/scenes quite painless and the technique is very fast.

[ds7771]

Thanks for your reply.  Thats a very good point.  I don't use direct links because I have always preferred the control of programs, but in this case I seem to be shooting myself in the foot.  

 

I did once use direct links.  I have a specific requirement to disable the lights on/off trigger at certain times, and I could never get the direct link method to handle this very well.  I am aware of the method for disabling motion by adjusting on level to zero in the scene.....but I could just never get it to work smoothly for me.  I also felt that this method created a lot of unnecessary traffic in ISY for adjusting scene levels every time the sensor was triggered, versus the program method which seems to shut down any further traffic after ISY determines that the program is in a disabled state.  

 

I think I will try going back to direct links.  Is there a recommended method for disabling motion, or is adjusting the scene level pretty much the only way to do it?  

[larryllix]

http://forum.universal-devices.com/topic/17495-how-to-use-a-ms-with-lights-for-faster-response/?hl=%2Bmotion+%2Bsensor+%2Bxathros

[KeviNH]

I've been slowly moving to ZWave motion sensors anywhere I don't actually need the sensor to trigger an Insteon scene directly.

[ds7771]

I tried the solution proposed above, but I do not think this can work for me.  

 

I have a need to disable motion sensing on certain days of the week, and instead turn the lights on and off using a timer that is based on the time of day.  

 

If I follow the technique to disable motion sensor (by adjusting the on level to zero inside the scene), then this seems to conflict with the timer because the on level is zero when the timer wants it to be 100.  Using this technique, I cannot figure out any way to have the timer keep the lights turned on or off for the duration of the timer period, while simultaneously ignoring motion sensing.

 

Any ideas?