Insteon Motion Question

[XxTRAINEExX]

Hello all, I have a question regarding Insteon Motion detectors and a kitchen light. I've read the following thread but there are mountains of suggestions and I'm wondering which method is the most widely accepted/supported.

 

http://forum.universal-devices.com/view ... sc&start=0

 

Basically, I have a kitchen light hooked up to a togglelinc. This light switch should function normally 24 hours a day. (on/off) But between the sunset and sunrise, I want the motion detector in the kitchen to control the kitchen light (togglelinc).

 

When I add the motion sensor to the kitchen light scene, it turns the light on/off all day long with motion. I tried creating a few programs to manage the on/off during the day but it resulted in the light coming ON from motion, then quickly being turned back OFF from the program.

 

I've read about the use of folders with time constraints, the use of "day only" jumper setting, the use of programs that set the scene to 0% if its during the day. etc.

 

What is the most accepted way to accomplish this task? Thanks in advance!

Brian

[dansmith]

I spent about 6 hours on the weekend playing around with the motion sensor and trying out the various programming options to make it do what I wanted it to do. My application is to turn on a light in our kitchen pantry when you walk in and to keep the light on the entire time that motion is detected. In a couple of threads on here regarding motion it seemed to have been suggested that you couldn't easily detect a continued occupancy. (Maybe I just read the threads wrong, but it seemed very confusing to me). Anyways after 6 hours of playing around I finally got something to work for me. There were three separate issues to deal with: Motion Sensor jumpers, Motion Sensor settings via ISY, and the actual program inside the ISY. I took the approach of changing only one variable at a time and seeing what effect it had on status, timing etc. Trial and error basically. Here is my setup:

 

Motion Sensor Jumpers

 

1. Sensitivity - left Off (single pin)

2. Disable LED - ON (both pins)

3. Night only Mode - OFF (single pin)

4. On-Only Mode - ON (both pins)

5. Remote Management - ON (both pins)

 

Once linked to the ISY I used the following settings for the sensor:

 

Timeout - 0.5 minutes

LED Brightness - 0

Darkness Sensitivity - 35 (default)

 

With these settings, once the motion sensor detects movement it will send an ON status out. In the ISY the motion sensor will show an ON status. Once motion has ceased to be detected then after the timeout (in my case approximately 30 seconds) the status of the motion sensor will change from ON to OFF as seen by the ISY. It is important to note here that the sensor is not sending an OFF command, it is simply reporting to the ISY that it is no longer ON which is interpreted as OFF.

 

As long as motion is detected then the status of the motion sensor does not change and nothing is sent out from the sensor. It is only after motion has ceased and the internal timeout has expired that the status of the sensor will change. So if you moved about in front of the sensor for an hour and then walked out of range, the ON status of the sensor in the ISY would remain for an hour and 30 seconds and then change to OFF.

 

Note also that I did not create a scene with the motion sensor. It is not linked to the light switch at all, only linked to the ISY (technically to the PLM). All control is thus by program only.

 

