Motion Sensor II question

[dbwarner5]

On 6/28/2020 at 12:41 PM, larryllix said:

MSIIs are not good for light operations due to not supporting retriggerable signals.

They appear to support a retriggerable timer internally, but they do not inform external devices of the retrigger.  This doesn;t work for ISY994 and other HA central control systems. Insteon appears to have created this to support the Insteon system devices and defy HA systems.

MSIIs have another problem. The internal reset timer is the same internal timer used for the time-on timer (mentioned above). What this means is that once the internal timer expires from lack of motion detected, the MSII cannot send another On signal as long as it detects motion. Whether you require the external retriggered MS signal for HA, or not, you are going to have a period of dark time (no lights on) as long as the same lights on timer is set to. If you continue to move around the room, the lights will never come back on until you stop all motion for the timer time.

Complete design fail. ISY is not the only system that will not work nicely with these units. I suspect Insteon doesn't want UDI to survive, and this is just one more clue.

Perfect summary.....

[DAlter01]

On 6/28/2020 at 1:35 PM, HABit said:

 Typically I try to set the re-arm (time out) time as short as possible And only have the MSII sent On commands, using an ISY program/timer to provide a light (or device) turn-off. If additional On commands are received from the MSII, the ISY timer value is reset, so the on-time is extended. However, as you point out, the problem with that is if the  MSII is internally retriggered by motion, the subsequent On commands never come to reset the ISY timer. Fortunately, after having studied the problem, typically the opposite action occurs, which is people are doing some stationary thing and no detection occurs by the MSII. This is as bad since then the lights/etc. will turn off. Then it becomes a game of adjusting the timeout value of the MSII to optimize the detection in a particular zone.

 

HABit, I've been noodling around how to create a timer within the ISY to use a MSII as you describe above but have not come up with a way to do what you seem to have accomplished.  Would you mind pointing me in a direction of how to do that or cut and paste a code section?  I'm frustrated with the MSII internal timer and your solution will work magic to my problem....if I can figure out how to get the ISY to work as a resetable timer.

Thanks

 

[larryllix]

4 hours ago, DAlter01 said:

HABit, I've been noodling around how to create a timer within the ISY to use a MSII as you describe above but have not come up with a way to do what you seem to have accomplished.  Would you mind pointing me in a direction of how to do that or cut and paste a code section?  I'm frustrated with the MSII internal timer and your solution will work magic to my problem....if I can figure out how to get the ISY to work as a resetable timer.

Thanks

 

Nope. I never have worked out a decent way. I let the MSII do the timing and turn the lights on and off now. However ISY can dim the light in the scene dependent on time of day. Only the length of time cannot be adjusted.

My MS IIs have all been retired to occupancy detectors now, except one in my laundry room. The internal timer is retriggerable too so it works OK in that application.

Edited April 27, 2021 by larryllix

[HABit]

Hi @Dalter01, first you understand what LarryLiix is saying (summarizing: The MSII was designed to be a stand-alone unit, so the base operation is to allow it to be linked as a Controller, set it’s internal timing for a period of time, allow it to do its internal retriggering and let it control the load via Insteon without ISY interference). I use an MSII in that mode for two instances, just changing the On-Level via a Scene in the ISY when it needs to be dimmed or brightened (On-Level). 

If you are going to use an ISY timer then be aware that the MSII does not send a retriggering DON command when itself is retriggered and sends ONLY the final DOFF command at the end. The one success I had (instead of just using the MSII out of the box with no intervention), was to set the MSII time-out to a long period, or to set the link to something other than the bathroom load, using that DON to initially trigger the Timer (with the attendant ISY delay to turn-on of the load). 

