Print

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

[MD Corie]

A newbie question:

I've searched the forum and found some things that "sort of" relate to this, but not really - or else I just didn't get it.  So, please pardon any redundancy.

I am using Smart Macros to respond to triggers from several motion sensors, in an attempt to turn on a camera to view the affected location in time to see whatever it was that triggered the motion sensor - but generally without success.  The problems seem to be that the macros do not get the proper cameras turned on quickly enough, and that a second (or third) motion sensor may trigger before the macro finishes responding to previous motion trigger(s).  Since my response macros all seem to work fine when there is only one trigger in one area at a time, I'm assuming that something goes haywire when one macro is already running when another (or others) get triggered.  Anyway, things can get REALLY goofy in these cases.  So, I'm wondering how to get around this.

Some specific questions:
What actually happens if a macro is running and another macro (on a different code) gets triggered?  Is one supposed to preempt the other?  Does the second macro get delayed until after the first one finishes, and then run?  Do they both try to run at the same time?  Or, is the action indeterminate?

In my situation, the preferred result of this sort of overlapping triggers situation would be for the newest trigger to cancel all the previously-triggered macros.  This way, only the most recently detected motion would be responded to.  I don't know how to make that happen, though, because there is no way that I know of to have one macro cancel another.  A less desirable option that at least would avoid conflicts would be to use a suppression flag that would prevent any new triggers from running their macros while a previously-triggered macro is still running.  Unfortunately, this would not permit a timely response to the latest trigger, in such cases.  So, I'm not sure how to deal with this overlapping macro problem, such that the most recent trigger response takes priority;  any suggestions?

Thanks in advance....

[HA Dave]

This may.. or may not be helpful.... just a shot. X10 cameras work in groups of 4. A group of 4 would be cameras A1, A2, A3, A4... or any letter with numbers 1-4, 5-8, 9-12, or 13-16. When a camera in the group of 4 is turned ON... the other 3 cameras are automaticly turned Off . That can be helpful in constructing your macros.

Once a macro is triggered... it runs and runs to completion. If a module in the macro is to be turned off... but is already off (or on) because of another macro... the off (or on) will be sent anyway.

[MD Corie]

