Print

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

[MD Corie]

..... 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....

[Noam]

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.

[MD Corie]

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.

[Noam]

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.

[HA Dave]

......... 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.

[Noam]

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.

[HA Dave]

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.

[MD Corie]

...
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.

[MD Corie]

...

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! 

[MD Corie]

... 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...

[MD Corie]

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).

[Noam]

... 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.

[MD Corie]

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".   

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).

[Noam]

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".   

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.

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?

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.

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.

[MD Corie]

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.