Assuming that for rapidity, you use the load as the initial trigger to run the Timer program, I set a single integer variable as the Time-out value, setting a Timer state var in a Program to the amount of time I want to initially trigger the load. The MSII is set to a short time-out value so it will send additional retriggering signals, but only after it sends a DOFF, then a DON (which is not a retrigger, but a detect again). In the Program I immediately set the Scene controlling the Load to IGNORE the MSII, using the ISY Timer to turn-off the load. When the sufficiently long ISY timer expires, the Program first Dim’s the load, to warn any occupant that the load will be turned-off, and then turns it off. I use any additional DON’s as the retrigger for the ISY internal timer. I use every DON from the MSII to trigger (or retrigger) the internal ISY Timer, but ignore any DOFF’s. The internal ISY Timer is the component that turns-off, via a Program, the load, not the MSII.

I’m not near my ISY at the moment to give a snippet of code, and have a meeting scheduled right now, so cannot go to the ISY for several hours, but will post the code for this after the initial comments. Again, it is easier for me to use the timer within the MSII to turn the load both On and Off, forgetting about the ISY, other than to vary the amount of brightness of the load depending upon the time of day.

[DAlter01]

HABit,

I believe I understand, and it is a creative solution.  I do understand that the MSII will not send additional retrigger ON commands if it is already in its own internal timer interval.  My issue is the maximum internal timer interval of the MSII is about 45 minutes which is too short for my purpose.  If I'm reading your post correctly, I set the ISY variable to change from a triggered value to a non triggered value at my desired 90 minute interval from an MSII ON command.  And, I leave the MSII internal timer at a shorter interval (45 minutes or something shorter).  And, use the MSII ON command to reset the ISY varaible timer, sometimes redundantly.   And, of course, use the ISY for the OFF command once the variable changes to its non triggered value and ignore any OFF commands from the MSII.  In my application, I will not do the warning with the partial dimming at the start of the off sequence but I will use a long timeframe for the off command so that the lights slowly dim until they reach zero unless the MSII (and therefore the ISY program) is retriggered ON.

I may have missed or misunderstood a nuance of your solution so when convenient, please do send over a snipet of code.  Once recdeived I'll play around with it and report back on this forum for the benefit of all.  

Thanks again.

[HABit]

Hi @Dalter01, Sorry for my tardiness, the meeting ran long.

I just looked at all of the systems I have. I no-longer utilize any timer in those systems for the MSII - I cannot post any code. I am in the progress of building a new house, so the ISY which may have contained the Timer In the ISY, turning-off the DON response from the MSII, is not available, and none of the systems I have access to utilize that type of technique to circumvent the time-out/retrigger phenomena of the MSII. Recently, I have either used the MSII as-is, or attempted to use a different solution for load-timing which does not include Insteon devices.

[larryllix]

4 hours ago, DAlter01 said:

HABit,

I believe I understand, and it is a creative solution.  I do understand that the MSII will not send additional retrigger ON commands if it is already in its own internal timer interval.  My issue is the maximum internal timer interval of the MSII is about 45 minutes which is too short for my purpose.  If I'm reading your post correctly, I set the ISY variable to change from a triggered value to a non triggered value at my desired 90 minute interval from an MSII ON command.  And, I leave the MSII internal timer at a shorter interval (45 minutes or something shorter).  And, use the MSII ON command to reset the ISY varaible timer, sometimes redundantly.   And, of course, use the ISY for the OFF command once the variable changes to its non triggered value and ignore any OFF commands from the MSII.  In my application, I will not do the warning with the partial dimming at the start of the off sequence but I will use a long timeframe for the off command so that the lights slowly dim until they reach zero unless the MSII (and therefore the ISY program) is retriggered ON.

I may have missed or misunderstood a nuance of your solution so when convenient, please do send over a snipet of code.  Once recdeived I'll play around with it and report back on this forum for the benefit of all.  

Thanks again.

Just use the old ISY technique using a long off delay timer, and set the MS II timer to something short...say 15 or 30 seconds, to avoid too much battery and Insteon protocol action. You may want to disable the Off commands from the MS II, if you are not going to use them, to save battery life.

This should work if motion is not continuously seen by the MS II during your time out period. If motion is seen before the MS II internal timeout then your light may time off occasionally.

You may be able to use a one and only one set of programs to ensure a long timer, ignoring retriggers, while a shorter timer using retriggers runs, and ORed together to get the best of both timing logics.