Yup, I already use the "block of four" hardware switching to reduce the number of camera-off commands that I need to issue in certain circumstances (mainly when a camera is to be turned on under conditions where some other camera already may be active).  In such cases, my macro can issue only three "off" commands (one for any one of the cameras in each of the other three code blocks, and then use the turn-on command for the desired camera to automatically switch off any other camera within its own code block - via the hardware switching.

In regards to my question about the behavior of macros in cases where one macro is still running and another gets triggered, or when two macros on different codes manage to get triggered at essentially the same time, it's unclear to me what is supposed to happen (as well as what actually happens) in such cases.

A typical "real world" situation is when one motion sensor detects activity, and sends a code that triggers a macro.  Shortly after that, the source of the activity moves to a spot where it triggers another motion sensor, which sends a code to trigger a second macro - while the first macro has not yet finished.  And, it may be further complicated when the first sensor sends its off command while the second macro is still running.  Once the trigger occurs for more than one macro, things start behaving strangely - or often times, it appears that some or all of the involved macros never finish (although I've never been able to make sense of what actually takes place in these cases).  If one macro is running when another gets triggered, does one or the other get stopped or paused?  Do both continue running concurrently?  I don't see any consistent indication of the actual behavior - probably because the trigger events don't happen consistently, but ).  Anyway, quite often the end result is that some or all portions of the turn-off macros don't take effect - as if the off-macros never ran at all.  I'd like to understand what is really going on in such cases.  Are the macros interfering with each other?  Are the macro-issued commands blocking the subsequent commands from the motion sensors?  I don't know.... the resulting behavior is all rather bizzarre.

Can anyone explain how the macros interact with each other?

[HA Dave]

Can anyone explain how the macros interact with each other?

Every setup is different. I can't explain your setup. But if you created the macros [and the series of events they are to cause] comparing that information with the AHP's log should give you a good idea.

What likely is happening is signal collisions. If two signals are sent at roughly the same time... often neather... or only one... will be understood by the CM15A (or any receiving device). Collisions can occurs with ether RF or PLC. Since your using both RF [motion sensors] and cameras [PLC] you have the opportunity for BOTH to disrupt the action of your macros.

If your macros triggers (motion sensors) are being used to track a persons movements while also switching cameras the motion sensors may be too close to each other to get reliable switching.

Good camera setups... are a little more complicated than it would seem. There is a little bit of art involved in planning where to place (and when to use) the cameras. I think a little trial and error will be helpful.

Macros are.... generally.... better when shorter. Simple, easy, short macros tend to work best.

[MD Corie]

Can anyone explain how the macros interact with each other?

Every setup is different. I can't explain your setup. But if you created the macros [and the series of events they are to cause] comparing that information with the AHP's log should give you a good idea.

My bad!   I wasn't seeking an explanation of why my particular macros interact with each other, but rather in general terms how newly-triggered macros interact with already-running macros.

I agree with all of your comments and assessments, and I will add the following:

I'm wondering what can be done to avoid or compensate for signal collisions, because they are almost guaranteed to occur in any sort of real world situation like this.  I was assuming that the X10 devices and the software would handle at least some of this "recovery" effort, but...   (By the way, I use the floodlight motion sensors, which are wired types and issue only PLC, not RF.  If I was trying to use the XxxxEye RF motion sensors here, the problem would be multiplied - because those RF sensors issue an ON command every time motion is (re-)detected, where the floodlight sensors issue their ON commands only once per "instance", and thus trigger their response macros only once per "session".  On the other hand, the RF sensors would cause a flurry of ON triggers until all motion stopped, thus trying to re-trigger their response macros many times per motion).

One of the biggest difficulties that I've found in regards to positioning motion sensors and cameras is that the motion sensors have a wide field of view while the cameras have a considerably narrower field of view.  This is part of the reason why I have so many cameras to deal with).  It also creates logic issues when trying to figure out how to match the proper camera to any given motion trigger - as you said.  In fact, this was one reason for using SmartMacros to manage the system:  It should allow flexibility in controlling the cameras without having to do as much physical relocation as would be needed if the experimentation was done only with the hardware devices.

I agree wholeheartedly that shorter macros are better - especially considering that they take a substantial time to execute.  Unfortunately, all the things that need to happen in response to a motion trigger (especially at night) in order to workaround various problems with camera control (which is another whole issue), means that the macros here typically need to be 15-20 steps long, taking at least that many seconds to execute completely (not counting any delays that may be needed).  This extended execution time increases the likelihood that some other macro will get triggered while one is still executing.

But, getting back to the original question of how newly-triggered macros affect and interact with already-running macros, you mentioned using the AHP log to assess the behavior.  This has been problematic to say the least, because there is often no apparent correlation between the macros that seem to be involved and that actual commands that appear in the log;  it often appears that the commands of two macros are intermingled at best, but worse, there are many cases where some commands never even appear in the log (possibly due to collisions, as you noted), while the most perplexing thing is to find extraneous commands appearing here and there, that can't be attributed to any macro that should have been running at the time.  This makes looking at the logs even more confusing that simply trying to account for the actual observed behavior of the cameras and things.  If collisions can account for all this, then clearly I need to find out how to avoid or compensate for these collisions in order to get any sort of desired behavior to occur.  But, based on what I've seen in the logs, it appears that the execution of the macros themselves is being affected when a new macro gets triggered while another macro is already running, but in rather inconsistent ways (so I'm not really sure what's going on).  That's why I'm trying to determine what the expected interactions should be, and then maybe I can make some sense of what I'm seeing in the logs, within that context.  Meanwhile, it's total gibberish. 

[Noam]

Once a macro starts, it will keep going until it finishes (or you stop it using the "purge delayed macro events) in AHP).

If multiple macros are triggered one after another, or even multiple instances of the same macro, they will all run out to completion.
That said, SmartMacros can be taught to be a little more intelligent. If you have a series of macros, and you only want one of them to run at a time, you can set them to check for the status of a flag, and only run if the flag is clear.
You would then have each of those macros in that series set the flag as their first step, and clear it as their last step.
Once one of them starts, none of the others would run (longer than to test the flag condition and exit), until that first one is done.

All this can get very complex, and you might find it easier to map it all out on paper first (like a flowchart), before trying to create all the macros in AHP.

I hope that answers your question regarding macros interacting with each other.

[MD Corie]

Once a macro starts, it will keep going until it finishes (or you stop it using the "purge delayed macro events) in AHP).

If multiple macros are triggered one after another, or even multiple instances of the same macro, they will all run out to completion.
That said, SmartMacros can be taught to be a little more intelligent. If you have a series of macros, and you only want one of them to run at a time, you can set them to check for the status of a flag, and only run if the flag is clear.
You would then have each of those macros in that series set the flag as their first step, and clear it as their last step.
Once one of them starts, none of the others would run (longer than to test the flag condition and exit), until that first one is done.

All this can get very complex, and you might find it easier to map it all out on paper first (like a flowchart), before trying to create all the macros in AHP.

I hope that answers your question regarding macros interacting with each other.

Thank you for your reply.

It so happens that my response macros already use the flag technique in order to avoid re-triggering a given response macro if the "event" is already active.  Not exactly the same situation as you describe, but essentially the same algorithm.

Anyway, the problem that I face doesn't really lend itself to a "lock-out" technique like this - simply because the need is for the newest trigger to pre-empt or cancel any earlier response macros - rather than the other way around.  I'm really not sure how to accomplish that without having a means to issue the purge all from a macro, or something along those lines - although I'd still only want to cancel other motion-response macros, not necessarily all possible macros.

Anyway, it sounds like the behavior you are expecting is for each macro to run when triggered, and execute completely to its end, regardless of any other macros that may be running concurrently.  (The end result of this would be an intermingling on the real time line of all commands from all involved macros, correct?)  Since I don't see this behavior in the AHP log nor in observing the actual behavior of the devices, I remain confused about how macros actually interact with each other.  (Sigh!)

[Noam]

Anyway, it sounds like the behavior you are expecting is for each macro to run when triggered, and execute completely to its end, regardless of any other macros that may be running concurrently.  (The end result of this would be an intermingling on the real time line of all commands from all involved macros, correct?)  Since I don't see this behavior in the AHP log nor in observing the actual behavior of the devices, I remain confused about how macros actually interact with each other.  (Sigh!)

I'm confused about what you are trying to do, then.
This is not what I'm "expecting," but rather what I've observed from my own setup.
Macros in AHP don't "interact" with each other. A macro is simply a list of commands, to be run in a certain order. Once they start, there is no programmatic way to stop them. That's just the way the software was written.

I suppose you could break your long macros up into a series of shorter macros, and use flags to determine if any of those smaller steps will run or not. As far as I know, however, you still need to create "dummy" appliance modules in order to call one macro from another.

There are other software options out there to directly control the CM15A (and possibly the CM19A and CM11A), but I am not very familiar with any of those alternate solutions. I do expect that if you are running all the macro logic off the PC (which those other programs require), that there is probably a way to have more "interactive" macro setups.

Do you have a CM15A, or a CM19A?
In my setup (with macros downloaded and running from a CM15A), it seems that macros will run concurrently.
Perhaps with a CM19A, or with macros run from the PC with a CM15A, the PC can only run through one macro at a time, and the other commands get queued up and run after the first macro completes. That is only a theory (since I don't have a CM19A to test with, and I don't know which unit you are using, either).

[HA Dave]

..... I'm wondering what can be done to avoid or compensate for signal collisions, because they are almost guaranteed to occur in any sort of real world situation like this.

I have created macros myself... that did indeed cause collisions and undesirable consequences. One was a driveway alarm [macro] that conflicted with my garage door open, warning [macro]. Both macros would be triggered by PowerFlash modules sending there own PLC signals. The problem was that on occasion my wife would open the garage door at about the same time her car passed the driveway sensor. Often I would be notified of driveway traffic with no sign/signal of the garage door opening. That indicated to me there was a visitor... instead of my wife returning home.

Or even worse... the driveway alarm would interfear with the completion of the garage door macro when my wife left. That would then alert me that the garage was left open... when it had actually closed.

My only solution was to remove the driveway alarm from my X10 setup. I now use a non-X10 signal for the driveway.

If your running several cameras... in a relatively small area and wish to catch/monitor all the action of what could be overlapping traffic patterns you may want to look at other... or additional ways to do that. Maybe adding a standalone recording device to capture/record/email movements on some higher traffic areas... and remove the X10 from those areas.... might smooth out your current X10 setup.

[MD Corie]

Noam:

In answer to your question, I am using CM15A, normally operating in stand-alone mode - which is my desired operational mode.  However, I attach the PC in order to do AHP logging when trying to troubleshoot the unexpected behaviors that often result when more than one of my macros tries to run at once.  Unfortunately, I can't make sense from the logged results as to what macro(s) actually are running, plus it appears that some parts of the macros don't execute, while in other cases, there are commands logged that are not included in any of hte macros that should have been running;  all this odd stuff leads me to my question about what happens when two or more macros try to run at the same time... because it certainly does not appear to be following either of the courses that seem plausible to me - that is, either every macro runs to completion regardless of any other macro that may be running already (i.e. - concurrent or "parallel" execution), OR only one macro can run at a time, meaning that either a running macro prevents any other macos from running, OR a newly-triggered macro stops any other macro that is already running, OR there is some sort of queuing mechanism that holds execution of all competing macros until a "priority" macro finishes (and then arbitrates the next priority macro to be run).  Consequently, I'm trying to get a handle on what really goes on in such cases...


HA Dave:

Your description sounds very much like the symptoms I've seen, and probably is a good chance of being the same problem here.  So, If I can't get a handle on how macros actually behave under these "concurrent" situations -and how to deal with that effectively- then it looks like I'll have to forego some of the functionality here (as you indicated).  (Sigh!)

[Brian H]

Noam may have more details but I believe Smart Macros can only be run from the PC.

[HA Dave]

HA Dave: Your description sounds very much like the symptoms I've seen, and probably is a good chance of being the same problem here.  So, If I can't get a handle on how macros actually behave under these "concurrent" situations -and how to deal with that effectively- then it looks like I'll have to forego some of the functionality here (as you indicated).  (Sigh!)

It seems to me I read in another thread... that you have quite a large camera setup. Although I can't remember you describing how you monitor your setup. Generally speaking... there are two methods for using cameras. #1 recording activity so the images or video could be used for evidence. #2 for convenience and safety of knowing what is going on... in real time.

Ordinarily surrounding a propriety with a handful of cameras [maybe with the addition of sensors and chimes or (BVC) announcements] will allow for realtime monitoring (I use a picture framed viewer that switches on to allow me to see whats happening around my home... I have also used a TV). You could move some of the other camera views to a secure (and/or hidden) Security DVR.

Using a security DVR would allow you to run those cameras 24/7 while always [mindlessly] catching little clips or images. Or you can use the software motion detection to capture footage. Ether way... it would record in a out of sight out of mind way. Then use a portion of your cameras currently in your X10 setup, to keep track of what's going on in realtime.

I also like emailed video and/or images. Not only can that be used to alert you of activity (where and when NOT expected)... say if emailed to a phone. But it also preserves the video/images safely on a server.

[Noam]

Noam may have more details but I believe Smart Macros can only be run from the PC.

It depends on the type of macros.
Some (like those that use any of the security modules, or run commands on the Pc, etc) must be run from the PC. Simpler ones (check for status of a flag, do something if it is set, etc) can usually be run from the CM15A.
If the macro requires the PC, then the "Store in  Interface" option is not available.

[MD Corie]

HA Dave: Your description sounds very much like the symptoms I've seen, and probably is a good chance of being the same problem here.  So, If I can't get a handle on how macros actually behave under these "concurrent" situations -and how to deal with that effectively- then it looks like I'll have to forego some of the functionality here (as you indicated).  (Sigh!)

It seems to me I read in another thread... that you have quite a large camera setup. Although I can't remember you describing how you monitor your setup. Generally speaking... there are two methods for using cameras. #1 recording activity so the images or video could be used for evidence. #2 for convenience and safety of knowing what is going on... in real time.

...

Actually, I wanted to accomplish both things:  real-time observation and "evidence" capture.  So far, due to the problems with controlling the system, the real-time part is still quite "iffy", and the capture part is entirely non-functional.

The desired functionality of my application was to permit real-time observation of the approach of vistors or intruders, and to record those instances of visits or intrusions.  Specifically, I only wanted to see/be alerted to/record instances of actual activity -as opposed to continuous monitoring- for several reasons:

First, I wanted the system to alert me to events, so that I would not have to "keep tabs" on things all the time;  second, I wanted to activate lighting only on an as-needed basis (in order to save energy);  third, I wanted the capture capability in order to be able to review events that may have occurred while I was away; and lastly, I wanted to record only the instances of activity - so that it would not waste tape and mainly so that I would not have to waste time reviewing a lot of "empty" tape.

Unfortunately, I have tried to use AHP/SmartMacros to coordinate all the surprising number of X10 devices that turned out to be necessary to accomplish this seemingly straight-forward functionality... and being unable to make sense of how the macros affect/interact with each other when triggered on a real-time basis, has led to my questions posed in this topic.  I sure would like to get a firm handle on how all that macro interaction plays out.

[HA Dave]

..... I sure would like to get a firm handle on how all that macro interaction plays out.

There is a lot of randomness in life. I believe... I am guessing... you have a fine understanding of how macros work. I think... your just trying to accomplish too much with X10 and macros.

There is no need to observe (or ever even review) video captured for evidence. Evidence tapes and Hard Drives are copied over and renewed... over and over. Unless you come home to broken glass or a ramsacked home... there is no evidence. Of all the recorded footage I've collected over the years all I've seen is a few people at my door... package delivery's and such... and countless critters. But it's always there... ready to be reviewed in the event that it's needed.

A handfull of macros that allow traffic (or even perimeter) video monitoring with audible alerts shouldn't be hard to create. Or difficult to make reliable. You could keep tabs of events by relying on the alerts (I do).

A lot can be done with X10. But like anything else... X10 has limits. I am NOT saying you can't monitor and record with 16 cameras and X10 alone. But... even with a limitless area to spread out the cameras... that isn't a simple undertaking. Taking some of those cameras off of your X10 setup and using a software-action triggered recording setup would greatly simplify things.

Another solution would be to isolate part of the X10 camera setup from the main setup. Using X10 PowerLine filters, a powerbar with all the alternate cameras power supplies and a 2nd CM15A, and RF motion sensors (as well as the PLC floodlight sensors) to create a system that operates without putting signals on the homes powerlines.