I realize that this is going to cause a stir, but I have to disagree with the "ELSE" definition. As Puck stated, if there is a delay at the start of a macro, all clauses try to execute. (Most likely because the "Stop" macro processing occurs after the delay, but it's too late to catch the already started clauses.) Seeing that I run many wacky programs and have now had to make major changes because I DO power down the server PC that runs the AHP once in a while, I have seen that a delay IS NOT always required to fire multiple else clauses. The firing even seems to be intermittant. I am going to run a few test cases, but the amount of macros and timers loaded seems to have an effect on how intermittant this really is. I never saw it occur until I hit around 50% of the CM15 memory in use. I have this very bad habit of always pushing my programs over the edge. (This comes from writting communication code for the production environment. If the code can wreck up, thereby shoving a tool on a CNC into a part turning at high speed, the amount of damage to the machine is unacceptable, never mind the possible death.) My whole theory on coding has therefore become, Push it till it breaks so I can see how it breaks. No programming or operating system is perfect. NONE. As a simple example, writting in machine code for an original 8080, running it out of ROM, and fully verifying the code multiple times, certain problems came up that could not be simply tested. (Pratt & Whitney spent well over 6 figures and many hours with logic analyzers monitoring every line to finally find the problem.) This was a simpler and more stable system than the CM15.
All I am trying to say is, Never believe the "Book". Just because something works for someone else doesn't mean that it will work for you unless you can duplicate the entire system. Of course, the normal problems I see around here are usually not the type that need detailed checkouts at that level, but there have been a few. Most everyone that I see answering peoples questions have a much better handle on the real-world problems that occur with X-10 than I ever will, but my way of solving the "Else" clause for now really comes down to Pucks observation about the delay. IF you use a delay as the first "Command" and assume that all clauses will then execute, you just modify the condition clauses to handle that. This also allows multiple triggers from a single command. (I use this a lot. Can simplify complex operations greatly.) As I mentioned though, this is what I am adding in now. I have quite a few macros without the delay so that they would not fire all clauses, and suddenly, while adding other code, they started to "occasionally" fire all of them anyway. Why? I don't know. Unfortunately, with the size of the total load, I cannot even just send the program from AHP after a single change without verifying all the "ON / OFF" values before sending because of AHP's little bug of displaying one thing in the graphics area and something different in the text area. (The text is what gets sent.)
If I ever get this sorted out to my satisfaction, I'll post the basic results here. Might make an interesting read, at least.
So to you Walt, if you put a delay as the First thing the macro will do (Before turning on the lights.) the second "Else" WILL execute, which is what you are looking for, I Think. To all, Does this sound right?