Edited April 27, 2021 by larryllix

[DAlter01]

Thank you both.  I'll program it the best I know how and see if i can get it working reliably.  On the surface, it would seem the logic will work fine.  The MSII in my application is USB powered so no reason for me to worry about battery issues.  I'll set it for a 10 minute time-out on the MSII and a 100 minute time-out on the variable in the ISY.  Therefore, it should never turn off within 90 minutes of  seeing motion.  I will set the MSII to only run ON commands just to save on unnecessary ISY traffic.

[DAlter01]

I've resolved my programming problems I had with the MSII acting as a motion on/motion off.  The MSII is installed in the living room of my guest casita.  The issues I had were:

1.  Short internal time-out period of +/- 40 minutes.

2. Sensor turning on the lights when the occupant wants the lights off.

The solutions I came up with are:

1.  A program is created that during defined hours, in my case 7 am to 9 pm, if the MSII senses motion, it sets a state variable called Casita Occupancy State Variable (COSV) to 1.  

2. A program that If the COSV equals 1 then the lights are turned on.  The normal state of the COSV is 0 (unoccupied) and will be set as shown below.

3. If the occupant turns off the wall dimmer switch, it will turn off the controlled lights but turning off the wall dimmer switch will not change the COSV value.  Since the COSV remains it its same state of 1 (occupied) it cannot then turn the lights on again as long as it remains in its occupied state.

4.  A trigger program called Casita Lights Off Trigger is run each time the MSII turns on or turns off (changes state).  When triggered, this trigger program runs a program called Casita Lights Off Execution.  

5.  The Casita Lights Off Excution program doesn't have an "if" statement, the "then" clause is merely a clause to wait 90 minutes and then turn off the Casita lights.  When it turns the lights off (even if the lights were previously manually turned off by the occupant), there is a second line that changes the value of the COSV variable to 0.  At 0, the state variable can then turn on the lights when motion is again sensed under paragraph 1 above.

The idea of this set of programs is that each time there is a change of state in the MSII (paragraph 4) the 90 minute interval in paragraph 5 is reset to 90 minutes.  In paragraph 4, we don't care if the change of state is an "on" command or and "off" command as I am just looking for the change to start the trigger.  If Pargraph 4 was set to only start the timer on with "on" commands, if motion was constant then the timer in paragraph 5 would expire at 90 minutes despite there being constant motion in the Casita.  If Pargraph 4 was set to start the timer with only "off" commands, the timer would not reset if the MSII recorded a new "on" event.  

With these programs once the casita is vacant for 90 minutes then lights will go off and the COSV variable will be reset to 0 which will allow the lights to be turned on again when new motion is detected.  If an occupant were to remain in the casita for an extended period of time and wanted the lights to stay on, or off, this set of programs would not defeat the occupants intent as long as the MSII sees motion once every 90 minutes. 

Important to this process to work successfully is a short internal timeout setting on the MSII so that is keeps sending change in state events under paragraph 4 to keep resetting the 90 minute timer in paragraph 5.  I have my MSII set for a 30 second internal timout interval.  I found the programs had issue when I had a long internal timeout interval in the MSII.     

As described above, the system is working as intended for several weeks so I think most of the bugs have been worked out of the logic.

I hope this can help someone else facing a set of similar challenges.  Good Luck!

[larryllix]

26 minutes ago, DAlter01 said:

I've resolved my programming problems I had with the MSII acting as a motion on/motion off.  The MSII is installed in the living room of my guest casita.  The issues I had were:

1.  Short internal time-out period of +/- 40 minutes.

2. Sensor turning on the lights when the occupant wants the lights off.

The solutions I came up with are:

1.  A program is created that during defined hours, in my case 7 am to 9 pm, if the MSII senses motion, it sets a state variable called Casita Occupancy State Variable (COSV) to 1.  

2. A program that If the COSV equals 1 then the lights are turned on.  The normal state of the COSV is 0 (unoccupied) and will be set as shown below.

