Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[eTreker]

Greetings. I am a long-time X10 user and reader of this forum and have gotten a great deal of useful information from it for which I am appreciative to all the contributing X10 experts out there.

I’m finally posting to ask for help with a problem closely related to Puck’s post titled Single Trigger Macro Using a Status Flag. I understand how this stops some repeated triggering but I wanted to take it a step further. From what I can see, both of the examples in the post will greatly reduce but not prevent retriggering of the chime. If I am correct, both prevent triggering of the chime within a certain fixed window of time only. (as defined by either the motion sensor delay before sending the ‘off’ in the case of #1…or, the 60 second delay in the case of #2). Ultimately, you still get retriggering if for instance, the person hangs around the front door longer than one of these two intervals. 

The problem in my particular application is much like the one above. I have an I/R sensor located in a bathroom. Each time motion is detected by the sensor, I’d like the bathroom light to stay on that much longer. For example, if on the initial detection the delay before the ‘off’ is set to 60 seconds in the macro, I’d like each subsequent detection of motion to essentially reset what would have been remaining of the 60 second delay (before the ‘off’ command would have been sent) back to 60 seconds.

I’ve tried a number of approaches and nothing seems reliable. And I apologize in advance  if the answer is already on this board…I really did search and read a great deal before giving up on finding it.

Also, as a sidebar to all of this, I’ve long wondering which of the following happens when a given macro is repeatedly triggered in rapid succession:

1)   The macros copies ‘stack up’ in memory and are executed sequentially for as many copies as were instantiated by the triggering device (single-threaded).
2)   The macros copies are executed in real time, as triggered (multi-threaded)
3)   The ‘current’ execution cancels any preceding instance so there are no copies.
4)   Something different.

Thanks in advance for any assistance!!!

[Puck]

eTreker: Welcome to the forum.

The first example I posted should do what you want. You would use the OFF signal from the motion detector to turn the light off after xx minutes of no motion. When the motion detector picks up motion, it will reset this timer and start over. So the OFF signal never gets sent until the detector completes a full time-out.

I do believe that all X10 motion detectors have the ability to program the time-out delay length (xx).

BTW: For a simple application like this to turn on a light (full) and keep it on, you don't need to use (waste) a Status Flag; as long as the repeated PLC signals are not causing an issue for the rest of your system.

2)  The macros copies are executed in real time, as triggered (multi-threaded)

From what I experienced, this is what happens during multiple triggers.

[eTreker]

Thanks for the speedy reply, Puck. I think I am still missing something here and also wanted to clarify two things:

1) I am trying to do this without using the OFF command from the I/R sensor so that my OFF timing can be set in the macro and be totally independent of the delay set into the sensor (1 minute by default, I think).

2) I forgot to mention that I do actually dim the bathroom light so the multiple triggers were causing it to come to full brightness and then back down again, but the flag should work-around that, leaving only the above issue.

And just to be sure I understand, when you stated that the

OFF signal never gets sent until the detector completes a full time-out

, are you saying that the OFF signals from the detector cannot overlap the ON signals? I leave all mine set to the one minute default and I could swear it looks as though (in the log) the OFFs get interleaved with ONs if there are enough ONs (more than a minutes worth). In other words, in the case of using the 1 minute default, are you saying that the detector will automatically delay the sending of it's first OFF until 60 seconds after the last ON given a series of intra-minute ONs happens? It seems to that it always sends an OFF for each ON that it sends, so I suppose only the timing is in question.

