Print

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

[MD Corie]

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

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

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.

[Noam]

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

[Noam]

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.

[Brian H]

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

[MD Corie]

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

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

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.

[MD Corie]

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?

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.

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

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:

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.

[MD Corie]

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

[Brian H]

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.

[MD Corie]

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?

[Brian H]

Could be as X10 is known to change things with no information passed to us or even a model number change.

[MD Corie]

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.

[Noam]

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?

[Noam]

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

[MD Corie]

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.

[Noam]

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.

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?