3. If the occupant turns off the wall dimmer switch, it will turn off the controlled lights but turning off the wall dimmer switch will not change the COSV value.  Since the COSV remains it its same state of 1 (occupied) it cannot then turn the lights on again as long as it remains in its occupied state.

4.  A trigger program called Casita Lights Off Trigger is run each time the MSII turns on or turns off (changes state).  When triggered, this trigger program runs a program called Casita Lights Off Execution.  

5.  The Casita Lights Off Excution program doesn't have an "if" statement, the "then" clause is merely a clause to wait 90 minutes and then turn off the Casita lights.  When it turns the lights off (even if the lights were previously manually turned off by the occupant), there is a second line that changes the value of the COSV variable to 0.  At 0, the state variable can then turn on the lights when motion is again sensed under paragraph 1 above.

The idea of this set of programs is that each time there is a change of state in the MSII (paragraph 4) the 90 minute interval in paragraph 5 is reset to 90 minutes.  In paragraph 4, we don't care if the change of state is an "on" command or and "off" command as I am just looking for the change to start the trigger.  If Pargraph 4 was set to only start the timer on with "on" commands, if motion was constant then the timer in paragraph 5 would expire at 90 minutes despite there being constant motion in the Casita.  If Pargraph 4 was set to start the timer with only "off" commands, the timer would not reset if the MSII recorded a new "on" event.  

With these programs once the casita is vacant for 90 minutes then lights will go off and the COSV variable will be reset to 0 which will allow the lights to be turned on again when new motion is detected.  If an occupant were to remain in the casita for an extended period of time and wanted the lights to stay on, or off, this set of programs would not defeat the occupants intent as long as the MSII sees motion once every 90 minutes. 

Important to this process to work successfully is a short internal timeout setting on the MSII so that is keeps sending change in state events under paragraph 4 to keep resetting the 90 minute timer in paragraph 5.  I have my MSII set for a 30 second internal timout interval.  I found the programs had issue when I had a long internal timeout interval in the MSII.     

As described above, the system is working as intended for several weeks so I think most of the bugs have been worked out of the logic.

I hope this can help someone else facing a set of similar challenges.  Good Luck!

admin console | right click programs | copy to clipboard | past in code <> box in forum.

 

[DAlter01]

25 minutes ago, larryllix said:

admin console | right click programs | copy to clipboard | past in code <> box in forum.

 

Without the narative it is hard for someone to follow along as the "why" is important.  But, here are the four programs:

This is Paragraph 1 program

If
        'CASITA / Mot - Casita On - Inst' Status is On
    And From     7:00:00AM
        For      14 hours 
 
Then
        $Casita_State_Occupancy_Variable  = 1
 
Else
   - No Actions - (To add one, press 'Action')

This is the paragraph 2 program

If
        $Casita_State_Occupancy_Variable is 1
 
Then
        Set 'CASITA / Casita Kitchen Downlights' On
        Set 'CASITA / Casita Living Rm Downlights' On
      
Else
   - No Actions - (To add one, press 'Action')

This is the paragraph 4 program
If

        'CASITA / Mot - Casita On - Inst' Status is Off
     Or 'CASITA / Mot - Casita On - Inst' Status is On
 
Then
        Run Program 'Casita Lights Off Execution' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')

This is the paragraph 5 program

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Wait  1 hour and 30 minutes 
        $Casita_State_Occupancy_Variable  = 0
        Set 'Z-Automation Scenes / Casita Lights Off' Off
 
Else
   - No Actions - (To add one, press 'Action')

I use a scene to turn the lights off so that I can have it turn off slowly so that the occupants are not left in the dark if there is an unintended turn-off.  They have time to retrigger the motion if they start to see the lights starting to fade out.  
 

[larryllix]

You have unlinked references in your programs because you didn't follow the instructions given. Your programs have then been labelled manually with paragraph numbers that do not relate to anything else.

The "why" is so other people can read your programs not imagine what they actually contain, and then offer help or advice.

eg: Where is the program this line runs?
    Run Program 'Casita Lights Off Execution' (Then Path)