(I hope I'm not overcomplicating this...)

[Puck]

And just to be sure I understand, when you stated that the

OFF signal never gets sent until the detector completes a full time-out

, are you saying that the OFF signals from the detector cannot overlap the ON signals? I leave all mine set to the one minute default and I could swear it looks as though (in the log) the OFFs get interleaved with ONs if there are enough ONs (more than a minutes worth). In other words, in the case of using the 1 minute default, are you saying that the detector will automatically delay the sending of it's first OFF until 60 seconds after the last ON given a series of intra-minute ONs happens? It seems to that it always sends an OFF for each ON that it sends, so I suppose only the timing is in question.

(I hope I'm not overcomplicating this...)

I only have hands-on experience with the MS16A ActiveEye, and it only sends the one OFF signal after the time-out elapses from the last ON signal. I do believe the other models are the same (I would be very surprised if they acted differently). Which model are you using?

[eTreker]

I'm using the MS16A and the MS13A (really the same, I think). And just did a test...you are 100% correct...there is only one OFF transmitted (after the last ON and after the internal delay has unwound since the last ON) for a given series of rapid-fire ONs. Stupidly enough, in my earlier tests I was using three I/R sensors set to transmit the same code and that explained the interleaved ONs and OFFs I was seeing. As a career programmer in lots of languages and environments, I still surprise myself at so easily missing the obvious! 

Now I guess the last challenge is still finding a way to do what I previously described (i.e. avoid using the transmitted OFF to turn the light off...)

Thanks!

PS. If it helps anyone, I'd like to offer a quick suggestion for others who have had problems with the motion detector spotlight kits (PR511). I had 4 of these that all eventally failed over a period of only 4 years! You can pull out the electronics board in these (4 screws) and substitute the wall-switch dimmer module. Fits nicely in the original weather-proof enclsure and is easily wired - takes about 5 minutes total. Then, just use the stand-alone MS16A sensor to trigger directly or via macro. This adds the advantage of being able to dim the spots and...seems to be much more reliable.

I also did the antenna extension I found here for the CM15A and it works GREAT!

[steven r]

...Now I guess the last challenge is still finding a way to do what I previously described (i.e. avoid using the transmitted OFF to turn the light off...)...

While I thought I had made a similar application, I haven't found it and AHP doesn't lend itself to a lot of macro programming flexibility. I did find a way to act off the original trigger only but that's not your goal. 

Needless to say, triggering from the OFF will be much easier and most likely the most reliable. You can still have a delay from it.

BTW... Is the light you are controlling part of your monitored HC?

[eTreker]

Thanks for considering my problem and responding anyway.

To answer your question, some of the lights I (want to) use in this manner are on the monitored house code but most are not. Between the inside and outside of my home, I am using 14 I/R sensors controlling various lights and combination of lights.

As you suggest, I really would like to put the delay to turn off the light into the 'OFF'-triggered macro, but then I'd run the risk of timing issues. That is to say, if I delay turning the light off in the macro after it is triggered by an OFF sent from the sensor, another ON can be sent by the same sensor which would fire the ON macro and turn the light ON, but the pending OFF delayed from the prior cycle might prematurely turn the light OFF in this current cycle (I hope that makes sense). I think that can be solved by killing the pending OFF somehow if a new ON was sent. Maybe by calling a dummy module (representing another macro) from the OFF macro (right after the delay) and having that second macro look at a flag that could be set by the latest ON which could be used to have it abort turning off the light? (Sidebar: You still cannot call one macro directly from another, correct?)

I may try the above idea but I can't get macros to reliably fire as stand-ins for dummy modules. The work sometimes and not others - and yes, I did make sure they are on the monitored house code so I don't know what is going wring with that.

[steven r]

Thanks for considering my problem and responding anyway....

I keep optimistically thinking this is possible but in reality I think it's not. I think the best approach is to let the MS16A be your delay and minimize what you need to do in closing in response to the sensors OFF signal.

While AHP is the most economical approach to home automation, it's "programing features" have some serious limitations. Perhaps the main limitation is that conditions can't  be impeded into a macro. This means there's no programming way to exit a macro once started! All conditions must be at the start of a macro. Flags and chaining macros with conditions can provide work arounds sometimes for some things but I don't think this is one.

[steven r]

So I'd do it this way.

MS16A set as M2.   Set delay for a few sec longer than the longest expected time someone would be present without moving.

Macro M2 ON - triggers from M2 ON & flag 2 clear^*
<Initial dim>
Set flag 2

Macro M2 OFF - triggers from M2 OFF
<Reset lighting for non occupied mode.>
Clear flag 2


^*Note: If flag 2 isn't clear the 1st time these macros are executed, the initial run through won't dim the light. This is self correcting after one complete cycle, however. Also you manually send an M2 off signal from the sensor to set initial conditions.

Hope that helps.

[eTreker]

Thanks again for the help. I actually think I got it earlier today. I've spent a long time testing my solution and it seems to work. I've shown what I did via modifications I made to your code in red. I can still leave the default of the I/R detector timeout at 1 minute and now set the time delay in the macro. (I did get the dummy module working properly, and it is needed for this solution.)

Essentially, the delay holds off the execution of the OFF (via the dummy module / macro) for as long as needed. If another ON is transmitted by the sensor during that delay period, the flag 2 is reset by the ON logic (in the ELSE) and prevents the pending OFF from executing in the dummy code after DELAY in the macro times out and calls it. As long as the sensor is tripped during the delay window in the macro, the OFF will not be executed (in favor of a subsequent OFF that is sure to come at some future point). This has the effect of resetting the timeout so long as motion is there.


Macro M2 ON - triggers from M2 ON & flag 2 clear* Else Set Flag 2
<Initial dim>
Set flag 2

Macro M2 OFF - triggers from M2 OFF
<Reset lighting for non occupied mode.>
Clear flag 2
Delay <n> minutes (where n > 1)
Turn ON dummy module to activate M3

Macro M3 ON   - triggers from dummy module M3 ON and flag 2 clear
<Reset lighting for non occupied mode.>


I really wanted to get this working because for many of my external lights, I have multiple I/R detectors controlling them. By adding a flag and checking it (and the status of the light) in the right place for each additional detector, I can prevent one detector's OFF from shutting off a light if it was tripped before another controlling the same light (which will send an OFF just a bit later). This seems to work fine now also.

[steven r]

Ok let's follow the logic. Assuming your value of "N" is 4 min. That would mean that if the sensor were triggered just once the light would dim and then 5 minutes later the light would reset.

Now let's look at a scenario where the light is triggered and then triggered again at 2 min.

• Start: Sensor triggers (flag set)
• Minute 1: The 1st trigger of the sensor starts sends a "M2 OFF"
• Minute 1: 1st execution of M2 OFF macro begins (flag cleared)
• Minute 2: Sensor is triggered again (flag set)
• Minute 3: The 2nd trigger of the sensor starts sends a "M2 OFF"
• Minute 3: 2nd execution of M2 OFF macro begins (flag cleared)
• Minute 4: (flag remains clear)
• Minute 5: 1st execution of M2 OFF macro ends while flag is cleared from 2nd activation
• Minute 5: M3 executes

As you see closing execution is still happening from the 1st trigger.
I spent a lot of time, even posting a similar approach that I thought would work till I realized the flaw in my logic and deleted it.

[Oldtimer]

The problem in my particular application is much like the one above. I have an I/R sensor located in a bathroom. Each time motion is detected by the sensor, I’d like the bathroom light to stay on that much longer. For example, if on the initial detection the delay before the ‘off’ is set to 60 seconds in the macro, I’d like each subsequent detection of motion to essentially reset what would have been remaining of the 60 second delay (before the ‘off’ command would have been sent) back to 60 seconds.

I’ve tried a number of approaches and nothing seems reliable. And I apologize in advance  if the answer is already on this board…I really did search and read a great deal before giving up on finding it.

We have had our downstairs bathroom set up to do this for many years with the I/R sensor working with an RR501 and now a CM15A.  In addition to controlling the light it now also controls a small space heater.  See this thread for more details.[/color]

Although I experimented with macros several times I always came back to a no frills set up i.e. the sensor, light and heater all have the same house code/unit code.  The OFF delay on the sensor is 4 minutes.  The only time the light goes out while the bathroom is occupied is when you've been "sitting" quietly for a while,  then, allowing for the 10 second sensor reset delay you wave your hand and the light comes back on again.  This has stood the test of time with visitors and has a sustained high WAF.

[steven r]

...Although I experimented with macros several times I always came back to a no frills set up i.e. the sensor, light and heater all have the same house code/unit code....

While I have fun programing for these lighting situations, my personal solution is photo sensitive night light. It comes on when I go in and turns off a min later. No shock to the eyes with a light coming on at full brightness and dimming.

[eTreker]

Steven R - Thanks...you are 100% correct in that there is a serious flaw in my logic. I really didn't think past raising the DELAY in the macro greater than the preset delay (before OFF transmission) from the I/R sensor. I was really more concerned in trapping conflicting OFFs from multiple sensors controlling one light, which it seemed to do (I try to explain this below).

Anyway, I spent most of last night and this morning obsessively trying to find a way to do a longer DELAY but I finally ended up with so many flags and conditionals that it became nonsense...so, OldTimer's advice about simplicity looks pretty good at this point. But I still would really like to avoid the exact problem that Oldtimer describes with the bathroom light - it's disturbing when you are in there reading and the light goes out...and you have to do the hand wave-thing but a delay is a delay and that issue would persist no matter what. My real aim in using that as an example of what I wanted to 'fix' was to apply that fix to my Lanai lights and my outside spots where I use multiple I/R sensors   (same house code, different Unit codes for each) to control the lights. This is where that 'fix' would be really useful.

Simply put (and assuming a 1 - minute default preset delay in the sensor), if I walked past one sensor in the yard and it turned on the outside spots (via it's macro), and then walked further down the yard and tripped another sensor to turn on the same lights (via it's macro separate from the 'first' sensor's one),  I would like to have the OFF ignored from the first sensor and only have the lights turn off in response to the most recent OFF from the sensor most recently tripped. Otherwise, if after tripping the first sensor it takes 50 seconds to walk down to and trip the second sensor, the spots are still going to turn off at the one-minute mark in response to the first sensor's OFF (if I'm thinking about this correctly). I hope this makes sense...working around this seems like it should be an easy thing to do. Thoughts?

I've twisted my brain on this one now, but I think that as long as I keep the DELAY in my original code less than or equal to the delay programmed into the I/R sensor, the timing will stay such that all re-trips withing the DELAY period will extend the overall delay by the delay, in perpetuity (although one or two might slip by now and then between the 'real' time delay and what we'd calculate on paper). I think this fixes the two-sensor problem I've described above, but I'm not sure. So, just in case I'm making sense at this point, I'd like to know if you'd agree.

Once again, thanks for the help!

[steven r]

...I've twisted my brain on this one now...

So have I but I like logic challenges so it's been fun. 

...I think that as long as I keep the DELAY in my original code less than or equal to the delay programmed into the I/R sensor, the timing will stay such that all re-trips withing the DELAY period will extend the overall delay by the delay, in perpetuity (although one or two might slip by now and then between the 'real' time delay and what we'd calculate on paper). I think this fixes the two-sensor problem I've described above, but I'm not sure. So, just in case I'm making sense at this point, I'd like to know if you'd agree....

Well while I haven't been able to find a case where it wouldn't work, Murphy says you might still run into a "dangling macro".

What it boils down to is even if does work, you have to still have to set a specific time in the sensor weather or not you choose to have an additional macro time. Why not just set the time only in the sensor and stick with a system that would be easier to change in the future if needed?