X10 Community Forum

🖥️ActiveHome Pro => Plug-ins => Smart Macros => Topic started by: MD Corie on November 23, 2011, 06:17:06 PM

Title: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 23, 2011, 06:17:06 PM
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....
Title: Re: Questions about macros that respond to "real world" triggers
Post by: HA Dave on November 23, 2011, 10:15:55 PM
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.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 24, 2011, 06:36:11 PM
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?
Title: Re: Questions about macros that respond to "real world" triggers
Post by: HA Dave on November 25, 2011, 12:36:05 AM
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.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 25, 2011, 11:06:26 AM
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.  ::)
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on November 25, 2011, 11:35:32 AM
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.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 25, 2011, 11:51:13 AM
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!)
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on November 25, 2011, 12:19:40 PM
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).
Title: Re: Questions about macros that respond to "real world" triggers
Post by: HA Dave on November 25, 2011, 04:04:51 PM
..... 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.



Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 26, 2011, 09:02:38 AM
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!)
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Brian H on November 26, 2011, 09:20:31 AM
Noam may have more details but I believe Smart Macros can only be run from the PC.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: HA Dave on November 26, 2011, 10:59:23 AM
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 (http://www.wgjohns.com/bvc.htm)) 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 (http://www.youtube.com/suitmanIM#p/u/7/tkAwQ4KXkHA)). You could move some of the other camera views to a secure (and/or hidden) Security DVR (http://www.geeks.com/details.asp?InvtId=SM-DV16GN11).

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.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on November 26, 2011, 06:06:52 PM
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.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 28, 2011, 06:41:16 AM
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.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: HA Dave on November 28, 2011, 08:50:59 AM
..... 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.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 28, 2011, 06:14:27 PM
..... I sure would like to get a firm handle on how all that macro interaction plays out.

I think... your just trying to accomplish too much with X10 and macros.
The crying irony of that is my system was originally just four cameras and a half-dozen motion sensors, and it all was supposed to work just via PLC commands, with no "smarts" (macros, etc.) involved.  From that simple beginning, the system mushroomed while trying to overcome various problems where the devices did not work as expected, and eventually became so extensive that it was recommended to me to use AHP/SmartMacros to manage the whole works effectively.  The actual desired functionality was so "lean" that the idea that it is trying to accomplish too much is just immensely ironic.  In any case, I'm not sure that I agree that what I'm attempting is beyond the reasonable capability... rather, I think that I need more information, understanding, and "tools" to deal with the idiosyncracies involved.

There is no need to observe (or ever even review) video captured for evidence. ...Unless you come home to broken glass or a ramsacked home...  and countless critters.

Truthfully, "evidence" capture is only a secondary - or even tertiary - function, and indeed I would not review the tape unless there was reason to do so - but, in such case, I'd still like to have only relevent recordings to review.  And it is interesting that you mention critters - because critters are the most likely intruders that I want to monitor... with the next most likely visitors of interest being deliveries and such... and unwanted visitors being less likely than any of the preceeding.  Of course, I would hope to capture "evidence" in the event of some criminal activity;  unfortunately, the cameras are not capable of any really useful level of detail as would be needed for that purpose.  For example, they cannot make out the lettering on a license plate at 8' - let alone tell what those letters are... and I doubt that it would be possible to positively identify any individual in any of the images... in fact, it is really difficult to even make out the brand of most cars!  I would like to use the images for such purposes, but I really don't think that the images would be of much value for that.

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.
I like that idea in principle, but I don't think it is really practical to set up a duplicate wiring system exclusively for X10 PLC because that sort of defeats the the whole purpose of PLC.  I mean, if I need a dedicated interconnection network for the system, then there are likely better types of systems to use.

Anyhow... Regardless of the application, I'd still like to really understand how macros interact with each other....
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on November 28, 2011, 07:31:04 PM
Anyhow... Regardless of the application, I'd still like to really understand how macros interact with each other....

I've already answered (as have others), that macros don't really interact with each other.
They can call other macros, and they can set or clear flags that would act as conditions for other macros, but that's the extend of their interaction.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 29, 2011, 04:07:52 AM
Anyhow... Regardless of the application, I'd still like to really understand how macros interact with each other....

I've already answered (as have others), that macros don't really interact with each other.
They can call other macros, and they can set or clear flags that would act as conditions for other macros, but that's the extend of their interaction.

OK, then do I understand correctly that if macro, say D1, is running and a trigger comes in for another macro, say D2, then D1 should continue to run, and at the same time D2 should start running... and if both of these are still running when a trigger comes in for macro D3, then D1 and D2 will continue running and D3 will also start running... yada, yada, yada... and no macro will preempt, cancel, queue-up, or otherwise delay or block any other macro, such that one or more of the macros would never run to completion?

If so, that's great - but I still have the question of how the commands from the respective simultaneous macros will be issued, because I assume that commands from multiple macros can't be issued at the same time, so the priority of the macros (or of the specific commands themselves) must be arbitrated somehow... otherwise, it must be a situation where the macro "engine" would be causing "self-induced collisions" - by issuing multiple overlapping commands.  Can you shed any light on how that plays out under normal conditions?

If the macro "engine" is not causing such collisions, and also does not block one macro when another tries to run, then I'm still trying to find the reason(s) why my macros start misbehaving -or often appear to stop running entirely - when subsequent macro(s) get triggered.  I apologise if this has been explained already, but if it has, then I didn't "get it".... so please clarify.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on November 29, 2011, 09:16:31 AM
I am not positive as to how it works in that case.
Perhaps someone else here has done some testing, and can give more insight.

I did send an e-mail off to one of the developers, asking him for some clarification. I'll let you know what he comes back with.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: HA Dave on November 29, 2011, 01:33:15 PM
......... but I still have the question of how the commands from the respective simultaneous macros will be issued, because I assume that commands from multiple macros can't be issued at the same time, so the priority of the macros (or of the specific commands themselves) must be arbitrated somehow...

I think I understand what your trying to accomplish. It would make sense after all... understand the machine better to better exploit its usefulness. But machine or not... you can't discount randomness.

If you and I was to meet at a party, and sit in a room and have a conversation. Each of us taking turns speaking and sharing views, things might go rather smoothly. But as... say as other guesses arrive more people enter the room and also start there own conversations as well as interject views and opinions into ours. Some guess would speak very loudly and others speak so softly they were hard to hear and understand even before the room became crowded. Some people fire out words [or commands] rapidly while others have long delays between each comment. Meanwhile... the host also left a TV on which provides distracting noise from the background.

At some point... I begin to misunderstand your words. Because I hear part of your sentence mixed with part from someone else. Later... I am only able to pick out a word or two from you... mixed with a word from this lady... and phrase from that man.

I don't know at what time the conversations become unreliable, or how many people were in the room when that happened. It would be impossible to repeat the circumstances to find the exact optimal number of guesses.... for good conversations. Because the rate of conversations will always have an element of randomness.

But... the host of the party can make some assumptions and changes to help promote good conversations. Like inviting fewer people... or separating the real talkers... by asking them to join them in the kitchen. Much like conversations at a party... so goes the reliability of X10 communications. I have one macro that will act up and not complete if it happens to run while my garage door closes and I disarm my alarm. Admittedly.... this rarely ever happens... but it has happened twice.

I am not trying to discourage you from learning more, or exploiting the most from the X10 protocol. But the phrase beating a dead horse does come to mind. As a rule... when someone starts getting conflicting commands and PLC collisions with the macros... it's time to back off a little. But... best of luck with however you procede.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on November 29, 2011, 02:00:10 PM
Wow! What a great metaphor!
I should bookmark it along with my "hallway" metaphor .
(here: http://forums.x10.com/index.php?topic=22998.msg131366#msg131366 in case you missed it)

The question IS a valid one (what is the "order of operations" when it comes to multiple X10 commands), but I don't think any of us "regulars" here can answer that one. The developers do have access to the forums, but they generally don't chime in unless they are asked to (and I've asked one to chime in here on this).

The same question comes up when you have multiple timers set for the same time (ex: both the kitchen and dining room lights are set to come on at 6 PM). Which one goes first?

Based on my reading through of my AHX file, it looks to be either the order in which the timers were created in AHP.
It looks like each module created in AHP is given a unique ID number. From what I can tell, those are sequential, and don't get re-used (if you delete a module, it's number is retired).
It looks like the same thing is done for timers (delete a timer, and the number is retired, too).

So, that at least answers the question for the timers. They execute in the order they were created.
However, I can't say what happens with the macro execution. I would have to create some sort of test scenario, and I won't have time to do that for a while.

I know that macros CAN run simultaneously (we have enough examples of that with macros that call each other, flag status, etc). As I said - When I hear back from the developers, I'll post the answers here.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: HA Dave on November 29, 2011, 08:11:56 PM
Wow! What a great metaphor!

Thanks... but I am pretty sure I've plagiarized that from somewhere. I read much better than I write.

The question IS a valid one (what is the "order of operations" when it comes to multiple X10 commands),

I agree... and I admire the OPs determination to force X10 to perform to his will. I myself have plotted and planned to squeak a little more from the old protocol to improve my macros. I just believe X10 motion detection adds actions that are likely too unpredictable at some level. I hope am wrong.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 29, 2011, 10:08:14 PM
...
I am not trying to discourage you from learning more, or exploiting the most from the X10 protocol. But the phrase beating a dead horse does come to mind. As a rule... when someone starts getting conflicting commands and PLC collisions with the macros... it's time to back off a little. But... best of luck with however you procede.
I certainly hope that is not the case!  :(

Nice analogy, by the way... but most "robust" systems include means to deal with most of that sort of thing.  Unfortunately, it's looking more and more that the X10 protocols don't, for some reason. ???
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 29, 2011, 10:16:22 PM
...

However, I can't say what happens with the macro execution. I would have to create some sort of test scenario, and I won't have time to do that for a while.

I know that macros CAN run simultaneously (we have enough examples of that with macros that call each other, flag status, etc). As I said - When I hear back from the developers, I'll post the answers here.

I certainly have quite a set of potential "test scenarios"... unfortunately, I'm not able to make much sense of what is going on when I try to "test" them...  ???  The collisions scenario certainly seems plausible - but the question then becomes, what is colliding with what (PLC commands, or macro step execution, or etc.), and when, and why.  It seems possible that, knowing what is actually going on, there might be ways to work around the problem aspects - or at least take steps to prevent or avoid the circumstances that produce the problems... without throwing out the baby with the bath water!  ;)

Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 29, 2011, 10:35:21 PM
... I just believe X10 motion detection adds actions that are likely too unpredictable at some level. I hope am wrong.
Well, the motion sensors do add a lot of randomness, by virtue of reporting realtime events (which are essentially random by definition), and -unfortunately- also provide some degree of unpredicatability due to some misbehaviors of their own doing.  In theory, it should be possible to deal effectively with the randomness -and maybe even the unpredicatability- but it would require some valid characterization of the randomness and of the manifestations of the unpredicatability... in other words, to determine if there is some other symptomology associated with the unpredicatability that can be sensed or tested for, and then used to selectively reject "probable" invalid triggers, and/or to suppress unwanted responses (such as multiple responses, concurrently-running macros, etc.)  "Smarts", in the form of conditional macros, should be able to deal with such things... in theory.  The problem would seem to be coming up with the valid characterizations...

Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 29, 2011, 11:09:52 PM
I know that macros CAN run simultaneously (we have enough examples of that with macros that call each other...

By the way, I forgot to mention that I also have a question or two about macros calling other macros... and maybe someone can shed some light in that area as well:

First off, why is a separate delay needed before a macro "call"?  In fact, why is a delay needed at all?  (It seems like if there is an inherent need for such a delay, then there ought to be a macro step designed for calling other macros - that would automatically handle any required delays, synchronizations, etc.  ???

Second, the act of calling one macro from another revisits the question of how macros interact with each other, specifically in this case, whether the "called" macro behaves like a subroutine, suspending execution of the "calling" macro until the "called" macro finishes, or if the "called" macro is simply triggered and then both macros continue to run.  (The behavior of my system appears to support the subroutine theory, yet that behavior would be contradictory to the general concensus here that all macros run when they are triggered, regardless of any other macros that may be executing, so... ???)

To further support the theory that at least some macros actually preempt or block each other in some cases, I have one macro scenario that gives me fits:

In order to automagically cycle through several cameras that are needed in order to cover a certain area here, I have a simple looping macro that turns on a camera, delays for several seconds, then turns on the next camera, repeating the steps for each of the cameras, and then looping back by calling itself.  A flag gets tested at the beginning of the macro, and this allows an external macro to abort the loop - as when the motion sensor issues an off command.  The aggravating problem is that the Off command is supposed to trigger a macro that sets the "abort flag", preventing the looping macro from restarting... but it appears that the Off-response macro often does not run (thus, the abort flag does not get set, and the loop continues to reiterate).  This is true regardless of whether the Off-macro gets triggered during the several-second delay periods of the looping macro, or if it gets triggered when the looping macro is actually switching cameras (i.e. - when it is issuing PLC commands).  Repeatedly firing the Off macro (with several seconds between each try) usually aborts the loop eventually, but sometimes not.  This behavior seems to indicate that the looping macro is actually blocking the Off-response macro from executing in many cases.  More puzzle...

(Actually, the preferred operation would be for the loop to abort immediately upon the execution of the Off-command - but I don't see a way to accomplish that, so the abort-flag method is a work-around).
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on November 30, 2011, 06:42:11 AM
... but most "robust" systems include means to deal with most of that sort of thing.  Unfortunately, it's looking more and more that the X10 protocols don't, for some reason. ???
The X10 protocol is quite old (It was invented in the 1970's). There were no cameras, motion sensors, etc when it was designed.
I certainly wouldn't consider it "robust" by any stretch of the imagination.

You had mentioned collisions (again), and that got me thinking: What are you using to get the RF signals back into your system?

The (unmodified) CM15A has a notoriously short RF reception range. Some people correct this by modifying their CM15A's antenna (either using the "warranty-friendly" mod, or one of the "warranty-voiding" mods). Others try to work around it by using other transceivers to try and get the signal.
If you have any TM751's, those could be causing some of your problems. They are "impolite," and don't wait for a clear line before transmitting. As a result, they can cause signal collisions, which can corrupt, or even kill other PLC commands already on the powerline.
I don't know if this is the case in your setup, but I figured I'd bring it up.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 30, 2011, 09:17:14 AM
The X10 protocol is quite old ...  I certainly wouldn't consider it "robust" by any stretch of the imagination.

Well, the key question/concern here would be how the X10 devices (either hardware or software) respond to "collisions" - for instance, do they even detect collisions and attempt any sort of recovery?  (I'm not sure, but seems like somewhere I read something that implied that the hardware does collision detection/recovery - at least some devices, and to some extent... but I have no idea about what the software does).  In any event, if "collisions" are indeed the primary cause of unexpected behavior with my macros, and if there is no effective collision-recovery built into the system/protocol, then I'll need to seriously alter the way I set up my hardware and my macros in order to try to compensate for this "omission".   B:(

You had mentioned collisions (again), and that got me thinking: What are you using to get the RF signals back into your system?

The (unmodified) CM15A has a notoriously short RF reception range. Some people correct this by modifying their CM15A's antenna (either using the "warranty-friendly" mod, or one of the "warranty-voiding" mods). Others try to work around it by using other transceivers to try and get the signal.

Actually, I'm not dealing with a lot of RF (because it is too short-ranged to serve my remote "stations").  In fact, the only RF devices here do not involve the motion-sensor/camera system.

I'm curious though:  What is the "warranty-friendly" CM15A mod... and is it also FCC-friendly?  ;)  If so, it might come in useful to know at some point.


If you have any TM751's, those could be causing some of your problems. They are "impolite," and don't wait for a clear line before transmitting. As a result, they can cause signal collisions, which can corrupt, or even kill other PLC commands already on the powerline.
I don't know if this is the case in your setup, but I figured I'd bring it up.
Thanks for the heads-up.... that's good to know.  I actually have several TM751's on-hand, but off-hand, I think that all of them have been taken out of service since I went with the CM15A and also "retired" most of my RF-based EagleEye motion sensors (which were used in the house to automatically manage some lamps - and had nothing to do with the surveillance system).
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on November 30, 2011, 09:40:40 AM
The X10 protocol is quite old ...  I certainly wouldn't consider it "robust" by any stretch of the imagination.

Well, the key question/concern here would be how the X10 devices (either hardware or software) respond to "collisions" - for instance, do they even detect collisions and attempt any sort of recovery?  (I'm not sure, but seems like somewhere I read something that implied that the hardware does collision detection/recovery - at least some devices, and to some extent... but I have no idea about what the software does).  In any event, if "collisions" are indeed the primary cause of unexpected behavior with my macros, and if there is no effective collision-recovery built into the system/protocol, then I'll need to seriously alter the way I set up my hardware and my macros in order to try to compensate for this "omission".   B:(
Since the X10 protocol was designed as a one-way protocol (with no confirmation of signal delivery at the far end), the hardware and software have no way to know if the message got through, or if there was a collision along the way.
If two commands go out on the powerline at the same time, they will generally corrupt each other, and (maybe) be detected as something entirely different, or (more likely) sound like garbage and be ignored.
The CM15A and RR501 DO have collision detection ONLY to the extent that they are "polite" and wait for the line to be clear before transmitting. (Don's ask me how they do it - others here can explain it much better than I can). I don't know about other PLC transmitters like PowerFlash modules, Mini controller, Maxi controller, or other PLC controllers.

Quote
You had mentioned collisions (again), and that got me thinking: What are you using to get the RF signals back into your system?
The (unmodified) CM15A has a notoriously short RF reception range. Some people correct this by modifying their CM15A's antenna (either using the "warranty-friendly" mod, or one of the "warranty-voiding" mods). Others try to work around it by using other transceivers to try and get the signal.

Actually, I'm not dealing with a lot of RF (because it is too short-ranged to serve my remote "stations").  In fact, the only RF devices here do not involve the motion-sensor/camera system.
You had mentioned motion sensors in your first post. If you aren't using X10's RF motion sensors, what ARE you using to trigger your macros?

Quote
I'm curious though:  What is the "warranty-friendly" CM15A mod... and is it also FCC-friendly?  ;)  If so, it might come in useful to know at some point.
You can search for CM15A Antenna Mods - there are a number of different ones out there. The one I was referring to involves taking a straight length of wire, about 18.5 inches long (I used #12 electrical wire, but a straightened coat-hanger works, too), and attaching it alongside the CM15A's antenna, making the bottom of the wire even with the "elbow" at the bottom of the CM15A's antenna. There is no electrical connection to the CM15A's antenna, and the only damage being done to the CM15A might be some residue from whatever tape or glue you use to attach the wire. I have done this mod on two different CM15A's. The first one I did (at first) with two strips of masking tape, which I later replaced with a spiral wrapping of electrical tape, purely for looks. The second time, I just slipped a length of heat-shrink tubing over the CM15A's antenna, and slid the wire in. The fit was snug enough that I didn't even bother to shrink the tubing down.
The wire acts as a "reflector", which helps to "catch" the RF signals, and "bounce" them to the CM15A's antenna. (aprdon my simple terminology, I'm not an engineer). Most people see at least *some* improvement, and some have reported amazing results with this very simple mod.

Quote

If you have any TM751's, those could be causing some of your problems. They are "impolite," and don't wait for a clear line before transmitting. As a result, they can cause signal collisions, which can corrupt, or even kill other PLC commands already on the powerline.
I don't know if this is the case in your setup, but I figured I'd bring it up.
Thanks for the heads-up.... that's good to know.  I actually have several TM751's on-hand, but off-hand, I think that all of them have been taken out of service since I went with the CM15A and also "retired" most of my RF-based EagleEye motion sensors (which were used in the house to automatically manage some lamps - and had nothing to do with the surveillance system).
Well, the TM751's (if you have any left) might still be causing problems. In fact, Any time you have multiple transceivers putting the same RF signals on the powerline, you have the potential for problems. Even double-triggering of a macro can wreak havoc, as the devices try to respond to a doubled set of commands.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on November 30, 2011, 04:07:33 PM
If two commands go out on the powerline at the same time, they will generally corrupt each other, and (maybe) be detected as something entirely different, or (more likely) sound like garbage and be ignored.
This is as I would expect... as well as what could well be happening here, based on the observed behaviors and the gibberish in the AHP logs at times.

The CM15A and RR501 DO have collision detection ONLY to the extent that they are "polite" and wait for the line to be clear before transmitting. (Don's ask me how they do it - others here can explain it much better than I can). I don't know about other PLC transmitters like PowerFlash modules, Mini controller, Maxi controller, or other PLC controllers.

Generally speaking, I should only have to worry about the CM15A and floodlight sensors (PR511, IIRC) as issuers of commands, and thus potential conflictors.  Any other PLC transmitters that may exist here would be "manual" and thus directly controllable as far as when they are activated.

You had mentioned motion sensors in your first post. If you aren't using X10's RF motion sensors, what ARE you using to trigger your macros?

The floodlight sensors - PR511, I believe.

... The wire acts as a "reflector", which helps to "catch" the RF signals, and "bounce" them to the CM15A's antenna. (aprdon my simple terminology, I'm not an engineer). Most people see at least *some* improvement, and some have reported amazing results with this very simple mod.
Interesting!  I take it the added antenna does not hurt the CM15A's transmitter?  (Probably fouls up the FCC certification... but who's telling!  ;) )

Well, the TM751's (if you have any left) might still be causing problems. In fact, Any time you have multiple transceivers putting the same RF signals on the powerline, you have the potential for problems. Even double-triggering of a macro can wreak havoc, as the devices try to respond to a doubled set of commands.
I don't think there are any... if there are, then they'd only overlap one House Code (each), not the entire 16 House Codes... and here, they would be on House Codes that are not part of the camera system anyway.

My macros shoudn't be double-triggering -er, well, double-executing- because the motion sensor response macros' conditions use monitored House Code units to "lock-out" re-entrant execution.  Specifically, the response macros' test for a monitored code that goes with a "zone indicator" light specific to the respective motion sensor;  if the unit is already On, then the macro's condition is not met (so it does not re-execute).  Otherwise it does execute and immediately sets the unit On.  When the motion sensor sends its Off command another macro turns the unit off and thus allows the next On command to execute the macro.  Assuming the macros behave, this would prevent a given macro from executing more than one instance at a time.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Brian H on November 30, 2011, 04:18:02 PM
The transmit antenna in a CM15A is a separate wire wrapped around the inside top piece of the case. Held on by what looks like hot glue.

The receive one is also a piece of wire. Threaded inside the external plastic tube. Unless X10 changed someting. About half of the receive antenna wire is also inside the case.  :' My early ones where in a random ball of knots. The later ones are at least wrapped neatly around the lower case and held again by the hot glue.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on November 30, 2011, 04:22:00 PM
...and the gibberish in the AHP logs at times.
Can you give us an example of the "gibberish"? That might help us figure out where it is coming from.

Quote
You had mentioned motion sensors in your first post. If you aren't using X10's RF motion sensors, what ARE you using to trigger your macros?
The floodlight sensors - PR511, I believe.
I don't know if those are "polite" or not. I don't have one myself. Perhaps someone else here has that answer.

Quote
... The wire acts as a "reflector", which helps to "catch" the RF signals, and "bounce" them to the CM15A's antenna. (aprdon my simple terminology, I'm not an engineer). Most people see at least *some* improvement, and some have reported amazing results with this very simple mod.
Interesting!  I take it the added antenna does not hurt the CM15A's transmitter?  (Probably fouls up the FCC certification... but who's telling!  ;) )
Nope. As Brian said (WHILE I was typing my response), The CM15A has separate antennas for transmitting and receiving. The external one is the receiving antenna.

Quote
Well, the TM751's (if you have any left) might still be causing problems. In fact, Any time you have multiple transceivers putting the same RF signals on the powerline, you have the potential for problems. Even double-triggering of a macro can wreak havoc, as the devices try to respond to a doubled set of commands.
I don't think there are any... if there are, then they'd only overlap one House Code (each), not the entire 16 House Codes... and here, they would be on House Codes that are not part of the camera system anyway.
Unless they are on separate power lines, ANY transmissions from a TM751 (on any house code) will step on a simultaneous transmission on the powerline.

Quote
My macros shoudn't be double-triggering -er, well, double-executing- because the motion sensor response macros' conditions use monitored House Code units to "lock-out" re-entrant execution.  Specifically, the response macros' test for a monitored code that goes with a "zone indicator" light specific to the respective motion sensor;  if the unit is already On, then the macro's condition is not met (so it does not re-execute).  Otherwise it does execute and immediately sets the unit On.  When the motion sensor sends its Off command another macro turns the unit off and thus allows the next On command to execute the macro.  Assuming the macros behave, this would prevent a given macro from executing more than one instance at a time.
I guess we would need to see a sample of what you are seeing in the Activity Monitor.
If the CM15A is picking up the signals from the PR511's, but isn't running the macros, that would lead us down a different path than if it isn't even seeing those commands at all.

Also, in case you weren't aware of it, conditional macros ignore all conditions when you manually trigger then from within the AHP interface. To properly test, you need to introduce the trigger signal some other way (like with a PalmPad, or another controller - or with the actual trigger device).
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 01, 2011, 09:33:01 AM
As Brian said (WHILE I was typing my response), The CM15A has separate antennas for transmitting and receiving. The external one is the receiving antenna.

That's good (I guess ;) ) although I think there may be more need for increased transmission range than reception range here, anyway... because the "inputs" are via PLC.

Unless they are on separate power lines, ANY transmissions from a TM751 (on any house code) will step on a simultaneous transmission on the powerline.

Duh!  (I guess that's what happens when I try to think while I'm half asleep!  :-[)


I guess we would need to see a sample of what you are seeing in the Activity Monitor.
If the CM15A is picking up the signals from the PR511's, but isn't running the macros, that would lead us down a different path than if it isn't even seeing those commands at all.

You're referring to the AHP log file?  If so, I don't have any saved (being such nonesense), and I'd have to capture some.

But, I'm puzzled:  Wouldn't the proper approach be to first understand the behavior/interaction of macros, as well as what commands are actually recorded in the logs (i.e. - "real" versus "virtual") - so that knowledge can be used to decipher the messes that show up in the log files?

Also, in case you weren't aware of it, conditional macros ignore all conditions when you manually trigger then from within the AHP interface. To properly test, you need to introduce the trigger signal some other way (like with a PalmPad, or another controller - or with the actual trigger device).

Painfully aware of that... it's one of my pet peeves about macro debugging!  Right up there with my peeve about having to re-download "Run in Interface" macros in order to test them...
 B:(

In fact, that raises a good question:  How do things foul up when the version of a macro that's in the interface's memory differs from the version of the macro that's in the PC's memory? (It's not clear from my observations as to even which copy executes in such cases... but clearly it makes something unhappy!)
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 01, 2011, 10:04:54 AM
As Brian said (WHILE I was typing my response), The CM15A has separate antennas for transmitting and receiving. The external one is the receiving antenna.

That's good (I guess ;) ) although I think there may be more need for increased transmission range than reception range here, anyway... because the "inputs" are via PLC.
What commands are you SENDING via RF from the CM15A?

Quote
I guess we would need to see a sample of what you are seeing in the Activity Monitor.
If the CM15A is picking up the signals from the PR511's, but isn't running the macros, that would lead us down a different path than if it isn't even seeing those commands at all.

You're referring to the AHP log file?  If so, I don't have any saved (being such nonesense), and I'd have to capture some.

But, I'm puzzled:  Wouldn't the proper approach be to first understand the behavior/interaction of macros, as well as what commands are actually recorded in the logs (i.e. - "real" versus "virtual") - so that knowledge can be used to decipher the messes that show up in the log files?
You're assuming that someone here KNOWS the logic involved in how the CM15A processes multiple macro commands. As I've said, we are (nearly) all users, who volunteer our time to help each other out. While there are X10 employees (the developers included) who have access to these forums, they don't spend their days monitoring the forums, and it is a rare occasion when then chime in on a discussion. In the past I've asked them to get involved in specific discussions, as I have done here. I haven't heard anything back yet, though.
Unless you've cleared the AHP Activity Monitor, you should be able to open it, and export it to HTML.
You can then copy and paste (cleaning up the formatting would be helpful for us here, if you can) into a post here.
What you SHOULD be seeing is the trigger (from the floodlight), followed by the commands in the macro executing.
If you can show us the other "garbage," we might be able to help you determine where it is coming from, and maybe figure out a way to eliminate it.

Quote
Also, in case you weren't aware of it, conditional macros ignore all conditions when you manually trigger then from within the AHP interface. To properly test, you need to introduce the trigger signal some other way (like with a PalmPad, or another controller - or with the actual trigger device).

Painfully aware of that... it's one of my pet peeves about macro debugging!  Right up there with my peeve about having to re-download "Run in Interface" macros in order to test them...
 B:(

In fact, that raises a good question:  How do things foul up when the version of a macro that's in the interface's memory differs from the version of the macro that's in the PC's memory? (It's not clear from my observations as to even which copy executes in such cases... but clearly it makes something unhappy!)
Again, I don't have that answer for you. Your best bet after making a change is to download it and test it using another signal source to trigger it.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 02, 2011, 08:38:01 AM
You're assuming that someone here KNOWS the logic involved in how the CM15A processes multiple macro commands. ...
Unless you've cleared the AHP Activity Monitor, you should be able to open it, and export it to HTML.
You can then copy and paste (cleaning up the formatting would be helpful for us here, if you can) into a post here.
What you SHOULD be seeing is the trigger (from the floodlight), followed by the commands in the macro executing.
If you can show us the other "garbage," we might be able to help you determine where it is coming from, and maybe figure out a way to eliminate it.
I regularly clear the Activity Monitor - because it avoids having to go back and figure out where the latest test session starts (because it's hard enough to trace through when I know where the session starts :().

Anyway, I'm just saying that once multiple macros start running, there is so much inconsistency and nonsense showing up in the log that I'd need some idea of how the processing occurs to even start trying to figure out whether the logged commands are consistent with that.  I also don't know whether to expect to see "real" or "virtual" commands logged - or both.  Sometimes it seems that it's one way, other times not...

Just to clarify, though:  So long as only one macro gets triggered at a time, the log very nicely reflects only the commands that result from the execution of said macro.  The nonsense shows up only when another macro gets triggered while one is already running... and then things often become totally untracable.  It seems plausible that this stuff may be the consequence of collisions -due to two macros sending commands at about the same time or whatever- because things can get really bizarre - like commands that don't exist in any of the macros nor would be issued from any of the hardware involved.  But, without knowning just what the log would record in such cases, it's really hard to tell anything for sure.

Again, I don't have that answer for you. Your best bet after making a change is to download it and test it using another signal source to trigger it.

It appears that it does need to be downloaded (so that everything matches) in order to test the changes.  Unfortunately, this is a real time-waster when iteratively trying to work out a kink in some macro.  Oh, well...
Title: Re: Questions about macros that respond to "real world" triggers
Post by: dave w on December 02, 2011, 10:22:36 AM

Just to clarify, though:  So long as only one macro gets triggered at a time, the log very nicely reflects only the commands that result from the execution of said macro.  The nonsense shows up only when another macro gets triggered while one is already running... and then things often become totally untracable.  It seems plausible that this stuff may be the consequence of collisions -due to two macros sending commands at about the same time or whatever-
$0.02
"Collisions" is a term to describe two X10 commands transmitted by two different X10 transmitting devices putting commands on the homes powerlines at the same time, thus corrupting each other. Obviously this requires at least one "impolite" X10 transmitter in the equation (i.e. a TM751).

IMHO "collisions" created by the CM15A trying to send multiple commands at the same time, is absolutely impossible. One reason is because all X10 commands are serial, and sequential.  The CM15A powerline interface circuitry can only send one command at a time, and I must assume the running program handles that internally, correctly. I have seen NO comments from any users that would hint otherwise, which obviously would indicate a serious software bug. Software wonks like Noam, Tuicemen, and many others on the forum can confirm or correct me. But, you are not the only user that has the possibility of more than one macro executing at the same time. I think you are making incorrect assumptions about "internal collisions" which is leading you astray.

As a side rabbit trail: I use Homeseer which requires a computer running the program 24/7. Homeseer feeds all X10 commands to a cache for serial transmission. I have "events" (what Homeseer calls a macro) that sends 68 X10 "OFF" commands which obviously takes over a minute to run, hence the requirement to move X10 commands waiting to be fed to the powerline interface to be buffered, so Homeseer can go back to running the main program.

I have no idea how AHP works, especially when the limited memory CM15A is running standalone mode. It *might* be that the CM15A does have to "hold" when it must transmit X10 commands. Have you tried running everything from the computer?   
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 02, 2011, 12:13:49 PM
Just to clarify, though:  So long as only one macro gets triggered at a time, the log very nicely reflects only the commands that result from the execution of said macro.  The nonsense shows up only when another macro gets triggered while one is already running... and then things often become totally untracable.  It seems plausible that this stuff may be the consequence of collisions -due to two macros sending commands at about the same time or whatever- because things can get really bizarre - like commands that don't exist in any of the macros nor would be issued from any of the hardware involved.  But, without knowning just what the log would record in such cases, it's really hard to tell anything for sure.
Here's my suggestion:
1. Clear the Activity Monitor, then trigger one macro at a time, to get a "clean" log of each macro's events. Safe out that log to a file (I suppose you could save it out, and then clear it separately for each macro  - that's up to you).
2. Clear the log again, and try to replicate a real-world scenario of multiple macros triggering in sequence. Save THAT out to a file.
3. Post the files here, with a description of what each one is, and we can take a look at them.

You keep mentioning "garbage" and "nonsense" in the logs, but you haven't given us any examples. Are these commands that don't look like valid X10 commands? Are they *actual* gibberish (random numbers, letters, etc)? Are they *valid* commands, but are not supposed to be running at that time?

One other thought I had was that perhaps a neighbor of yours also has X10, and has their own macros that share some of the same trigger codes as yours. Your macros firing (or maybe the devices that the macros are controlling) might be causing some of their macros to run, sending back commands you don't expect. It is pretty unlikely, but you never know. (Dan is probably going to chime in here with a comment that it is such a remote possibility because X10 was never mass-marketed. ;))

Quote
It appears that it does need to be downloaded (so that everything matches) in order to test the changes.  Unfortunately, this is a real time-waster when iteratively trying to work out a kink in some macro.  Oh, well...

For testing you might try changing the macro so it is set to "run from PC", and then re-downloading one time (which should clear the macro from the CM15A). You can then make more changes, and test, and then change it back to "run from interface" and download when your testing is complete.

One other thing I thought of. I don't have a PR511, but I looked up the instructions (http://software.x10.com/pub/manuals/pr511-om.pdf). It looks like it has the ability to send on/off commands to four different Unit codes based on motion sensing, and then a separate 4 codes based on dusk/dawn. Are you (intentionally or not) using any of those other codes? Might some of those be triggering other macros or modules unintentionally? Is it possible that the lights are aimed such that the light from one floodlight (or reflected off a surface) is fooling the dusk/dawn sensor into thinking it is daytime?

You *might* be able to test that my temporarily disabling the macros (either by changing their HC/UC to one that is DEFINITELY not being used, or by creating a temporary "blank" AHX file, and downloading it to the CM15A), and then watching the activity Monitor as you try a "real world" test of triggering the motion sensors (just looking at what they do, and when, without any macros to muddle things up).
Title: Re: Questions about macros that respond to "real world" triggers
Post by: HA Dave on December 02, 2011, 07:03:33 PM
"Collisions" is a term to describe two X10 commands transmitted by two different X10 transmitting devices putting commands on the homes powerlines at the same time, thus corrupting each other. Obviously this requires at least one "impolite" X10 transmitter in the equation (i.e. a TM751).
IMHO "collisions" created by the CM15A trying to send multiple commands at the same time, is absolutely impossible.

I agree. However.... the OP in this case is using Floodlights (PR511)... which can send up to 4 impolite PLC's per motion sensing. I don't know how many Floodlights are in use... but since the OP is switching 16 cameras... I would guess more than 1 floodlight.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: dave w on December 02, 2011, 09:16:31 PM

I agree. However.... the OP in this case is using Floodlights (PR511)... which can send up to 4 impolite PLC's per motion sensing. I don't know how many Floodlights are in use... but since the OP is switching 16 cameras... I would guess more than 1 floodlight.
I'm not sure, but since the PR511s have X10 transmit and receive capabilities, I think they are polite.
But MD is concerned that CM15 running two macros at same time is creating collisions....
Title: Re: Questions about macros that respond to "real world" triggers
Post by: HA Dave on December 02, 2011, 09:55:45 PM
..... MD is concerned that CM15 running two macros at same time is creating collisions....

Yeah... I can't imagine the CM15A tripping on itself.... I've never seen it.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: dave w on December 03, 2011, 09:43:00 AM
..... MD is concerned that CM15 running two macros at same time is creating collisions....

Yeah... I can't imagine the CM15A tripping on itself.... I've never seen it.
No, I don't think it possible either. I think MD has much simpler problem that he isn't recognizing. His posts indicate the Activity Monitor is full of garbage, making him think the CM15A is trying to send multiple commands at the same time. That would be a software/hardware problem that would quickly be evident to all users, developers, and forum members. But I guess MD does not see it that way.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 03, 2011, 11:42:05 AM
Wow!  Lots to reply to...  So, rather than trying to quote everyone, I'll just list my replies here that refer back to others' comments:

"Collisions":  I'm using this term rather loosely to describe any potential command collisions, whether they be hardware collisions in the PLC, or virtual command collisions somehow caused when multiple macros run at the same time - as seems to be implied by the logging that I've tried to decipher.  The possibility that stands out to me from these observations is because it sometimes looks like parts of a command from one macro are mingled with part or all of a command from another macro, it may be that conncurrent macros are somehow overlapping the discrete portions of their PLC commands.  This is the "gibberish" that I am referring to:  Not only are commands not occuring in the expected sequence, there are places where it looks like only half of a command pair is in the log, or it may be "split", with other commands being logged between the first and second part of a command.  (I'll emphasize that this is only speculation, since the stuff I saw is really hard to follow).  There is no "garbage characters" in the log, as far as I can tell - only "garbage commands".  My best guess may be that something is getting corrupted somehow, and the logging facility is mis-interpreting it as some other command... otherwise, it's just utter nonsense or literally random commands flying around.  And, yes, I will try to capture some examples to pass along, when time permits.

I make no claims about why this stuff occurs;  but it is obviously associated only with more than one macro running at a time... and I'm trying to figure out why.  Maybe my macros are bogus;  maybe my CM15A is fouling up; maybe AHP is fouling up; maybe there are PLC collisions that the log file (and the X10 devices) mis-interpret as something other than what they are... I really don't know.... it is all guesses at what may be going on here.

(By the way, would AHP or SmartMacros foul up if AHP logical devices have not been defined for each and every House/Unit Code used in the macros, or if more than one logical device exists for the same House/Unit Code, or if the logical device is not exactly the same device as the corresponding physical device?  (Due to revisions in my AHX, it is possible that some or all of these conditions exist, although I'm not specifically aware of any).)

Generally, I have not tried running everything from the PC;  that is mainly because the ultimate intention is to run everything stand-alone in the CM15A, so doing it on the PC may allow subtle differences to creep in - such as PC-only commands, or memory issues, or flag issues, or timing issues, or other unexpected glitches/nuances.  For a general troubleshooting effort, it would be worth a try - but I haven't done that as a matter of course because I figured it might introduce needless time-wasting execution-time problems.  (Of course, there are time-wasting development-time problems doing it the other way, so who knows which is better).

I have about a dozen PR511 Motion Sensors in use; they are configured for 24/7 operation, and do not have the dusk/dawn output codes enabled at all.  After going to AHP/SmartMacros, each PR511 is set to issue only one (unique) output code - although I suppose it is possible that there might be a problem with the device(s), or an overlooked setting switch, where some other code could be issued, too - but I have not seen any evidence of that during individual testing.  One thing that is a nagging question is whether having one PR511 issuing the base code of another PR511 would cause one of them to foul up somehow - but again, I have not seen any indication of that while testing "individually".

Actually, I was thinking myself of that deal to strip out everything from AHP and from the CM15A, and just run tests with the Monitor enabled, and see what goes on.  I was wondering whether the Log would work right if there were no logical modules defined, though.  Anyway, I have not done that, and I'm becoming less convinced that it is worth the effort the more I think about it... but it may still come to pass.

When I have logged the results of the single macros, they generally show as running exactly as prescribed in the macro definitions.  When two macros run at once, all bets are off:  The log shows commands that seem to be properly formed, but tend to be out of sequence in various ways - like delays that don't work, commands that seem to be bogus (based on the text placed in the log), macros that stop in the middle and never finish, and "split pairs" of commands.  It all becomes untracable, as far as I can see.

As for a neighbor having conflicting X10 commands, I tend to doubt that for several reasons:  There are no nearby neighbors; we have our own line transformer (nobody else feeds from it), there is some isolation filtering on the incoming line, I have never detected spurious commands when I am not using the macros, and the Find Other Computers has never reported any "foreign" stuff.

As for TM751's, I have confirmed that there is only one now in the system - and it is used only to control lights in a barn via macro action, and thus uses a House Code that is not being used by anything else in the system.  (Specifically, macros set to its House Code simply "transceive" commands from a hand-held and re-issue the correct actual House/Unit codes for the lights.  Thus, the TM751 should never issue any PLC except if I explicitly issue RF commands for its House Code - which has never happened since I tested the original installation because I have no longer use the old hand-held remotes.

One thing that worries me in regards to spurrious commands is the presence of an Active Phase-Coupler/Repeater in the system, but I don't see anything screwy when executing macros individually, nor when issuing PLC directly, so... ???

Regarding a simple problem that I'm not recognizing, I'm all ears:  please explain!  If there is a simple solution to this mess, then I'd love to know what it is.  If these issues actually do not afflict anyone elses' system, then it implies there is some problem specific to my system - but what?  I have tested everything to death, and nothing conclusive comes of it.  There is some slight suspicion that some of the X10 devices were "flakey", but testing - even replacing - them hasn't materially changed the situation, so I'm baffled.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: dave w on December 03, 2011, 05:47:37 PM
Regarding a simple problem that I'm not recognizing, I'm all ears:  please explain!  If there is a simple solution to this mess, then I'd love to know what it is.  If these issues actually do not afflict anyone elses' system, then it implies there is some problem specific to my system - but what?  I have tested everything to death, and nothing conclusive comes of it.  There is some slight suspicion that some of the X10 devices were "flakey", but testing - even replacing - them hasn't materially changed the situation, so I'm baffled.
"If there is a simple solution to this mess, then I'd love to know what it is". Obviously there isn't or you would have found it by now....

What I would do in your situation:
1. Run everything from the computer. X10 isn't going to tell you how the CM15A handles multiple macros. By running from the computer (at least for testing) you can assume AHP has all the memory it needs to buffer, cache, run multiple threads, etc. etc. etc.
2. Using the Activity Monitor log, test all "inputs" one by one to verify their inputs are reliably getting to the CM15A all the time, (Motion sensors, PR511, etc.).
3. Using the Activity Monitor log, a Palm Pad and TM751, or wired controller, manually test each of your macros one by one by initiating the trigger via the Palm Pad or wired controller to verify they (singely) execute correctly.
4. Repeat # 3,  only now manually trigger multiple macros.
5. Assume your problem is external to the CM15A and not a "macro collision/execution" problem and troubleshoot on that basis. (Unreliable signal reception, noise, etc).
6. Don't look for a magic wand solution. There probably ain't one.  
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 03, 2011, 06:25:38 PM
What I'll add to Dave's suggestions:

Map out your ENTIRE process. On a big sheet of paper.

Each macro should get its own path, and draw lines where one macro triggers another, etc.

You mentioned that you might not have all devices defined, or not properly. That could certainly be causing problems.
Don't share the save HC/UC between device types (or between SoftStart and non-SoftStart devices). Ever. (The only exception would be a "dummy" appliance module set to the same HC/UC as a macro, and used to call that macro from another macro.)

Any command you are sending from a macro should be linked to a VALID (and properly defined) device in your AHP setup.

Clear your AHP trash can. Macros have been know to still run from the trash in some cases.

If you still can't make heads or tails of it, post your AHX file here. Give us a description (as detailed as possible) of what each macro SHOULD be doing, and what triggers it. Also give us a sample of the logs from those macros running (individually, AND concurrently). Maybe one of us will see something you might not have noticed.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 04, 2011, 06:40:42 PM
Although I think we're getting beyond the scope of what I want to get a handle on, and have moved into the larger realm of trying to figure out the entire situation (which likely does involve other factors), let me report the findings I have so far relating to your proposed course of action:

What I would do in your situation:
1. Run everything from the computer. X10 isn't going to tell you how the CM15A handles multiple macros. By running from the computer (at least for testing) you can assume AHP has all the memory it needs to buffer, cache, run multiple threads, etc. etc. etc.
2. Using the Activity Monitor log, test all "inputs" one by one to verify their inputs are reliably getting to the CM15A all the time, (Motion sensors, PR511, etc.).
3. Using the Activity Monitor log, a Palm Pad and TM751, or wired controller, manually test each of your macros one by one by initiating the trigger via the Palm Pad or wired controller to verify they (singly) execute correctly.
4. Repeat # 3,  only now manually trigger multiple macros.
5. Assume your problem is external to the CM15A and not a "macro collision/execution" problem and troubleshoot on that basis. (Unreliable signal reception, noise, etc).
6. Don't look for a magic wand solution. There probably ain't one.  
1. I have not yet tried running things from the PC only, so -given some time to set it up- I can do that and see what effect it has on things.  (Off the cuff, my guess is that it will simply slow things down a bit, but... the proof will be in the pudding, as they say).

The rest are results that I have obtained while using "Run in interface" mode, but are still useful information:

2.  All inputs (and their macros) have been demonstrated to work properly, individually - although "all the time" is not really possible to tell.  So, the question would be how long do they need to work reliably in order to say they are "OK"?  (So far, I have not found any errors in the inputs).
3.  I have done essentially the same thing using either the Icon Remote (which, of course is transceived by the CM15A), and from the actual motion sensors.  (I don't know whether the transceived inputs from the Icon Remote via the CM15A are going to accurately reflect the "real world" situation, but things do work properly that way - at least when only one macro is triggered at a time).
4.  When I have done this via the Icon Remote, in general terms, the results are consistent with "real world" execution of multiple macros - that is, things screw up significantly.  I will say, though, that they often seem to get more mucked up when they come from real world triggers than from my attempts to run them manually.  In any case, the results are more or less consistent with the results from multiple real-world triggers: screwed up.
5.  Making that assumption seems that it would unreasonably lead down the proverbial "rabbit trail", because all testing to date does not reveal any such "external" problems AND all observed problems show up only while using macros.  So, to arbitrarily assume the opposite makes no sense.
6.  I'm not looking for magic wand solution;  my intention in starting this thread was to try to gain understanding of how the macros behave and interact with each other - so that I could apply that knowledge to troubleshooting and macro design.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 04, 2011, 07:00:48 PM
...
You mentioned that you might not have all devices defined, or not properly. That could certainly be causing problems.
Don't share the save HC/UC between device types (or between SoftStart and non-SoftStart devices). Ever. (The only exception would be a "dummy" appliance module set to the same HC/UC as a macro, and used to call that macro from another macro.)

Any command you are sending from a macro should be linked to a VALID (and properly defined) device in your AHP setup.

Clear your AHP trash can. Macros have been know to still run from the trash in some cases.

...

Do you have any feel for what issues would result from having commands on the PLC for devices that have not been defined in the AHX? (This would be the same situation if I try to use the Log file on a "bare" system, only worse there).

I don't believe there are any situations where multiple physical devices share the same code.  The situations I was referring to are in the nature of defining a simple virtual Appliance Module for a dimmable physical Lamp Module.  This is because I use only On/Off control for those particular lights, and the "correct" virtual modules cause bright/dim commands to be issued for simple on/off functionality, and thus slow down the execution considerably - as well as allowing more "room" for collisions to occur, due to the extended-duration commands.  (All such cases are "output devices" as far as the macros are concerned... that is, they are controlled-only, and do not do any macro triggering).

If macros run from the trash can, then that re-visits my earlier question about which macro actually runs if you have one version in the interface, and another in the PC.  Now, it appears that we must also deal with a third possibility... which begs the question of which one is going to run if a macro having the same trigger code exists in all three places?  Hopefully, there is some definitive answer to that question... although if X10 is not going to say how multiple macros behave, then probably there is little chance of getting this answer, either... and, IMO, withholding those answers are serious problems.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 04, 2011, 09:19:08 PM
I'm going to try and work backwards through this one.
1) I don't think they are "withholding" the information. They just haven't gotten around to giving it to us yet. As I (and others) have said, the X10 reps aren't reading the boards every day. I've sent e-mails off to one of the developers, but he might be on vacation.

2) There ARE bugs and design flaws in AHP. Nobody is disputing this (we have a long list here: http://forums.x10.com/index.php?topic=22373.0). However, there are things that can be done to minimize their effects (ie: workarounds). Emptying the trash is one of these workarounds.

3) If you are defining a "virtual appliance module" for a physical lamp module, do you also have the lamp module defined in AHP?

4) If you don't have the modules defined in AHP, how are you sending them commands in the macros? Are you using the advanced function to send the discrete codes directly from the macro? The preferred way to do it is to define the modules (properly) in AHP, and use those in the macro sequencing.

5) If the macro operation seems to get MORE messed up with the real motion sensors, then perhaps something isn't set up correctly, or the motion sensors aren't configured right (or aren't working properly).
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 05, 2011, 07:53:46 PM
1)  I am not so much inclined to give X10 the benefit of the doubt because they actually have withheld necessary operational and usage information from me in the past, that caused me to waste a lot of time unnecessarily (due to figuring things out - sort of - via trial and error) and even prevented me from solving problems that prevented successful use of some devices.  I have no idea why they keep things so "close to the vest", as it doesn't appear that we were treading close to anything proprietary.

In any case, it makes me wonder if the same situation is occuring with the info for the software... but the real bottom line is that people can't use the stuff properly/effectively if they don't have all of the necessary information... and I feel that not providing it (for whatever reason) is just plain unacceptable.  Imagine if someone like National Instruments were to sell their FieldPoint equipment without providing full information about programming the devices, or not providing the full specs for interfacing their devices to other equipment.  I don't think they'd sell much of the stuff - at least not for very long.

Anyhow...  back at the ranch:
2)  I don't have a problem, per se, with flaws and bugs;  it becomes a problem when there are no steps taken to correct the bugs, or no information provided to achieve temporary patches while problems are being corrected... especially if it means that an entire system is out of service due to the problems.

Regarding emptying the trash, in my case, I typically do not have anything "residing" in the trash, so I'm guessing that is not an issue here - but I will make sure of that in the future.   I will also review the list of problems and work-arounds to see if there is anything applicable there.

3)  In such cases, the virtual module is (of course) defined in AHP but there is no "correct" virtual module also defined in AHP - that is, no duplicate virtual modules exist for any given physical module.

4)  I'm not sure I understand the question here;  possibly there is some misunderstanding of what I have been saying?  There are AHP virtual modules (of some type) defined for each controlled physical module... so I'm not sure that I follow the question here.

Note:  Please be aware that the cases where a surrogate virtual module is used in place of the "correct" virtual module are very limited in scope, to perhaps three "special case" modules at most... it is not a typical or widespread implementation, and certainly does not involve all of the macros by any stretch.

5)  Again, I'll have to raise the question of how to define "set up correctly".  When it comes to the PR511s, the question of "correct" settings often raises its ugly head... as far as getting the anticipated results in actual operation.  (By the way, this is one of the areas where information was withheld, as mentioned earlier).  And, based on past experience, it is entirely possible that one or more of the PR511s is not working properly... but, if that is the case, then it must be connected somehow with macro action - because that is the only time any glitches are seen currently.

Please keep in mind during this discussion that the hardware in this system (and the supporting electrical system) has already been tested exhaustively - to the extent that it can be evaluated without specialized test equipment - and no known hardware or "infrastructure" problems currently exist.  It is quite literally a case where the problems show up only when multiple macros execute at the same time.  I'm not ruling out some sort of hardware problem, but the circumstances seem to indicate that is a very low probability, so I'm inclined to believe that chasing such trails is likely just a waste of time.  At worst, it would be a case where some otherwise undetected hardware problem(s) manages to show up only in association with multiple macros running... so logically, those aspects would be the most likely suspects to investigate.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 05, 2011, 10:23:19 PM
Okay, I give up. I have no idea why your system won't work right.
Without seeing your AHX files and/or your logs, there isn't much more I can do to help you. Sorry.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 05, 2011, 11:11:19 PM
Okay, I give up. I have no idea why your system won't work right.
Without seeing your AHX files and/or your logs, there isn't much more I can do to help you. Sorry.

No problem... (That makes two or three of us who have thrown up our hands over this).  Just to be clear, though:  The "system" works; the macros don't.  We actually had a limited-functionality hardware-only system working at one time, but needed to overcome some limitations (like not being able to control a VCR) and the AHP system -supposedly- offered ways to handle the limitations, ability to control the VCR, ability to coordinate multiple cameras, added system flexibility, and even ways to add some bells and whistles.  Between its actual inability to coordinate cameras and the macros fiasco, it's looking look like AHP was more mistake than benefit.

I will see what I can do later this week about generating some sample logs that show the garbage that occurs when two or more macros run at once.  I hope someone can make more sense of them than I have been able to.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 06, 2011, 02:42:12 PM
I will see what I can do later this week about generating some sample logs that show the garbage that occurs when two or more macros run at once.  I hope someone can make more sense of them than I have been able to.

As I've said, I'm more than willing to take a stab at it, but you haven't given us any data to look at.

Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 17, 2011, 02:38:24 PM
I will see what I can do later this week about generating some sample logs that show the garbage that occurs when two or more macros run at once.  I hope someone can make more sense of them than I have been able to.

As I've said, I'm more than willing to take a stab at it, but you haven't given us any data to look at.

Well, it has taken some time to get to this with everything going on around here, but I now have some sample logs.

Unfortunately, I have not been able to capture any of the really wild (gibberish) stuff where it looked like there were totally "foreign" commands showing up, or partial commands, etc., but the sample log did get fairly confusing - especially towards the end... so, maybe that is at least worth taking a look at, because there might be some clue there.  As time permits, I'll try to capture some of the really wierd stuff, too.


Meanwhile, here's what I did:

First, I ran each of the three typically offending macros via a remote trigger (to get a log of what they should look like when they run without any sort of interference from concurrent macros).  I saved the AHP Activity Log file after each run, and then cleared the Activity Log for the next run.  These "stand-alone" samples all appear to be pretty consistent with their associated macros, both in terms of commands being correct and in the proper order, and delays working more or less as expected.  (Note:  I ran the daytime version of these macros, because the night versions get even more "hairy" with lighting control actions - so I figured the simpler forms would be better for now).

Second, I cleared the Activity Log, and then went out and triggered the actual motion sensors under "typical" conditions of someone walking through the area.  I then came in and waited until all the motion sensors had issued their respective turn-off commands, and then saved the resulting log to a file.

It looks like the "actual run" log initially shows that the first macro is running normally;  then the second sensor triggers, but it looks like all commands in the log are still coming from the first macro.  Then the third sensor triggers and it looks like some commands are getting interspersed occasionally, but essentially it is still the first macro running.  Then things start getting confusing, and I'm not really sure what is running - although I think all the logged commands can be attributed to one of the three macros... but it looks like the delays are not always correct - or maybe not happening at all.  Anyway, it becomes quite confusing, and doesn't seem like things are happening in their proper order, etc.

Over all, my impression is that the subsequently-triggered macros don't really run while the first macro is already (still) running, although at some point, they do seem to start getting muddled together - but that's quite awhile after the subsequent macros get triggered... so there must be more to this than macros simply running concurrently.

So, let me know what you make of it....

(Note:  I had to rename the .htm log files to .txt extensions in order to attach them here).
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 17, 2011, 06:53:36 PM
Thanks for sending the logs.
It will take me a little while to go through them, and compare the "actual" run to the "testing" runs.
One more thing that might help, if you can, would be to post a list of the commands in each macro.
something like this:

Camera C5 On
Delay 5 seconds
VCR On
Indicator light N1 on

etc.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 18, 2011, 01:24:01 PM
Thanks for sending the logs.
It will take me a little while to go through them, and compare the "actual" run to the "testing" runs.
One more thing that might help, if you can, would be to post a list of the commands in each macro.
something like this:

Camera C5 On
Delay 5 seconds
VCR On
Indicator light N1 on

etc.



Yeah, I was going to do that, but I didn't see any easy way to output only that specific info;  is there some "quick and dirty" way to get only that stuff - without having to type it out manually, nor dump the whole works?
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 18, 2011, 10:24:33 PM
Thanks for sending the logs.
It will take me a little while to go through them, and compare the "actual" run to the "testing" runs.
One more thing that might help, if you can, would be to post a list of the commands in each macro.
something like this:

Camera C5 On
Delay 5 seconds
VCR On
Indicator light N1 on

etc.



Yeah, I was going to do that, but I didn't see any easy way to output only that specific info;  is there some "quick and dirty" way to get only that stuff - without having to type it out manually, nor dump the whole works?
Nothing that I know of.
The best way would be to type it out. That would also give you a chance to double-check the macro sequencing, and see if there might be something contributing to the issues you are having.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 20, 2011, 02:29:28 PM
I started taking a look at your log files.
Without a clear idea of what each macro is *supposed* to do, I'm having a lot of trouble just following a singe macro's execution.

I looked at the "Entry Macro Sensor" log, and I can't tell where there are supposed to be delays, or if there are other macros being triggered from within these or not. It is really hard to follow what this macro is trying to do.

When you get a chance to post the step-by-step execution of what each macro is supposed to be doing, I think that will help me out.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 21, 2011, 10:12:53 PM
I started taking a look at your log files.
Without a clear idea of what each macro is *supposed* to do, I'm having a lot of trouble just following a singe macro's execution.

I looked at the "Entry Macro Sensor" log, and I can't tell where there are supposed to be delays, or if there are other macros being triggered from within these or not. It is really hard to follow what this macro is trying to do.

When you get a chance to post the step-by-step execution of what each macro is supposed to be doing, I think that will help me out.

Here are the basic macros and -hopefully- all of the possibly-associated macros.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 21, 2011, 10:45:07 PM
Wow.
I took a look at two of the files. That's a really complicated setup you have.
It will take me a while to go through everything, and look at what it is trying to do.
One thing that struck me as odd, however, is in the "Entry Sensor Macros," It looks like you are turning on camera C3, and then turning it right off. What's the point?

If you could provide a short paragraph, explaining what each macro is supposed to do (turns on camera 1, then switches to camera 2, triggers macro that rings a bell, feeds the cat, makes the coffee, and fetches my slippers), that would also be helpful.
I have a feeling you might have just made everything too complicated, and that's why you are running into issues.
You say that each macro works fine on its own, but it looks like you have macros calling other macros, and possibly having those call others. I still haven't gotten an answer about the command buffer, or the order of operations when one macro is called while another is working.
I know that the execution of the first one doesn't stop (it doesn't matter if the second one was called by the first, or by some other independent trigger), but where the new macro's commands fit in isn't all that clear to me.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 22, 2011, 10:07:49 PM
Wow.
I took a look at two of the files. That's a really complicated setup you have.
It will take me a while to go through everything, and look at what it is trying to do.
One thing that struck me as odd, however, is in the "Entry Sensor Macros," It looks like you are turning on camera C3, and then turning it right off. What's the point?

If you could provide a short paragraph, explaining what each macro is supposed to do (turns on camera 1, then switches to camera 2, triggers macro that rings a bell, feeds the cat, makes the coffee, and fetches my slippers), that would also be helpful.
I have a feeling you might have just made everything too complicated, and that's why you are running into issues.
You say that each macro works fine on its own, but it looks like you have macros calling other macros, and possibly having those call others. I still haven't gotten an answer about the command buffer, or the order of operations when one macro is called while another is working.
I know that the execution of the first one doesn't stop (it doesn't matter if the second one was called by the first, or by some other independent trigger), but where the new macro's commands fit in isn't all that clear to me.

I have attached description files for the macros.  I think the description will answer your question about the camera control.  Generally speaking, though, most everything in those macros is done to compensate for or workaround hardware limitations or problems, or idiosyncracies.  It is a pain in the a**, but those "fixes" were a big part of the reason for going with the macros rather than a hardware-only system.  I do, however, feel that the actual purpose of the macro steps is irrelevent to their proper functioning in an absolute sense.  It certainly may be that there is some logic error that might lead to undesired outcomes... but, that in itself should have no bearing on whether the macros execute the steps in the proper sequence, depending on the individual instance.

I have to disagree with both the idea that the macros are "too complicated" and the idea that complexity would lead to the malfunctions seen.  (If this is indeed the case, then one can only presume that the macro software is pretty weak).

When I said that each macro works OK on its own, I was actually referring to the macro and its called sub-macros as a unit... which, of course, implies that each sub-macro also works OK by itself, too.

From the logs I've examined, it appears that the first macro generally retains control until it completes (or until it hits a delay command), at which time, commands from other "pending" macros show up in the log.  After that, it often becomes unclear whether the first macro resumes, or what actually is going on.  If there is some limitation to the "depth" of the calling tree, then it may be possible that these macros are exceeding that depth, and thus fouling up.  However, in such case, it is apparently the multiple motion sensors that are "overloading" the "queue", because the macros do work OK individually - as can be seen in the sample logs.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 22, 2011, 11:42:54 PM
I have to disagree with both the idea that the macros are "too complicated" and the idea that complexity would lead to the malfunctions seen.  (If this is indeed the case, then one can only presume that the macro software is pretty weak).
Well, it was written 7 years ago, and hasn't really been changed since. It was never designed to do a lot of what people are actually doing with it (like calling one macro from another, for example), so it is perfectly reasonable to me that it has certain limitations, and it is possible to exceed those limitations with a large setup.

Quote
When I said that each macro works OK on its own, I was actually referring to the macro and its called sub-macros as a unit... which, of course, implies that each sub-macro also works OK by itself, too.
Well, that's something the system was never designed to do in the first place. Why do you think we need a workaround to call one macro from another in the first place?

Quote
From the logs I've examined, it appears that the first macro generally retains control until it completes (or until it hits a delay command), at which time, commands from other "pending" macros show up in the log.  After that, it often becomes unclear whether the first macro resumes, or what actually is going on.  If there is some limitation to the "depth" of the calling tree, then it may be possible that these macros are exceeding that depth, and thus fouling up.  However, in such case, it is apparently the multiple motion sensors that are "overloading" the "queue", because the macros do work OK individually - as can be seen in the sample logs.
Once again, there is a limit to what the CM15A can do. You might have found it.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 23, 2011, 09:19:40 AM
I have to disagree with both the idea that the macros are "too complicated" and the idea that complexity would lead to the malfunctions seen.  (If this is indeed the case, then one can only presume that the macro software is pretty weak).
Well, it was written 7 years ago, and hasn't really been changed since. It was never designed to do a lot of what people are actually doing with it (like calling one macro from another, for example), so it is perfectly reasonable to me that it has certain limitations, and it is possible to exceed those limitations with a large setup.

It is entirely likely that there are limitations in the design, but my expectation is that such limitiations as apply here are unrelated to the size of the setup, but rather should manifest whenever an attempt is made to do something that is beyond the limitations - even if the setup is nothing more than a single three-action macro.  All indications seem to be that the problem here arises due to macros being triggered while other macro(s) are already running.  This itself may be a design limitation, yet it is a bit surprizing because one might expect this sort of macro system to be designed to support asynchronous "real time" triggers - because that is the basic type of "system" that it would be used with in virtually all applications.

(I'm also a bit puzzled by the statement that it hasn't changed much in a long time... because it seems there are frequently new versions that must be updated to).


Quote
Quote
When I said that each macro works OK on its own, I was actually referring to the macro and its called sub-macros as a unit... which, of course, implies that each sub-macro also works OK by itself, too.
Well, that's something the system was never designed to do in the first place. Why do you think we need a workaround to call one macro from another in the first place?

Again, that is a surprising "deficiency" for a system that is intended for this type of environment... and, in fact, the primary reason why I find it necessary to have one macro call another is simply to implement conditional actions that need to occur in places other than at the start of a macro thread.

Another big reason for having "subroutines" in a "tight" memory system is to save memory by having only one copy of common "code" - instead of repeating that same "code" in each place where it is needed.  The lack of support for such "subroutines" is really out of place in this type of environment.

Another thing with "subroutines" is that it makes changes and fixes easier to implement - since they need be done only in one place - instead of in a bunch of copies of the same "code"... but I would think all of this would be well-known to any software developers, so... ???


Quote
Quote
From the logs I've examined, it appears that the first macro generally retains control until it completes (or until it hits a delay command), at which time, commands from other "pending" macros show up in the log.  After that, it often becomes unclear whether the first macro resumes, or what actually is going on.  If there is some limitation to the "depth" of the calling tree, then it may be possible that these macros are exceeding that depth, and thus fouling up.  However, in such case, it is apparently the multiple motion sensors that are "overloading" the "queue", because the macros do work OK individually - as can be seen in the sample logs.
Once again, there is a limit to what the CM15A can do. You might have found it.

OK, I think that gets to the crux of a lot of the problems here:  There are a lot of unexpected limitations, yet there is no detailed documentation on what they are, how they occur, how to avoid them, etc.  This makes it really hard to use the system effectively.  I find very few "how-to's" regarding "proper" design of macros - telling not only how to make the macros work as intended, but also how to avoid causing hardware problems as a result of macro (mis-)behavior.  If any such concise documentation exists, I've somehow missed it entirely.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 23, 2011, 11:11:40 AM
(I'm also a bit puzzled by the statement that it hasn't changed much in a long time... because it seems there are frequently new versions that must be updated to).
If you look back at the AHP revision history: http://www.x10.com/support/rev_ahp.htm , you will see that a lot of the updates were for bug fixes.
The SmartMacros plugin is the ONLY one (that I can think of, at least), that is capable of running entirely within the CM15A, and does not require the PC to be connected. All of the other plugins (which were released alter) added functionality that the CM15A could not handle alone, and required the PC. The SmartMacros plugin was released very soon after AHP and the CM15A were introduced, and the functionality in it hasn't really changed (other than a few bug fixes and minor tweaks, some of which only affected macros that ran from the PC). Why do you think there isn't a built-in way to call one macro from another, and that to do so you need to create a "dummy" module to be called? It was never part of their original design, perhaps due to the unreliability of concurrently running macros. I don't know for sure, that is only a guess.

It still seems to me like you are trying to put together a process flow that is beyond the scope of what the CM15A was designed to do.
As others have mentioned, tehre are software packages (many of them free) that have been written for the PC that will control the CM15A, and offload all that logic and processing to the PC. They are much more powerful, and can do a lot more than you can do with the CM15A alone. For your setup, it might be worth looking into it, just to see what else is out there.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 23, 2011, 12:08:15 PM
I took a look at one of your description files.
A few things I noticed:
1. You are turning on cameras, and then turning them right back off (with no delay). I don't understand why.
2. At one point you turn OFF a single camera, with a note that it turns off the other cameras in that group of four. I don't know if that works. I know that if you turn one ON, the other three go off, but I don't know if sending an "off" to one of them turns off all four.
3. You seem to be calling a lot of sub-macros. Why not just put the actions all in one macro? Are those sub-macros also condition based? (that's the only reason I see for sub-macros being called like that).

the CM15A can only send one command at a time. So, if you want a sub-macro to run to completion before the main macro continues, then you might want to put a long enough delay into the main macro to accomplish that.
Another way to do it might be to have the main macro end with the execution of the sub-macro. Then, the sub-macro can call the next macro when it finishes.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Brian H on December 23, 2011, 12:36:53 PM
#2 Turning Off any camera in a group will not turn the rest Off.
Only an On to one in the group. Turns the rest in the group Off.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 24, 2011, 03:17:30 AM
(I'm also a bit puzzled by the statement that it hasn't changed much in a long time... because it seems there are frequently new versions that must be updated to).
If you look back at the AHP revision history: http://www.x10.com/support/rev_ahp.htm , you will see that a lot of the updates were for bug fixes.
...


I suppose it depends on whether those are bugs or features...  ;)

Seriously, though, I know some of that stuff was intended to provide "enhancements" - although probably nothing that was particularly relevent to the issue here.


Quote
It still seems to me like you are trying to put together a process flow that is beyond the scope of what the CM15A was designed to do.

As I've mentioned, the reason for my using the CM15A and macros in the first place was because the X10 hardware alone could not handle multiple-camera setups consisting of more than four cameras, and their recommended "solution" was to employ the AHP/SmartMacros - which they claimed would support switching of multiple banks of cameras (which it does not actually do on its own, by the way - leading to all the camera manipulations in my macros).  AHP also was supposed to enable "work-arounds" for other hardware problems or limitations, although I guess that was all left to the users to figure out on their own. :o  So, if I am going beyond the capabilities of the CM15A or AHP, it is only because X10 told me that was what I needed to do in order to get past the hardware issues, not because of any desire of my own to "make things fancy".  (By the way, X10 also claimed that a benefit of using AHP was that one could vastly enhance the operations of their hardware via the software flexibility.  This sounded really appealing because I'd love to be able to enhance the capabilities of my system via software, but I've never gotten to the point of being able to do anything "interesting" with the software - because I can't even get it to accomplish the basic stuff that it was supposed to help cure :().

Quote
As others have mentioned, tehre are software packages (many of them free) that have been written for the PC that will control the CM15A, and offload all that logic and processing to the PC. They are much more powerful, and can do a lot more than you can do with the CM15A alone. For your setup, it might be worth looking into it, just to see what else is out there.

Perhaps... but I have a constraint that all macro operations must run stand-alone in the CM15A during normal use, so PC-based operations can't be used.  If there are packages that will produce stand-alone code for the CM15A, then I'd be interested... but my concern with those is that going to a non-X10 software will allow X10 to disavow any support for the problems that exist around their hardware.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 24, 2011, 03:51:27 AM
I took a look at one of your description files.
A few things I noticed:
1. You are turning on cameras, and then turning them right back off (with no delay). I don't understand why.

I'm not aware of that situation; can you elaborate?

Quote
2. At one point you turn OFF a single camera, with a note that it turns off the other cameras in that group of four. I don't know if that works. I know that if you turn one ON, the other three go off, but I don't know if sending an "off" to one of them turns off all four.

It does... and I believe it is even documented somewhere in the X10 wikis.  If a camera power supply (of the type I'm using, at least) receives either an On or Off command on another unit code that is within its bank of four unit codes, it will turn itself off.  I have confirmed this via actual testing, and in fact, most of my macros would not produce usable camera operations were it not true.

In any case, this is not relevent to the issue of "confused" macro operation in real-time. ;)


Quote
3. You seem to be calling a lot of sub-macros. Why not just put the actions all in one macro? Are those sub-macros also condition based? (that's the only reason I see for sub-macros being called like that).

For details, please refer back to the post where I attached those macro descriptions, but yes, conditional execution is one of the reasons that necessitated calling sub-macros in situations where the "code" would otherwise have been "in-line".

Quote
the CM15A can only send one command at a time. So, if you want a sub-macro to run to completion before the main macro continues, then you might want to put a long enough delay into the main macro to accomplish that.

Yup, in fact, there are a couple of places where I've done that.  It's not a really viable solution in most cases, though, because it is not really possible to determine how long it will take the sub-macro to run under actual operation, so one has to "pad" the delay, making it quite a bit longer than is normally necessary or desirable - just to ensure that it is long enough under all conditions (which is another aspect that is difficult to determine).

All appearances so far lead me to believe that sub macro "calls" are actually "spawns" (where the sub-macro competes for execution time with the calling macro, rather than suspending the caller until the sub-macro finishes.  This would be "OK" if it could be confirmed that it works this way all the time, and if it was understood how the "time sharing" actually occurs... although, there are some cases where it is desirable or necessary to stop the caller while a sub-macro runs, in which case it becomes necessary to "daisy-chain" individual macros, you describe below:

Quote
Another way to do it might be to have the main macro end with the execution of the sub-macro. Then, the sub-macro can call the next macro when it finishes.

This would be "OK" -albeit a bit cumbersome- if calling operations were completely predictable;  perhaps they are, but my own observations lead me to suspect they are not.  Even so, it may be the only coding option available... and, in fact, it is the reason why you see a lot of my macros calling other macros as their last action.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 24, 2011, 03:54:12 AM
#2 Turning Off any camera in a group will not turn the rest Off.
Only an On to one in the group. Turns the rest in the group Off.

Either Off or On induces all other cameras in the bank to turn off - see my previous post for more details.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Brian H on December 24, 2011, 06:39:20 AM
If you are using your macros to turn them all off. That maybe possible.
By themselves. Turning one Off in a Group will not turn the rest Off.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 26, 2011, 11:00:13 PM
If you are using your macros to turn them all off. That maybe possible.
By themselves. Turning one Off in a Group will not turn the rest Off.


I've just re-tested with a maxicontroller and cameras do indeed all turn off if any one in the same group of four is commanded to turn off... and the other three turn off if any one is commanded to turn on.  No macros involved.  Perhaps these camera power supplies operate differently than the ones you are thinking of?
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Brian H on December 27, 2011, 06:08:27 AM
Could be as X10 is known to change things with no information passed to us or even a model number change.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 27, 2011, 10:04:56 AM
Could be as X10 is known to change things with no information passed to us or even a model number change.


That's kind of scary - especially if one has to go through a lot of "concessions" in order to make things work consistently with the current behaviors of a device.  When the device fails, its replacement may not play with these concessions. :o
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 27, 2011, 10:18:57 AM
I took a look at one of your description files.
A few things I noticed:
1. You are turning on cameras, and then turning them right back off (with no delay). I don't understand why.

I'm not aware of that situation; can you elaborate?
From your "Entry Sensor Macros":
(C3) Entry camera    ON
(B8) Entry indicator    ON
(K13) VCR #1    OFF
(K14) VCR #2    OFF
(N4) Entry Upper camera    ON
(N4) Entry Upper camera    Move Camera Entry Upper camera to Preset 2
(C3) Entry camera    OFF

There is no delay here, so the commands will fire one after another.
You might get a short delay, just from the time it takes to run the commands in between the "On" and the "Off," but it won't be very long, possibly not even long enough for the camera to warm up.
It seems that your reason for doing this is to move that camera to a certain position. I don't know what happens if it is in the middle of moving while it receives an "off" command. Does it stop moving?
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 27, 2011, 10:36:57 AM
Quote
It still seems to me like you are trying to put together a process flow that is beyond the scope of what the CM15A was designed to do.
As I've mentioned, the reason for my using the CM15A and macros in the first place was because the X10 hardware alone could not handle multiple-camera setups consisting of more than four cameras, and their recommended "solution" was to employ the AHP/SmartMacros - which they claimed would support switching of multiple banks of cameras (which it does not actually do on its own, by the way - leading to all the camera manipulations in my macros).  AHP also was supposed to enable "work-arounds" for other hardware problems or limitations, although I guess that was all left to the users to figure out on their own. :o  So, if I am going beyond the capabilities of the CM15A or AHP, it is only because X10 told me that was what I needed to do in order to get past the hardware issues, not because of any desire of my own to "make things fancy".  (By the way, X10 also claimed that a benefit of using AHP was that one could vastly enhance the operations of their hardware via the software flexibility.  This sounded really appealing because I'd love to be able to enhance the capabilities of my system via software, but I've never gotten to the point of being able to do anything "interesting" with the software - because I can't even get it to accomplish the basic stuff that it was supposed to help cure :().

I think we might have found the source of the problem. From my experience (and I've heard the same from others here), X10's sales staff aren't anywhere near as familiar with AHP as the users here seem to be. Some of them (so it seems, at least) only know as much as they can read on the website. An X10 sales person telling you the system they want to sell you will do all kinds of fancy things does NOT necessarily mean that the system is ACTUALLY capable of operating the way they describe it.
That's not to say that they *deliberately* deceived you, either. The sales person simply might not have really understood what the product can and cannot do, and told you the capabilities of the product, as they understood it to be.

Once you remove any assumptions you made based on (possibly faulty or incomplete) information given to you by the X10 sales team, you (hopefully) can begin to understand where we (the volunteer users who are trying to help you) are coming from. We are all stuck with the same hardware and software limitations, and we all suffer from the same "information blackout" when it comes to trying to get "real" answers from X10 on some things.
It is entirely possible that with enough workarounds and tweaks, the system you purchased MIGHT be capable of working exactly the way you want it to, but based on the responses here, it seems that nobody here knows how to do it.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 27, 2011, 10:45:37 AM
I took a look at one of your description files.
A few things I noticed:
1. You are turning on cameras, and then turning them right back off (with no delay). I don't understand why.

I'm not aware of that situation; can you elaborate?
From your "Entry Sensor Macros":
(C3) Entry camera    ON
(B8) Entry indicator    ON
(K13) VCR #1    OFF
(K14) VCR #2    OFF
(N4) Entry Upper camera    ON
(N4) Entry Upper camera    Move Camera Entry Upper camera to Preset 2
(C3) Entry camera    OFF

There is no delay here, so the commands will fire one after another.
You might get a short delay, just from the time it takes to run the commands in between the "On" and the "Off," but it won't be very long, possibly not even long enough for the camera to warm up.
It seems that your reason for doing this is to move that camera to a certain position. I don't know what happens if it is in the middle of moving while it receives an "off" command. Does it stop moving?

I know that's kind of hokey, but it's an attempt to work around some stuff:

First, the overall objective is to get as much "relevent" viewing time as possible, starting as soon as possible after detection occurs.  So, I turn on the "near" camera first, then work my way out to the broader view.
The Entry camera has a very limited field of view, and the motion sensors are rather indeterminate as far as where motion actually occurred, so I use the House NW camera to "sweep" the whole area, after getting a quick look at the local entry area.

As far as timing goes, it typically takes just under one second for each command in the macro to execute (see the timestamps in the log), so the Entry camera is actually on for about seven seconds, give or take, in the segment that you've listed.

Regarding the camera's movement after turning it off, I don't know whether they are "supposed" to do so, but the cameras actually do continue moving (to presets, or sweep, etc.) even after they are turned off.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 27, 2011, 10:49:40 AM
Could be as X10 is known to change things with no information passed to us or even a model number change.


That's kind of scary - especially if one has to go through a lot of "concessions" in order to make things work consistently with the current behaviors of a device.  When the device fails, its replacement may not play with these concessions. :o
Just look at what they did with the lamp module redesign a few years back. Or what they are currently doing with the "out of stock" status of the CM15A.
How hard would it have been for them to tack an "-S" onto the end of the model number for the SoftStart modules, to avoid confusion?
How hard would it have been to NOT use "CM15" as the beginning of the part number for the CM19A/TM751 kit?
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 27, 2011, 10:56:39 AM
Quote
It still seems to me like you are trying to put together a process flow that is beyond the scope of what the CM15A was designed to do.
... their hardware via the software flexibility.  This sounded really appealing because I'd love to be able to enhance the capabilities of my system via software, but I've never gotten to the point of being able to do anything "interesting" with the software - because I can't even get it to accomplish the basic stuff that it was supposed to help cure :().

I think we might have found the source of the problem. From my experience (and I've heard the same from others here), X10's sales staff aren't anywhere near as familiar with AHP as the users here seem to be.
...

Actually, it was X10's Tech Support that told me.  :(


Quote
It is entirely possible that with enough workarounds and tweaks, the system you purchased MIGHT be capable of working exactly the way you want it to, but based on the responses here, it seems that nobody here knows how to do it.

I certainly hope so... but for now, I'd just be happy to know how the macros actually interact with each other when two or more are trying to run at the same time.  It would also be helpful to understand whether "collisions" can occur due to macro operations, or if the macro system is "smart" enough to issue only one command at a time... and beyond that, how macro execution responds to collisions that may occur between macro-issued commands and asyncronous commands coming from other hardware.

I'm also rather puzzled about why it takes so long for macro actions to execute.  Is this "normal", or is there some sort of latency being introduced by some operational factor(s)?
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 27, 2011, 10:59:51 AM
Could be as X10 is known to change things with no information passed to us or even a model number change.


That's kind of scary - especially if one has to go through a lot of "concessions" in order to make things work consistently with the current behaviors of a device.  When the device fails, its replacement may not play with these concessions. :o
Just look at what they did with the lamp module redesign a few years back. Or what they are currently doing with the "out of stock" status of the CM15A.
How hard would it have been for them to tack an "-S" onto the end of the model number for the SoftStart modules, to avoid confusion?
How hard would it have been to NOT use "CM15" as the beginning of the part number for the CM19A/TM751 kit?

I'm not familiar with the CM15A situation... are they trying to "emulate" a CM15A with the CM19A/TM751 combination, perhaps?
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 27, 2011, 11:21:43 AM
I'm not familiar with the CM15A situation... are they trying to "emulate" a CM15A with the CM19A/TM751 combination, perhaps?
Sort of. They are out of stock of the CM15A (and have been for a while now).
They decided to put a CM19A and a TM751 in a box, and slap a "CM15K" label on it, selling it in place of the CM15A.
They are strongly indicating that it is an equal substitute for the CM15A, but it is severely lacking:
1. It has no internal memory, so it needs to be connected to a running PC 24/7.
2. It has no PLC transmitter, so they give you a TM751, which is "impolite," and can cause PLC collisions.
3. It has no PLC receiver. They have no solution for that one. The setup is "dumb" when it comes to PLC triggers (like from the floodlight motion sensor, or a PowerFlash module, or a plug-in controller).
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 28, 2011, 01:41:48 PM
I'm not familiar with the CM15A situation... are they trying to "emulate" a CM15A with the CM19A/TM751 combination, perhaps?
Sort of. They are out of stock of the CM15A (and have been for a while now).
They decided to put a CM19A and a TM751 in a box, and slap a "CM15K" label on it, selling it in place of the CM15A.
They are strongly indicating that it is an equal substitute for the CM15A, but it is severely lacking:
1. It has no internal memory, so it needs to be connected to a running PC 24/7.
2. It has no PLC transmitter, so they give you a TM751, which is "impolite," and can cause PLC collisions.
3. It has no PLC receiver. They have no solution for that one. The setup is "dumb" when it comes to PLC triggers (like from the floodlight motion sensor, or a PowerFlash module, or a plug-in controller).

Yikes!  That is a real bummer if the CM15A is no longer available, and there is no viable replacement:  In its current configuration, my system relies on that CM15A to do much of anything useful.  So, when the CM15A fails, the system will be dead in the water!  (I always was going to buy a backup CM15A, but economics forced other priorities... Ugh!)

I suppose that it would "resolve" the problems with the macros, though!   ::)
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 28, 2011, 02:36:12 PM
Well, X10 has been saying they are getting more of them in someday.
They just posted on FaceBook that they have SocketRockets again.
However, it looks like a new part number (LM15A-COM), and it doesn't appear to be dimmable.

Since there were rumors that they had closed a far-east manufacturing plant, perhaps the "out of stock" condition was due to the ramp-up time of their new manufacturer. If they do introduce a redesigned CM15A, I'd hope they fix some of the bugs and shortcomings of this one, and give it a new number.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Brian H on December 28, 2011, 02:44:17 PM
The old LM15A isn't dimmable either.
Maybe they used a better triac so it dent fail with a bulb blowing out.
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 28, 2011, 02:50:50 PM
Well, X10 has been saying they are getting more of them in someday.
They just posted on FaceBook that they have SocketRockets again.
However, it looks like a new part number (LM15A-COM), and it doesn't appear to be dimmable.

Uh-oh...  I have a couple of SocketRockets with CFLs in them.  I thought mine said they were non-dimmable, so I'll have to confirm that ASAP!  (Fortunately, they are only being controlled with plain On/Off commands, anyway).


Quote
... If they do introduce a redesigned CM15A, I'd hope they fix some of the bugs and shortcomings of this one, and give it a new number.

Here, here! ;)
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 28, 2011, 03:00:24 PM
The old LM15A isn't dimmable either.
Maybe they used a better triac so it dent fail with a bulb blowing out.
You're right, the old one wasn't dimmable, either. I was going on a comment that someone posted on Facebook about these not being dimmable. I never paid attention to the old one (since I don't have any).
The page shows the new model number.  I'm not sure if it is CFL/LED friendly or not.  The upper part of the page says "any standard incandescent light," while the lower part (in the picture) says "accepts ALL light bulbs."
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 28, 2011, 03:34:37 PM
...  I'm not sure if it is CFL/LED friendly or not.  The upper part of the page says "any standard incandescent light," while the lower part (in the picture) says "accepts ALL light bulbs."

Good question!  From experience, I can vouch that none of the SocketRockets that I have put CFLs in have failed or had other problems - unlike some others that have failed (repeatedly) while having ordinary incandescents in them. ???
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Noam on December 28, 2011, 08:07:51 PM
...  I'm not sure if it is CFL/LED friendly or not.  The upper part of the page says "any standard incandescent light," while the lower part (in the picture) says "accepts ALL light bulbs."
Good question!  From experience, I can vouch that none of the SocketRockets that I have put CFLs in have failed or had other problems - unlike some others that have failed (repeatedly) while having ordinary incandescents in them. ???
Well, per their Facebook rep, "The model number is still LM15A. The only change that has been made is that they respond quicker to programming. They are still not compatible with CFL bulbs."
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 29, 2011, 11:13:54 AM
...  I'm not sure if it is CFL/LED friendly or not.  The upper part of the page says "any standard incandescent light," while the lower part (in the picture) says "accepts ALL light bulbs."
Good question!  From experience, I can vouch that none of the SocketRockets that I have put CFLs in have failed or had other problems - unlike some others that have failed (repeatedly) while having ordinary incandescents in them. ???
Well, per their Facebook rep, "The model number is still LM15A. The only change that has been made is that they respond quicker to programming. They are still not compatible with CFL bulbs."

I'd say that's typically ironic:  They have been working with CFLs (which they're reportedly incompatible with), but some have failed repeatedly when used with 100W incandescent bulbs (which is what they are supposedly intended for).  Go figure... ::)
Title: Re: Questions about macros that respond to "real world" triggers
Post by: Brian H on December 29, 2011, 11:37:31 AM
The triac in a Socket Rocket even when full on. Can effect some CFLs. I have a CFL that generated lots of X10 power line noise as read by my XTBM when in a Socket Rocket.
The no CFL statement is a cover you butt thing. On the chance a certain CLF destructs. They can say "We told you not to use a Socket Rocket with a non incandescent bulb".  ;)
Title: Re: Questions about macros that respond to "real world" triggers
Post by: MD Corie on December 29, 2011, 11:56:30 AM
The triac in a Socket Rocket even when full on. Can effect some CFLs. I have a CFL that generated lots of X10 power line noise as read by my XTBM when in a Socket Rocket.
The no CFL statement is a cover you butt thing. On the chance a certain CLF destructs. They can say "We told you not to use a Socket Rocket with a non incandescent bulb".  ;)

Maybe I just got lucky with my (few) CFLs, then...  I've never detected any noise issues on the system.  (Thankfully - because there are enough other problems).

The thing that baffles me is why the SocketRockets tend to self-destruct when used with the larger incandescent bulbs.  Mine say they are rated for up to 150W bulbs, and so I'd think a 100W would be well within the rating.  And I use them either full on or full off, not dimmed.  I wonder if there is some issue with cooling;  do the SocketRockets have to be installed in open-air sockets, as opposed to semi-enclosed fixtures, in order to get adequate cooling?  On second thought, the failures occur within 30 seconds after installation, so it doesn't seem like things would heat up to a failure point that fast... ???

But we digress...