Note: A scene is not required to dim lights. Program lines can do this quite well. Personally I would set the lights to a dim value (as a warning) and then turn them off maybe 30-60 seconds later all inside the same program. Each to his own here and whatever you feel comfortable with, though.  Programs can dim to any value, at any dimming rate, you desire.

Edited May 23, 2021 by larryllix

[DAlter01]

If read in context with my prior post it will make sense.  I tied it to the explanations/narrative in my prior posts.  Sorry you don't like it that way.  The program you mentioned "Run Program 'Casita Lights Off Execution' (Then Path) " is what I describe as paragraph 5.  Good luck

Edited May 23, 2021 by DAlter01

[larryllix]

3 minutes ago, DAlter01 said:

If read in context with my prior post it will make sense.  I tied it to the explanations/narrative in my prior posts.  Sorry you don't like it that way.  The program you mentioned "Run Program 'Casita Lights Off Execution' (Then Path) " is what I describe as paragraph 5.  Good luck

Many have tried to create a decent resolution with these MS II units and failed. If you have come up with a decent solution, many would be interested but I am trying to tell you how to make your solution easily readable. Text descriptions can be misinterpreted how the code would be actually implemented. The copy and paste technique leaves very little room misinterpretation and it is quick and easy. The mechanisms have been provided in the admin console as well as the forum to handle this.

[HABit]

Hi @DAlter01, I apologize for the late reply. I have a crazy schedule and just saw your post.
I think I see what you are doing. The bottom line is: Did it work for you? If the solution works, then that’s almost the whole  battle.

There are some things you can do to enhance operation, but then again if what you have works, why bother? You could use a timer program and load a state variable with a value you get from memory (another var) so you can adjust the On-time by things like time-of-day, or whatever. Users can then also easily adjust the On-time by the great UD Mobile program (change the value in the var). The great thing about the ISY is you can do things in different ways. I had an occasion to look at a system I coded about 5 or so years ago and I know that I’d write the programs differently today. So as you use the ISY, you find easier/more efficient ways to do the same task. It’s all good - you get better over time.

As for your documentation, I use the old-fashioned flow chart or pseudo language IF-THEN-ELSE format, then convert to ISY’s single if statement format, knowing that when implemented the program will be multiple programs in ISY language.

I read it OK the way you described your programs, but gave you the benefit of doubt that it worked. That you have ANY documentation for your system, is a plus. I always try to write an operator manual so I know how I want the system to work. Then you can work toward making the entire system work that way. Plus, (as personally experienced), it’s great to have a manual if you plan to sell the automation system with the house. You WILL get your money out, plus.

Good job. I wish you a very good experience with the ISY and on this forum. I’m sure others here will read what you wrote and have done, and gain inspiration from it.

[DAlter01]

HABit, thanks for the props.  The solution is 98% your idea so I need to give credit where it is due. The only part I added to it was to intentionally use a variable to delink occupancy from the On command after the initial On command.  This is so an occupant could turn off the lights and the lights would stay off until the MSII showed no activity for a period of time.  This no activity period is to determine the occupant had left and so the process starts over again.  That feature might have been part of your original code.  If so, I didn't remember that part of it.  

This is my second house with an ISY and its been a process to clean up all of the programming short comings I had at the first one.  As one learns more about the ISY and the creative ideas others have come up with it impresses me how powerful the system can be.  I've got a few more issues to work out but this part of it was a major accomplishment.  I've used the same coding concept for the MSII's and a few Z-wave motions in my house that are running in parrallel.   

I am attempting to document most of the code with the "reason" for the method selecting and inserting a lot of comments in the ISY.  This may help a future owner but it will also help me when I want to make a change in a few years so I don't have to figure out why I did what I did and re-learn from the mistakes I made in my first attempts to program it.  

Good idea on using variables for start/stop/trigger times.  I see those can be helpful to keep all of these defined values in a seperate section of program to make them easy to locate if/when a change needs to be made.  Being buried within a program makes them hard to track down and change at a later date.

Thanks again for your help.  

Edited May 24, 2021 by DAlter01