I have two programs to turn the light on and off. (Don't have access to the ISY at work so I will do these from memory).

 

Program Pantry Light On

 

If Control Pantry Motion Sensor is switched On

And Pantry Light Status is not On

 

Then Turn Pantry Light On

 

Else

 

 

Program Pantry Light Off

 

If Status Pantry Motion Sensor is On

And Status Pantry Motion Sensor is Not Off

 

Then

Wait 20 Seconds

Turn Pantry Light Off

 

Else

 

 

When someone walks into the pantry the light will come on if it is not already on. The light will remain on as long as the sensor detects movement in the pantry. About 50 seconds after movement is no longer detected then the pantry light will turn off.

 

If I only wanted the motion sensor to operate from sunset to sunrise then I would probably put these two program into a folder that had time constraints of sunset to sunrise. In my case the only issue that I could see by putting them into a controlled folder is what would happen if the wait statement was being executed when the folder conditions went false. ie If motion ceased just moments before sunrise and the Wait 20 seconds in the THEN statement was being executed at the very moment that sunrise occurred. Would the folder going false interrupt the execution of the Wait? Would the light ever turn off? Would have to try that one.

 

Dan

[Sub-Routine]

Yes, the Folder changing to false will stop every program it contains.

 

It will be better to put the Wait program outside of the constricted folder.

 

Then add a line to your On program to stop the Off program if the sensor is triggered On again.

 

If
       Control 'Kitchen Motion Sensor' is switched On
   And Status  'Kitchen South' is Off

Then
->      Stop program 'Kitchen Low Off'
          Set Scene '~Kitchen Motion Fast' On

Else
  - No Actions - (To add one, press 'Action')

 

If motion ceased just moments before sunrise and the Wait 20 seconds in the THEN statement was being executed at the very moment that sunrise occurred. Would the folder going false interrupt the execution of the Wait? Would the light ever turn off? Would have to try that one.

 

Dan

[XxTRAINEExX]

Thanks Dan & Rand,

 

Your method sounds pretty solid. I too was confused by the seamingly endless ways to control the motion/light relationship. Adding a motion sensor to a scene seemed to complicate the matter but I couldn't get the MS to send ON/OF signals properly when it wasnt linked to a scene. Perhaps I was doing something incorrectly.. I will re-test this evening.

 

Brian

[dansmith]

Can you link the motion sensor to the ISY okay? At first my motion sensor wasn't in range of my access points. I had to move the access point up from the basement to a location closer to the pantry where the sensor is located.

 

Before doing anything I would set the jumpers, link to the ISY, change the settings and then monitor the status. Make sure that the status changes as you would expect it to. I made the mistake of inserting it into a program before fully testing it. I knew better, but went ahead and did it anyways. This sensor definitely works different than the X10 motion sensors.

[XxTRAINEExX]

Sorry I haven't given an update yet. I've been busy with a few other things and the insteon equipment is sitting idol on my desk. I will see if I can get it going this evening.

[XxTRAINEExX]

 

Program Pantry Light Off

 

If Status Pantry Motion Sensor is On

And Status Pantry Motion Sensor is Not Off

 

Then

Wait 20 Seconds

Turn Pantry Light Off

 

Else

 

Dan, I'm assuming you didnt mean to put "status pantry motion sensor" twice in the IF statement. Is that correct? I'm working on my motion sensor tonight and I wanted to make sure.

 

Brian

[XxTRAINEExX]

I think I have it! Here is my code:

 

If
Status 'Kitchen Sink Light' is Off
And Control 'Kitchen Motion Sensor' is switched On

Then
Set Scene 'Kitchen Sink NightTime' On

 

 

If
Status 'Kitchen sink light' > Off
And Status 'Kitchen Motion Sensor' is Off

Then
Wait 4 minutes and 30 seconds
set scene 'Kitchen Sink NightTime' Off

 

It appears this is working... the one side effect will be the light possibly not turning off the program is running when it passes sunrise. (Since I have a sunset-sunrise restriction on the program folder) I don't think this is a big problem since we will be up and awake and the light will be just like any other light in the house at that point.

[oberkc]

the one side effect will be the light possibly not turning off the program is running when it passes sunrise.

 

There are posts about these types of conditions...boundary conditions were they called? There are lots of nice ways around them. My approaches tend to be brute force... I just add another program to turn all lights off at a certain time in the morning. That way, if any were inadvertently left on, or failed to turn off, or whatever, this assures that they won't be on for days at a time.

[Sub-Routine]

I think I have it! Here is my code:

 

If
Status 'Kitchen Sink Light' is Off
And Control 'Kitchen Motion Sensor' is switched On

Then
Set Scene 'Kitchen Sink NightTime' On

 

 

If
Status 'Kitchen sink light' > Off
And Status 'Kitchen Motion Sensor' is Off

Then
Wait 4 minutes and 30 seconds
set scene 'Kitchen Sink NightTime' Off

 

It appears this is working... the one side effect will be the light possibly not turning off the program is running when it passes sunrise. (Since I have a sunset-sunrise restriction on the program folder) I don't think this is a big problem since we will be up and awake and the light will be just like any other light in the house at that point.

 

OKAY! Almost home then.

 

Create an Off program that is outside of the time limited folder and call it from your off program. But then you will need to stop it when the sensor switches On while it is still running.

 

Kitchen Off

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
       Wait 4 minutes and 30 seconds
       set scene 'Kitchen Sink NightTime' Off

Else
  - No Actions - (To add one, press 'Action')

 

If
Control 'Kitchen Motion Sensor' is switched On

Then
Stop program 'Kitchen Off' 
Set Scene 'Kitchen Sink NightTime' On

 

If
Control 'Kitchen Motion Sensor' is switched Off

Then
Run program 'Kitchen Off' (Then Path)

 

Rand

[Goose66]

Rand,

 

Are you saying that a program that is currently running (in a WAIT) will cancel if the folder condition for a folder it is in changes?

 

What's up with that?

[Sub-Routine]

Yes, when a folder becomes False all the programs contained are disabled.

 

It has it's uses.

 

Rand,

 

Are you saying that a program that is currently running (in a WAIT) will cancel if the folder condition for a folder it is in changes?

 

What's up with that?

[Goose66]

I understand that the programs would become disabled in that they would not run. But if they are already running, why cancel the program when the folder condition changes? Doesn't this belie your argument that the condition/status seperation we discussed can be accomplished with folder conditions? If folder conditions and IF conditions behave the same way, then how is using folder conditions different from just putting all the conditions in the IF statement? Seems like program folders and conditions are just a means for organization.

 

If, however, changes in folder conditions did not stop running programs, then what the OP was trying to accomplish could be done in one program, not 3:

 

Folder condition: Sunset to Sunrise

IF condition: Control Motion Detector On

THEN: Action Light ON

Wait 1 MIN 30 SEC

Action Light OFF

 

In this case, each time motion occurrs, the WAIT timer would reset (as discussed above) and the light would remain on 1 MIN 30 SEC after last motion. Plus once started, the light would turn off regardless of sunset to sunrise.

[Goose66]

Maybe a better question is: What are the uses for cancelling a currently running program (in WAIT state) when the folder condition changes? Or even when the IF conditions change? That is what I am not seeing.

[Sub-Routine]

I understand that the programs would become disabled in that they would not run. But if they are already running, why cancel the program when the folder condition changes? Doesn't this belie your argument that the condition/status seperation we discussed can be accomplished with folder conditions? If folder conditions and IF conditions behave the same way, then how is using folder conditions different from just putting all the conditions in the IF statement? Seems like program folders and conditions are just a means for organization.

 

Folders can certainly be used only for organization. The ability to add Conditions adds flexibility. For example, I have folders that are scheduled for date ranges. Some of these folders contain 10 programs. Some contain folders with time Conditions. Using folder conditions not only helps me organize the programs but makes it easier to create programs because I don't have to include the date range and the time range in each program. Basically I can Copy a program to a different folder and with a change or two in the Actions I have a different response. And I can change the Date or Time range in one folder to affect many programs.

 

If, however, changes in folder conditions did not stop running programs, then what the OP was trying to accomplish could be done in one program, not 3:

 

Folder condition: Sunset to Sunrise

IF condition: Control Motion Detector On

THEN: Action Light ON

Wait 1 MIN 30 SEC

Action Light OFF

 

The reason for 2 programs is one turns the lights on, the other turns the lights off. The 3rd program is to move the Wait out of the folder.

 

In this case, each time motion occurrs, the WAIT timer would reset (as discussed above) and the light would remain on 1 MIN 30 SEC after last motion. Plus once started, the light would turn off regardless of sunset to sunrise.

 

 

 

Maybe a better question is: What are the uses for cancelling a currently running program (in WAIT state) when the folder condition changes? Or even when the IF conditions change? That is what I am not seeing.

 

Simply:

 

IF condition: Control Motion Detector is switched Off
          And Control Motion Detector is not switched On
THEN: 
          Wait 1 MIN 30 SEC
         Action Light OFF

 

This will stop the program from turning the light off if motion is detected again during the Wait.

 

Rand

[Goose66]

Your supplied code just shows how to deal with the fact that the program is cancelled during a WAIT (and thus needing this seperate 'OFF' program), but it does not illustrate how cancelling the program during the WAIT upon changes in the conditions is useful.

 

That being said, I am afraid our interaction between the two threads has become pointless. I guess I will have to learn to live with the ISY the way it is instead of trying to suggest ways of making it better.

[oberkc]

That being said, I am afraid our interaction between the two threads has become pointless.

 

Don't forget that forums are public and that allows many of us like to learn from the interraction of others. I have not considered this pointless. Perhaps, too, on occasion, another can jump in and try to help.

 

but it does not illustrate how cancelling the program during the WAIT upon changes in the conditions is useful.

 

I thought it did give such an example: Reciept of a new motion trigger stops the ongoing wait and starts it fresh again. This allows one to create a program where one can have the lights go off after the LAST detected motion, rather than after the FIRST detected motion. Perhaps I misunderstood.

 

I guess I will have to learn to live with the ISY the way it is instead of trying to suggest ways of making it better.

 

Better, of course, is in the eye of the beholder. I prefer the greater amount of flexibility, even if it adds a layer of apparent complication. There is nothing wrong with honest differences of opinion. Keep asking questions. We all get smarter as a result.

[Michel Kohanim]

kingwr,

 

As you may have seen, we are quite eager in improving ISY. The main problem is that, at the moment, I am not entirely sure what it is you are requesting. Is it not to stop the wait when the condition is turned to false?

 

As far as folders, I did respond to your previous post but never got a response back. As Rand suggested, the first and foremost the folders are used for organizational purposes. Just like any other folder concept out there. Secondly, and more importantly, folders allow for reuse of conditions. In short, why would you want to have the same condition repeated in 10 programs when it can be added on the folder as a constraint?

 

Now, if you could possibly let me know what it is you are after, then we would surely take it into consideration.

 

With kind regards,

Michel

[oberkc]

Is it not to stop the wait when the condition is turned to false?

 

I think this is exactly the suggestion/question. I think he is questioning the value in halting a running program as a result of changing input conditions.

[Goose66]

I don't question your desire to improve the product and I appreciate the openess of the forum. I just don't want to keep belaboring my point when I am clearly failing to communicate my point. I am not really asking a question or asking for explanation on how to do something with the current implementation. I get that.

 

Generally, my suggestion is that once the program has triggered, then changes in status-type conditions should not stop the program. I don't see where that is useful. This also goes hand-in-hand with the dicussion regarding the (unrecognized in the current implementation) differences between triggers and statuses. Rand suggested the example where a subsequent execution of a program delays the expiration of a timer, e.g. when i receive a subsequent ON from a motion detector. But that is not the status of something changing, it is a subsequent trigger of the program (with the same condition).

 

A simple example for our discussion:

 

IF 'Garage - Motion' ON is Received (trigger) AND Time is between Sunset and Sunrise (status) THEN

Turn 'Garage - Light' ON

WAIT 5 minutes

Turn 'Garage - Light' OFF

 

In this case, it would be handy to have each subsequent occurrence of ON from the motion detector (a trigger) reset the WAIT so that the light would stay on as long as there is motion. The light would eventually turn off, 5 minutes after the last motion that occurred between Sunset and Sunrise.

 

However, the problem is that if the status (Time is between Sunset and Sunrise) changes, then the WAIT is also canceled, which means the light may get stuck on if motion was occurring right up to Sunrise. If status-type conditions didn't cancel the running program then, the program would work as writted. And you could have 1 program to implement this simple procedure, not 3 programs as suggested above.

 

Now, this requires the ability to differentiate between Status conditions and Trigger conditions. This could be done a number of ways. Perhaps all Controls and Time = could be considered trigger conditions and everything else status conditions, but this may be confusing. I thought Rand was explaining to me that putting conditions on a folder was essentially implementing status conditions that would not be evaluated after a WAIT, but that turned out not to be the case, either.

 

So we return to my original suggestion, first made in my first post in the other thread: Each program should specify both trigger conditions (which would be inherently ORed) and status conditions (which would be in the existing IF statment). Trigger conditions could include receiving an ON or OFF, a change in the status of a device, the time equalling a specific time value, and the like. Status conditions would be status of a device equalling ON or OFF, time being between some values, and the like.

 

Subsequent triggers would essentially restart running programs that were in a WAIT. Changes to the conditions in the IF statement would have no effect once the program THEN or ELSE branch is running.

 

This, again in my opinion, would be easier to understand and just as flexible (if not more so) than the current implementation. It may require some seemingly redundant program code, e.g.:

 

Trigger: Status of A changes

IF: Status of A = ON

 

but it makes more sense (to me) and would provide more flexibility. Plus we could have 1 program to control our motion sensors, not 3.

 

EDIT: BTW, I love my ISY 99i Pro/IR, I love the folks at UDI, love all around.

[TJF1960]

Hi kingwr,

 

My question on this subject would be whether existing programs already written and implemented would have to be re-written once any of the code were to be changed as you suggest? While it may make writing programs easier and would require fewer programs, how would this impact current users who have been at this for a while and have hundreds (and hundreds) of programs already written?

 

Tim

[Goose66]

I would think it would impact you dramatically

 

Seriously, the real answer is that is definitely a challenge with any change made to the firmware, whether the one I suggested or something completely different.

 

However, I think it would be possible to write a function to extract triggers from existing IF statements. This would not alleviate impact on existing implementations, but may isolate the impact to a small number of programs. Besides, perhaps with this new implementation, you could have only hundreds (and not humdreds and hudreds) of programs to maintain, no?

[XxTRAINEExX]

Help! My thread has been hijacked! Just kidding of course. I completely understand where kingwr is coming from but now that I understand how it works... I just work around it (ie. 3 programs)

 

It is nice that my motion detector status changing to ON will immediately halt an "OFF" program I've created. This is not the case with traditional programming unless you are actively looping to look for a variable/status change. It keeps me from having to write loop code to check for status while the 4min wait is happening.

 

Back to my original topic....

 

Everything appears to be working and I must admit... I didn't understand how the 3rd program would be effective until you wrote it out. Makes sense that if I want to start turning a light off, I should exit the time restricted folder to wait... so if the time restriction passes, the wait program will continue on.

 

But here is an internal programming question about the ISY...

 

In its current form, the WAIT is occurring in the parent program. If the motion sensor changes to ON, it exits the program, and as such, terminates the WAIT and the subsequent "Lights OFF" that would have followed.

 

If I move the WAIT program outside the parent program as you suggest, I'm guessing the parent program will become FALSE and exit. Does it tell the child program to stop as well? Because in your scenario the child program doesn't have an IF condition and as such, will never become false. IT appears the child program would finish its 4:30 wait and turn the lights OFF.

 

Obviously this isn't the case if the parent/child program are somehow connected in the ISY. (a relationship) Is this the case? Thoughts?

 

Brian

[Michel Kohanim]

Hello kingwr,

 

Thanks so very much for the feedback.

 

I must apologize to all for the wrong information; it seems that even I was under the wrong impression.

 

Here's how things work:

For every event that is related to a condition for which there's a program, the whole program is re-evaluated and the execution of the Action part starts from the beginning.

 

kingwr, specifically to your point, if the status does NOT change, then the execution continues. If the status changes, then the WAIT/REPEAT are interrupted. So, if you want your motion sensors to keep starting from the beginning, then you should use Control instead of Status. Of course, this does not completely address your concerns (the execution starts from the top) but it will alleviate having to write multiple programs.

 

We will be working on enhancing the program structure and execution and your comments/suggestions are surely taken into consideration.

 

With kind regards,

Michel

[Goose66]

To add to the original thread topic, most of my motion detectors are simply set to turn on the lights directly and turn them off after set period of time. Having the motion sensor and light in a scene seems to me to provide more instantaneous light on motion than the use of a program.

 

The motion detector has a dusk/dawn detector that can be set as well. However, as you know, this may not work if the light is in the room with the motion detector, because the dusk dawn sensor may reset after the light is on for about 4 minutes (in my case). This was the problem I had on my driveway sensor.

 

To alleviate that, I have implemented the following program:

 

If
       From    Sunset 
       To      Sunrise (next day)
   And Control 'Outdoor / Driveway Motion-Sensor' is switched On

Then
       Set Scene 'Outdoor / Driveway Floods on Motion' On
       Wait  8 minutes 
       Set Scene 'Outdoor / Driveway Floods on Motion' Off

Else
  - No Actions - (To add one, press 'Action')

 

However, as you know this creates the "boundary conditon" described above where the light may be left on at motion within 8 minutes from sunrise. To couteract that, I have another program that cleans-up my outdoor lighting:

 

If
       From    Sunset 
       To      Sunrise (next day)

Then
       Set 'Outdoor / Front Lanterns' 80%
       Set 'Outdoor / Front Porch Lights' Off
       Set 'Outdoor / Garage Keypad-Driveway Flood' Off

Else
       Set Scene 'Outdoor / Outdoor All Lights' Off

 

This way nothing is left on at Sunrise. If something accidently gets turned on during the day, it is also cleaned up at Sunset. So, 2 programs instead of 3, with one program being a generic cleanup. This seems to be working, although only for a couple of days. But from the discussion above, it theoretically should work.