[DAlter01]

 

On 5/23/2021 at 1:26 PM, larryllix said:

Many have tried to create a decent resolution with these MS II units and failed. If you have come up with a decent solution, many would be interested but I am trying to tell you how to make your solution easily readable. Text descriptions can be misinterpreted how the code would be actually implemented. The copy and paste technique leaves very little room misinterpretation and it is quick and easy. The mechanisms have been provided in the admin console as well as the forum to handle this.

 

As wisely suggested by larryllix, here are the programs that seem to work to make the MSII a viable sensor with the use of the ISY as the timeout timer for the sensor.  Please read my prior posts to see what these programs seem to successfully accomplish.  As part of this, It is important to set your MSII's internal timer to a short timeout interval.  I currently have mine set and 30 seconds and it works well for my purposes.  I previously had it set for 4 minutes and that did NOT work.  It did not work because if motion occured at least once every 4 minutes the ISY timer never reset because the MSII's internal timer never timed out.  With a 30 second MSII internal timeout inteveral, there only needs to be 30 seconds of inactivity (no motion) for the below programs to work.  In your situation, you may need to decrease that even further to the 10 second minimum offered by the MSII, or maybe you can increase it to something longer.

It took me 4 programs to create this logic and as suggested by HAbit, variables can be used instead of the values I have inserted for start times, the timeout interval, etc. to provide more flexibility and easier changes. 

 Program 1 (this program uses the MSII to set a state variable that indicates there is motion (occupancy).  It is set to do that only during specific times of the day)

Casita Motion Variable Set - [ID 0030][Parent 0019]

If
        'CASITA / Mot - Casita On - Inst' Status is On
    And From     7:00:00AM
        For      14 hours 
 
Then
        $Casita_State_Occupancy_Variable  = 1
 
Else
   - No Actions - (To add one, press 'Action')

Program 2 (this program uses the change in the state of the above triggered state variable to turn the lights on)

Casita Lights On - [ID 0018][Parent 0019]

If
        $Casita_State_Occupancy_Variable is 1
 
Then
        Set 'CASITA / Casita Kitchen Downlights' On
        Set 'CASITA / Casita Living Rm Downlights' On
         
Else
   - No Actions - (To add one, press 'Action')

Program 3 (This program looks for a change in state of the MSII's status to reset (restart) a program this is the timer part of this group of programs.  Each time there is a change in state of the MSII's status, the program it calls (the timer) restarts.

Casita Lights Off Trigger - [ID 0056][Parent 0019]

If
        'CASITA / Mot - Casita On - Inst' Status is Off
     Or 'CASITA / Mot - Casita On - Inst' Status is On
 
Then
        Run Program 'Casita Lights Off Execution' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')
 
Program 4 (this program is the timer.  There are no conditions to run (no if statement).  The only part of this program that is used is the "then" statement.  Every time there is a change in state of the MSII this timer program restarts by Program 3 so it keeps resetting to a 90 minute countdown if there is a change of state of the MSII.  Once the 90 minutes of the timer in this paragraph has passed, the lights turn off and the state variable in program 1 is reset to an unoccupied condition which will then allow the lights to be turned on again the next time there is motion detected by the MSII.  This set of programs is specficially designed to allow an occupant to turn off the lights that have been turned on by this set of programs.  Once turned off by the occupant the lights will stay off until the space is unoccuped for 90 minutes as evidenced by there being no change of state of the MSII for 90 minutes.)

Casita Lights Off Execution - [ID 0054][Parent 0019]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Wait  1 hour and 30 minutes 
        $Casita_State_Occupancy_Variable  = 0
        Set 'Z-Automation Scenes / Casita Lights Off' Off
 
Else
   - No Actions - (To add one, press 'Action')

I've been using this logic in my casita for a few weeks and it is working as I've described without error.  I have used a modified version of this logic in my house to achieve a similar result and it has worked there also for the last 10 days without error.  I believe it is a successful logic sequence uninterupted by unknown/unintended features of the MSII and ISY.  YOUR RESULTS MAY VARY!!