Print

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

[Charles Sullivan]

...I don't believe that AHP alters the firmware of the CM15.

Since the CM15A has 8K of EPROM inside it's RISC micro-controller, and an external 8K EEPROM, I suspect the firmware gets loaded along with the macros & timers. If so, that would make the firmware "AHP Version" specific. I don't know this for sure, but how else would they be able to add security module recognition without firmware control?

I believe the capability for decoding and encoding security RF signals has been in the firmware from the beginning, but all the CM15A does is report back the received security code to AHP.   AFAIK there's no working firmware code to execute macros based on received security codes -- that has to be done by AHP.

[ArtClark]

I must thank you for this reply.  If the firmware of the CM15 IS altered by AHP, then ANYTHING is possible.

THat actually scarres me because software updates could change the base conditions for operation of the CM15 and therefore
any bug could really cause trouble.  Nevermind the possibility of problems comming and going during a macro change.

ANY download to to CM15 of timers, macros or whatever might cause a reload could wreck up the whole works.

I note that there is no "Download Verify" function, so this becomes even more of a question.

I am going to check out the lights a little more as well.  I hadn't noticed the lights you mentioned.  (Oh Boy, More Testing...)

As to your last comment, Elses, if there were really an else clause, WOULD NOT HAVE A TRIGGER.  The TRUE trigger would
be the FAILURE of the first IF clause, NOT THE MACRO ITSELF.  This is the premise that If-Then-Else clauses rely on in ALL
programming languages that I have ever worked with.  (Basic, C, C+, C++, True Assembler, Binary Machine Language, Fortran, Focal, Cobal, And a couple most people have never heard of.)  It is, of course, true that, as you said, the people at X-10
simply used this method to represent the true underlying If-Then-Else logic but "I don't think so" best describes it for me.

That's my way of saying "I DON'T KNOW?"  I'm going to test, but I really can only make inferences from the results of
testing.  Without the Source code, Processor Type, etc. of the CM15 AND the same for AHP, Testing the final results is all
I have to go on.  I try to use complete methods for testing, but as you have noticed, I can miss a lot.

I'm redoing my whole test setup just to answer for myself what you mentioned.  I consider myself very technical, but that
doesn't always cover everything.  If I keep adding to my tests the input I get from everybody, the results can only get better.

Life is a waste if I don't learn something new everyday.

Interesting, While I was typing this, another post came in stating that the firmware was there already.  That would explain
why ALL security macros must be run from the PC.  It would imply, however, that the "Activity Monitor" is NOT a diagnostic tool
but an accessory.  If it were a true diagnostic, it would record the security modules data even though "OnAlert" was not loaded.
I can easily accept that the Activity Monitor UI only lists what AHP processes, NOT what the CM15 outputs.  There are probably
very few people that would want to see unknown hex codes displayed and then have to manually decode what they meant.
I know many people who would have trouble just reading the Monitor as it is, never mind a double listing or pure hex output.

It's getting so I spend as much time here on the forum as I do Testing.  Not very effective for what I'm supposed to be doing here.
I had better get to work testing so I can make a meaningful reply.

[Puck]

Thanks Charles, that makes sense; since the security modules require the PC to be running.

The TRUE trigger would be the FAILURE of the first IF clause, NOT THE MACRO ITSELF.

But don't forget, the primary condition for all the macros in the string is that the address gets triggered. 

Without the Source code, Processor Type, etc.

CYPRESS: CY7C63723

[ArtClark]

Unfortunately, I cannot seem to figure out how to send screen shots, so all I can do is send my text results.

I may look stupid, but I will send my raw note data.  This is what I record while testing.  It's not consice nor pretty but I hope it gets the info across and gives an idea of my testing procedures.  Remember, this is my personal note data so PLEASE ignore bad remarks, junk notes, etc.  This is just step One to check out the Macro Display Indicators in AHP.  My Version seems to do something different than Puck's so there may very well be other MAJOR differences as well.  If this type of Note data is OK for people to bother to read, I'll send on the next one.  If you want screen shots, I'm afraid you will have to instruct me how to send them.  (I have my FTP and WEB server available, if that is a viable alternative here??   Enough said - here is the data.

X-10 Testing Information - Series 5
10-29-2006 - 12:16AM
ArtClark

[/b]

Notes:    New series of test as recomended by other users.  Many missed details in first tests require second verify pass.  All items and documents to be included.  (This Doc should be saved with Glossary, if Suggested)

Test Prerequisites:

• 1.) All Macros to be run from CM15.  NO PC macros allowed during test.  (Eliminates certain conflicts.)
  
• 2.) All Macro outputs MUST BE Delayed at different intervals to prevent 2 PLC commands at the same time.
    (There are already documented problems with commands interferring and overlapping.  Seperate Prob.)
  
• 3.) All Macro Delays must be moved around between macros so that delay can be ignored. 
    (This eliminates the possibility that the amount of delay has an effect on outcome.)
  
• 4.) All Macros Must be "Captured" from screen and documented.  (User request for Replication!!)
  
• 5.) All Tests and results must be repeated a minimum of 3 times (Three) to ensure accuracy.
  
• 6.) All macro start (Trigger) commands must be sent the same way and from a direct PLC Controller.
    (This is to eliminate RF problem possibilities or changes in what I am doing.  Art Screw-up factor)
  
• 7.) All Modules and CM15 on same circuit and isolated from all other circuits.  No Interference allowed.
  
• 8.) ALL UNUSED controllers, modules, repeaters, transeivers, etc. MUST BE REMOVED. 
  
• 9.) Every test to be Documented, including typo's, failures, and undesired results.  (No Hiding Boo Boo's)
  
• 10.) Basic Notes should be files as much as possible.  (I want a dictionary when done....)
  
• 11.) All Results having to do with AHP can only be Verified with Version 3.206.  (I'm not re-loading.)
    (If other version test need to be done,  Allow other users to do it.  Wider range of testing that way.)
  

Test 1 Basics:

• Verify Display output for multiple Macro selection.  User "Puck" mentioned This. (Important!)
  

Test 1 Setup:   

• Create 2 Macros,  A6 on   and A6 Off and see if both light at same time.
  
• Create Screen Shot and Save
  
• Execute Test and Verifiy result, record.
  

Test 1 Results:

• 1.) Could NOT get both display indicators for the macros to light at the same time.  Only the Macro that was triggered flashed. Test Macro On for A6 On and Test Macro Off for A6 Off. Repeatable for 5 Cycles, but No Response from Actual module A13???
    a.) Adding delay to Macro to ensure Hand Sent PLC Command A6 On or Off is not jamming Module Code. This could happen if my finger is too slow releasing.  Human error to be removed, if possible.
    b.) Added Delay of 2 Seconds to Macro Execution.  Re-captured Screen. Re-test.
  .
• 2.) Repeated Test with Macro Delays Inserted.  Macros execute perfectly now.  Macro display flash Only indicates the Macro being executed.  Test On for A6 On,  Test Off for A6 Off.
  

Test 1 Final Conclusions:

• The Flashing indicators for Macros ONLY flash if the specific Macro is being RUN.  Even with the same House and Unit code, Off and On are still seperate.  Very Repeatable.  Second Result is more important.  Failure of Macro to properly execute without delay is MAJOR Cause for concern.  The Activity Monitor Showed the A6 command but NOT the A On or A Off signal to go with it, however the  Macro DID trigger, Flashed it's indicator and SENT A13 and A ON or A Off as desired.  The A13 - A On or A- Off DID NOT WORK, even though the Monitor Said the commands were sent.
  .
• True Results:
   - Indicators are accurate for which Macros Execute.
   - Activity Monitor IS NOT ACCURATE for What is really sent OR received.  The Monitor can Drop incomming Commands that ARE received and can display commands that ARE NOT Sent.  Use the Activity Monitor output with a Grain of Salt, as they Say.
  

Test 1 Completion:

• Note:  The rest of these test must use this as a base.  Attempt to Up-load this to the forum forothers to pick apart.  Very basic test but proof of the basic overrun trouble that is already known. Also proves the Display on this version of AHP.
  

I realize this may be useless data and is a little Off-topic, but it was the first verification test for the full "ELSE" clause test.  I had to
have a baseline reference to work from, and this was it. 

Please let me know if this is OK, what, if any, more data to send and how much to send.  I'm counting on all of you to instruct me here because I have never before shared data on a Forum before and don't Know social protocols for what is right or wrong.  I've noticed I seem to type too long and am working on that.

Thanks in advance for the input.


[TTA Edit: Re-formatted for readability.]

[ArtClark]

I have Finally finished Part two of my testing.

There are some interesting results, but I have really not gotten very far in that only No condition "Elses" have been tested.

This test does offer some interesting results for multiple macros in elses or single macros without delays.

My previous post, I think, is way too long though.  This note page is longer.  Should I post this thing or shorten to results???

I'm going to follow whatever you people think.  I really am the "newbie / stranger" here and have seen other posters jamming
up the works with uneeded or unwanted posts.

Just let me Know what to do.  Calling it a morning for now.

Thanks to all.  Though I haven't been good at the rating button, I have gleaned so much info from this forum that I consider it
to be much more valuable than the X-10 site itself.  Certainly more important.

Little request....   I'm not sure what some of the common acryonms are, Like PM.  Is there a place to pick that up or am I just
so new that my basic ignorance is showing.  Any pointers would be a BIG help.

[Charles Sullivan]

Little request....   I'm not sure what some of the common acryonms are, Like PM.  Is there a place to pick that up or am I just
so new that my basic ignorance is showing.  Any pointers would be a BIG help.

While by no means complete, here's a list of some of the common acronyms you're likely to see in this forum:
  X10    Can be ambiguous, sometimes referring to the X-10 company, other times referring to the X10 powerline transmission protocol.
  PM     Personal Message or Private Message (via the forum message system)
  AHP   ActiveHome Pro (generally referring to the software but occasionally to the CM15A interface)
  AM     The AHP Activity Monitor  (but sometimes may be used to mean Appliance Module)
  SDK   Software Development Kit (for AHP; a free download from the X-10 website)
  AH     The old ActiveHome program which uses the CM11A serial port interface or sometimes the interface itself.
  PLC   Power Line Code or Power Line Command (generally via the X10 protocol)
  LM465, AM486, WS467, etc.   Model numbers for various X-10 modules - check the X-10 website if they're not further described.
 
I'm sure others can add to this list.

[Puck]

ArtClark: You experiment is nicely documented and easy to understand what you did & the results. Please continue that method for your additional tests. 

I just did a test on one of my ON/OFF MACROS.

If I trigger the MACRO ON from an RF Remote, both the ON & OFF MACROs flash.
If I trigger the MACRO OFF from an RF Remote, neither of the MACROs flash.
If I trigger the MACRO ON from a DUMMY Module in AHP, only the ON MACRO flashes. (The way it should be)
If I trigger the MACRO OFF from a DUMMY Module in AHP, only the OFF MACRO flashes. (The way it should be)

NOTE: In all 4 cases, the correct MACRO executed correctly.

From your test, it sounds like they may have corrected this anomaly in the newer version of AHP.


Two others that I seen to add to Charles's list
OT   Off Topic
OP   Original Poster (i do believe(?))

[ArtClark]

Thanks for the Info.   Soon I hope to learn how to PM, etc.  But for now, Documenting Testing is my focus so I don't lose track
of what I'm doing.  (I get confused easily...)

Puck - This is great info for me.  I noticed you used an RF Controller.  This forced me to do a complete test just to see
how much of a difference there is between RF and Direct PLC.  (I mean a wired controller.)

Instead of Posting all my Raw data again, Here is what I found.  I think you are right about a partial bug fix, but it's a grey area
because the bug is only in the RF.  (A little in the PC interface, but I'm only mentioning that because there are MANY PC to CM15
interface irregularities, which I'll get to in future Full tests.)

IF you could verify this, fine, otherwise, I'll assume that our info fits together.

Test on ON/OFF Macro (A16).

Macro Loaded in CM15:
  Trigger Macro ON (RF) - Both Macros Flash (Just what you got)
  Trigger Macro ON (PLC) - Only ON Macro Flash (Meaning - PLC is Correct, RF isn't  - Definate AHP "Bug")
  Trigger Macro OFF (RF) - Neither Flash (Just what you got again.)
  Trigger Macro OFF (PLC) - Only OFF Macro Flash (Again - PLC OK,  RF Isn't - Possibly Same "Bug"?)

What I need to remember here is - Avoid RF for Display checks.  The Macros ALL WORKED.  (Note: I Put a Delay in front..)

An Interesting little side note:  Running the SAME MACROS from the PC instead of the CM15 only changes two things .  The
Macros run slower (Of Course) and RF ON lights both but the lights flash a second time after the delay.  This second flash
only lights the Correct Macro.  RF OFF lights none and after the delay, does light the Off Macro.  Weird, but No operational
effect, so unless testing or debugging, I think these little "Bugs" can be ignored.  IF Trying to FIX a non-working Macro via
the display, I could see major headaches for a user with no experience with the X-10.  Using the PLC Wired Controller, All
Lights and macros work correctly, in or out of the CM15. 

From Now On, I will try to Include a seperate trigger test using RF just to be sure my testing includes real-world info.
Most people, including me, use the RF much more than the Wired controllers in actual use.  Testing is one thing, using another.

Again, Thanks for the other Info, It does help me out a lot.  (I usually Learn fast, so I should get up-to-speed in a year or so. "

[Puck]

IF you could verify this...

I got the same results as you with my mini-controller. Only the correct Macro flashed for ON & OFF.
Good catch. 

[ArtClark]

OK, Now what to do?  I feel, at this point, that this little display problem is a defined and confirmed "Bug".

I guess you could call it that, though X-10 could have some internal reason for this operation.  My question is:  Should this be posted in the "Bugs" area or is just a little thing like this worth making a post for.  It might be easier to just answer it if someone else questions why such a display comes up?

I'll leave that choice to you because, obviously, you are much more in touch with the Forum than I. 

Please let me know what you do so I can remember it for future reference.  It's going to be on my Website, but a Little
thing like this will be buried in technospeak there and not useful for someone looking for quick answers.  They would have
to read the whole thing anyway, which would be pretty boring for someone looking for a display problem.....

I think a quick statement - "It works this way" is what most are looking for?  (Me being a social moron, I'm Guessing...)

[ArtClark]

Well, Here Goes.  This is the First Real "ELSE" clause test I have preformed.  I'm Only including the Basic Note Log, and trying
a couple screen shots, if I can get them to upload.  I'm putting the text in a "Quote" to take up less space.  Notes are very
wordy.  This Entire test was repeated by me just now to verify I could repeat it on this setup.  It repeated Fine.

If anyone wants ALL the Info from this test (Rest of Screen Shots, etc. you can get them off the web page where I store all
this.  I'm leaving all the extras there instead of filling up this topic with extra junk.

Here are the Test Notes.  (I thought the results interesting, but Now I must make test With Conditions.  That's Next....)

X-10 Testing Information - Series 5 - 10-29-2006 - 03:49AM

Notes:   Next series of tests as recomended by other users.
   All items and Documents to be included. 
   (This Doc should be saved with Glossary, if Suggested)

Test Prerequisites:   
1)   All Macros to be run from CM15.  NO PC macros allowed during test.  (Eliminates certain conflicts.)
2)   All Macro outputs MUST BE Delayed at different intervals to prevent 2 PLC commands at the same time.
   (There are already documented problems with commands interferring and overlapping.  Seperate Prob.)
3)   All Macro Delays must be moved around between macros so that delay can be ignored. 
   (This eliminates the possibility that the amount of delay has an effect on outcome.)
4)   All Macros Must be "Captured" from screen and documented.  (User request for Replication!!)
5)   All Tests and results must be repeated a minimum of 3 times (Three) to ensure accuracy.
6)   All macro start (Trigger) commands must be sent the same way and from a direct PLC Controller.
   (This is to eliminate RF problem possibilities or changes in what I am doing.  Art Screw-up factor)
7)   All Modules and CM15 on same circuit and isolated from all other circuits.  No Interference allowed.
   ALL UNUSED controllers, modules, repeaters, transeivers, etc. MUST BE REMOVED. 
9)   Every test to be Documented, including typo's, failures, and undesired results.  (No Hiding Boo Boo's)
10)   Basic Notes should be files as much as possible.  (I want a dictionary when done....)
11)   All Results having to do with AHP can only be Verified with Version 3.206.  (I'm not re-loading.)
   (If other version test need to be done,  Allow other users to do it.  Wider range of testing that way.)

Test 2 Basics:
   
   Verify operation of "Else" clauses without Using Conditions.  (Strange Case but Necessary first Test)

Test 2 Setup:   

   Create 1 Macro with Many Else Clauses,  A9 on , A10 On, A11 On A12 On and A13 On  (Macro Trigger = A6 On)
   Use Both Lamp and Appliance Modules to Ensure no difference (Gotta Eliminate possible Junk Test.)
   Verify Delay before Outputting Command from Macro (Proven in Test One - Needed to eliminate OVERRUN)
   Preset by Manually Turning of ALL Modules Manually (Visually Check Preset Condition)
   Create Screen Shot and Save - Be Sure Each Macro Clause recorded Seperately
   Execute Test by Manually with PLC Controller - Push A6 button then On Button
   Watch and Verifiy result, record.
   Reverse Delays to ensure no effect on else results
   Re-test, Watch and Verify Result, Record.

Test 2 Results:
   
   1)   Created Macro.  Delays are 2,4,6,8,10 Seconds for A9 - A13 Respectivly.
   2)   Quick Test - Press A6 then On - All Test Units Come On.  (Make Screen Shots Now.)
   3)   Preset and Re-run Test Multiple Time and Check ACtivity Monitor and Display.  All Good.
   4)   Reverse Delay Order and Re-test.  All Good (Do not bother with Screen Shots - Only Delay Altered)

Test 2 Final conclusions:

   All ELse Clauses Execute.  Neither Delay nor Module type has any effect here.  All defined
   Modules Turn On.  Else Clauses are No Elses, but Concurrantly running Tasks.
   Tasks are started at the SAME TIME.  If they were not, the delay would be additive.  I.E.
   the final 10 second delay IS being counted from the initial command, not the end of execution
   of the previous clause.  Once started, these seperately running macros have NO interaction.

   True Results:   With NO conditions, ALL else clauses run.  Technically, they are just Multiple
         Macros that happen to have the same trigger.  Here the word "ELSE" does not apply.
         (Note to self:  if others noticed this, why didn't other notice the rest???)
         (Re-read forum posts to see specific details when i Finish..)

Test 2 Completion: 

   Note:   This test was to verify the "ELSE" clause behaves wrong, without an else ccondition.  Of course
      if this test were repeated without delays, the outputs and the activity MOnitor display
      would be USELESS.  A Non-delayed Item would fail due to the OverRun of the Interface, not
      because of the "ELSE" clause.  It seems to be VERY possible that the OverRun is being used
      to FORCE the else to not execute.  That could cause users to get the correct else results
      even though the logic is wrong.  Now This Must Be Tested to be sure of that premise.  If
      the overrun Problem causes "ELSE" to work "correctly", then X-10 Programmers, in the Lab,
      could easily have missed this, even in beta testing.  Note:  I prefer it this way, as long
      as I am aware of it and the timing between set and check, it allows more program options.
      The problem would be to normal users who have macros that work intermittantly and cannot
      figure out why.  First imaginable case, an RF transmission, repeated.  The signal could
      last long enough to jam the first outputted signal of the macro.  Oppps, it didn't work!


Test 2a Basics:

   Verify true Operation of Empty Condition Clauses with NO DELAYS.  (Proving OverRun Effects)

Test 2a Setup:

   1)   Use exact Macros as Test 2 but With All Delays Removed.
   2)   Don't Bother with Screen Save - Just Deleting Delays
   3)   Verify Preset (ALl Modules Off) and Hit A6 On  (Macro Trigger) - Watch and Verify Results.
   4)   Double Chheck Activity Monitor to See what was recorded versus What Happened (In Case...)

Test 2a Results:
   
   1)   Modified Macros.  Delays Removed.
   2)   Quick Test - Press A6 then On - Strange but Expected result - No Modules Respond - All Display
      Activity Monitor shows the A6 Command - No A On, but Shows an A9 and A9 On - Doesn't Happen
      (Note to Self:  CM15 coded basicly, no presend check for clear line? - No Presend Pause either!)
   3)   Multiple REpeat of Test accurate.  Macro Command will not work.  (Note: Nobody has seen this??)
   
   Re-set - Add SAME delay to all macros of 2 Seconds - Should allow First Clause to execute, but then
   What will happen is Unknown.  (I think rest will fail....)

   4)   Modified Macros.  2 Second Delay Inserted BEfore Command to Module in ALL Clauses.
   5)   Unexpected Results.  The Macros ALL executed perfectly.  ALL modules turned on.
      (They turned on in the Else order as well.  The CM15 MUST wait for previous commands in
       this specific case.  I'm Wrong in my guess again.  Darn.  Multiple Tests Verify Results.)

   6)   COntinuing This Test with New Conditions.  Will Remove Delay From LAST else clause and test
      Then Will work Back, removing the next to last, etc.  Once Complete, put back to current
      configuration and start from first to last.  (Note: I'm getting too detailed, but Must Finish.)

   7)   Modified Last Macro.  Removed Delay on A13 ON Command. Test and then remove A12, etc.
      ANY Command without Delay is NOT executed.  The Activity still loses the ON command sent manually.
      The First Command in the chain without delay shows up on the activity Monitor, but isn't Sent.
      All Commands with Delay work Fine.

   9)   Modified Again.  Put 2 Sec Delay in ALL.  Removed first in chain. Test.  Remove Next, etc.
   10)   Again, Unexpected Results.  If First Clause has no delay, ALL clauses fail to execute.
      Activity monitor (as usual) Misses the On Command to trigger, but shows the A9 and ON which
      are not sent.  The rest of the commands don't show up nor work.  No Modifications to the
      Macros further down the chain have any effect.  Must now test the Middle of the Chain First.

   11)   Modified Again.  2 Sec Delay in ALL.  Removed Delay in Middle of Chain  (A11 On). Test.
   12)   VERY INTERESTING RESULTS. - Final in test.  Activity Monitor Still Misses On of A6 Trigger.
      Next on Monitor is the Non-working A11 On.  This doesn't actually work, as it shouldn't.
      Next comes a surprise.  The First two Clauses DO Execute.  A9 ON and A10 On execute as well
      as show up corectly on the monitor.  A12 and A13 have no response.

Test 2a Final Conclusions:

   1)   First and foremost, with NO delay in front of a Macro command, the operation must be
      checked VERY carefully.  If a delay is needed, or any other process will do the same, I won't
      test here.  This testing is for ELSE Clauses, not system analysis.  The end rule is, for
      unambigous operation, precede all macro commands with a delay.  I hope and assume that
      only one is needed at the start.  The CM15 seemed to stack commands from multiple macros
      without any trouble.  I may return to that test later....
   2)   If no delay is used, the ELse clauses stop at that point.  No further clauses will execute
      nor will they show up in the activity monitor.  Only the first without a delay shows in
      the activity monitor, and this command is not really sent.  (Neither One.  By This I mean:
      The Monitor Shows A9  and Then Shows A On.  Neither of these is really sent.)  Even though
      this is (In Effect) the correct operation of an else clause, it is produced by an error in
      processing as shown.  It is not really using an else.  (Bad for normal Users...)
      (Note to self:  Probable that this is how this was missed in testing.  Look how long it
       took me to find this, and I was looking for it specifically.....)
   3)   All of these test only apply to this setup.  NO verification has been done to see if RF
      transmissions, etc. will be affected the same way as far as delay are concerned.  The ONLY
      commands verified are ON and Off of Modules.  Module Type makes no difference and Command
      type SHOULD not, but This can not be confirmed with this simple test setup.
      (Note to Self:  I'm sounding like an alpha tester again.  Notes only, remember, not opinion.)

Test 2a Completion:

   Note:   This test was to prove the effects of OverRunning the interface.  There are some OverRun
      prevention buffers working, but only in the certain cases noted.  The complexity of knowing
      When they will work is simple as long as the first thing a Macro does is delay.  It seems
      that a running Macro is buffered, once it is really running.  The FIrst thing a mocro does
      Usually won't work unless it is not a command.  If it can be other than a delay is not yet
      known from these tests, but the "ELSE" clauses ARE terminated from running as soon as the
      first overrun is encountered.  A simple Macro check is now available!!!  If the activity
      monitor shows a command that did not execute, That macro and all elses further down the
      chain have terminated.  Again, weather the Failing macro continues execution has not been
      tested here.  This was ONLY for else clauses.

Questions and Comments are desperately needed.  I'm going to continue, but should I keep posting these?

I Hope the Macro Screen Shots Follow.

[Puck]

Well it definitely appears that an ELSE doesn't work as we interpret it when there are no conditions. But writing a MACRO with Non-Conditional ELSEs isn't really practical either. I'm sure a real compiler would send out a warning or syntax error.

It will be interesting to see your results with ELSE conditions. I'm not sure what your plan is, but I'd like to see a test with all ELSEs having the same trigger condition. Particularly your Test 2a Step 4) that executed all ELSEs. If they still all execute, then there is a real issue.

[Tuicemen]

OK, Now what to do?  I feel, at this point, that this little display problem is a defined and confirmed "Bug".

I guess you could call it that, though X-10 could have some internal reason for this operation.  My question is:  Should this be posted in the "Bugs" area or is just a little thing like this worth making a post for.  It might be easier to just answer it if someone else questions why such a display comes up?

Others have reported bugs that are of a lesser concern!
It is best to report any or all bugs/problems you find in the Software Problems & Bugs area!
Little bugs tend to grow into Big bugs!
It's probably best if you post to an existing thread for the version of AHP that your running !

[ArtClark]

OK.  I'll look in the area mentioned and try to stick the little display bug there.

I have completed the testing I was doing on the "ELSE" oddity, and have the results.  Just read the end of the notes to get the final results.  THere is was too much info and too many screen shots that go with this for me to gum up the works with all of it so I sending the lab notesheet only.  If more data is desired, just let me know.  (I don't imagine anyone needs all that junk...)

X-10 Testing Information - Series 5 (Continued.) - 10-30-2006 - 08:18PM

Notes:   Basic Initial Check of Else WITH Condidtions.  Test Configuration Limited.
   All Configurations should be Screen Shot for Other Users.  (ALso Save .ahx Files for Each....)
   Remember Art, This document will be exposed to external users, watch the language!!!
   Save this Doc in Site as well as test data drive.

Test Prerequisites:   (These are Copied and Continued from Previous Tests...)
1)   All Macros to be run from CM15.  NO PC macros allowed during test.  (Eliminates MANY conflicts.)
2)   All Macro outputs MUST BE Delayed at different intervals to prevent 2 PLC commands at the same time.
   (There are already documented problems with commands interferring and overlapping.  Seperate Prob.)
   (There will be a seperate Test documenting this.  For Now I'm Avoiding possible extra Problems..)
3)   All Macro Delays must be moved around between macros so that delay can be ignored. 
   (This eliminates the possibility that the amount of delay has an effect on outcome. Min Delay 2 Sec.)
4)   All Macros Must be "Captured" from screen and documented.  (User request for Replication!!)
5)   All Tests and results must be repeated a minimum of 3 times (Three) to ensure accuracy.
6)   All macro start (Trigger) commands must be sent the same way and from a direct PLC Controller.
   (This is to eliminate RF irregularities noted from other tests.  RF interaction tests will be later.)
7)   All Modules and CM15 on same circuit and isolated from all other circuits.  No Interference allowed.
   ALL UNUSED controllers, modules, repeaters, transeivers, etc. MUST BE REMOVED for My sake. 
9)   Every test to be Documented, including typo's, failures, and undesired results.  (No Hiding Boo Boo's)
10)   Basic Notes should be files as much as possible.  (I want a dictionary when done....)
11)   All Results having to do with AHP can only be Verified with Version 3.206.  (I'm not re-loading.)
   (If other version test needs to be done,  Allow other users to do it.  Wider range of testing that way.)
   (Note to Self:  If request comes up for earlier version test, consider setting up 3rd PC....)

Test 3 Basics:
   
   Verify operation of "Else" clauses WITH Conditions. 
   (This will require 4 Sets.  1) if X   2) If X or Y   3) If X and Y   4) If X or Y and Z)
   Each Set will require several sub sets for verification, however the True set should be the only
      set that alters operation.  WHAT makes the set false should not make a difference (??)
   Important:  Use of only 2 of the Three possible "OR"'s or "AND"'s shouldn't change outcome (??)
   (Verify this during testing by running Quick series filling conditions all the way!!!)

Test 3 Setup:   (Special Note:  Follow Test 2 Setup as close as possible to reduce change interactions.)

   Create 1 Macro with Many Else Clauses,  A9 on , A10 On, A11 On A12 On and A13 On  (Macro Trigger = A6 On)
   Create Test Preset Macros to Set / Clear Condidtions.  These must be MANUALLY TRIGGERED.
   (The manual trigger prerequisite I'm self-imposing is to prevent Set / Clear problems from
      changing the test outcome.  Want to test "ELSE" options only....)
   This Setup shall use "Flags" for conditions ONLY.  Module Status depends on monitored House Code.
   (There are other considerations, but for this test, Flags should be a dependable condition source.)
   (Note to Self:  Run Quick Subtest to verify other conditions being used does not affect outcome...)
   Use Both Lamp and Appliance Modules to Ensure no difference (Gotta Eliminate possible Junk Test.)
   Verify Delay before Outputting Command from Macro (Proven in Test One - Verified in Test Two.)
   Preset by Manually Turning off ALL Modules Manually (for a Visual Check of Preset Condition)
   Create Screen Shot and Save - Be Sure Each Macro Clause recorded Seperately. Preset Macro Too!!
   Execute Test by Manually trippin with PLC Controller - Push A6 button then On Button to Execute Test.
   Preset Macro for Flags Shall use House Code "A7" for simplicity.  All Manually Run anyway.
   Watch and Verify result, record.  No Special Delay changes needed.  Test Two provides guidelines.
   Re-test, Watch and Verify Result, Record.

Test 3 Results:
   
   1)   Created "ELSE" Macro.  Delays are 2,4,6,8,10 Seconds for A9 - A13 Respectivly. (Same as Test 2.)
      Conditions for Each else is Same Number Flag (Flag 9 for A9, Flag 10 for A10, etc.)
   2)   Created "Preset" Macro.  Will Need to change preset MANY Times.  First Set A9 - A13 (ALL!).
   3)   Quick Test - A7 then ON on PLC Controller.  Wait 10 Seconds to be sure.  Press A6 then ON.
      (Guess:  I Think All will Come On....)
   4)   Guess WOrked!!  - ALL Macros Executed.  This means ALL ELSE Clauses ran.  Make Screen Shots.   
   5)   Now Reset and Re-run Test.  ALL Else running Verified.  Now for Options.
   6)   Modified Preset Macro to This:  2 Sec Delay, Clear ALL Flags used, 2 Sec Delay, Set 9,10,12,13
   7)   Ran Test with Flag 11 Cleared.   VERY strange Results.  9, 10, 12, 13 Ran.  (All Elses Run.)

   ********************  Ignore 8 - 9   Made Human Error   ***   Retained for Completeness  *************
      Strange Part.  Time Delays were incorrectly executed.  Pulling Flag 10 to Double Check This.
      Ran Test with Flag 10 and 11 Cleared.  Problem Verified.  Delays ARE Affected!!!!
   *****   To Detail Failure:  Normal is a sequence with 2 Second Delay between each MOdule ON   *****
   *****   The Non-activated Modules SHOULDN'T affect other timers, but they DO.  Each is STILL 2 Sec. 
   *****   To Make Clear - The Output in Words:
   All Flags Set - Trigger Macro, 2 Sec delay, A9 ON, 2 Sec Dly, A10 ON, 2 Sec Dly, A11 On, 2 Sec Dly, Etc.
   The Actual Timmimg is 2 Sec for A9, 4 SEc for A10, 6 Sec for A11, 8 Sec for a12 and 10 Sec for A13   
   Drop A10 and A11 Flags and the Result changes to:
   Trigger Macro, 2 Sec Delay, A9 ON, 2 SEC DELAY, A12 ON, 2 SEC DELAY, A13 ON !!!!!
   There Should be an 8 Second Delay for A12.  It Changes to 4 Seconds in this process.  This IS a Bug.
   The most likely cause is internal to the CM15, the counter used for timing is not multi-tasked right?
      Take Screen Shot of Preset Timer for reference.

   9)   Ignoring this Initial Bug, the Operation is OK, but different Timings Must be Tried Next
      All Timings will be Set to 2 Seconds.  POssible that Else down chain could be Killed?
      (Guess:  I will shoot in the dark - Maybe Elses won't execute!!!
      Start with ALL Flags set to verify Correct ALL ELSE operation.  ALL Should Trip OK. (Test 2)
      During Verification, My personal error discovered.  IGNORE ABOVE STATEMENTS.
      ALL Macros WERE Set to 2 Seconds.  (I was WAY ahead of testing versus conditions.)
      If this were not a lab note sheet, I would delete all my comments above.  Please Ignore Them!!
   ******************************************************************************************************

   10)   Previous Error forces me to set the timers to 2,4,6,8 and 10 seconds and check results.
      Quick Test: All Flags On - All Modules ON at Correct Delay Interval.
   11)   Flags 10 and 11 off - A9, 12 & 13 On at correct Intervals.  (CM15 is Right on, I messed up!)
         
Test 3 Conclusions:

   1)   Errors in test procedure force me to list what is proven so far, so as not to confuse
      myself as to what I am checking.  This is embaressing.  (To Err is Human?)
   2)   With Single Flag set condition, All Else Macros do Run if Condition is Met.  Previous clauses
      DO NOT prevent the running of Else clauses.
   3)   WIth Delay, to ensure correct start of macros, commands stack up in the CM15 correctly.
   4)   Removing Macros from execution in a chain DOES NOT affect timing of other chains. (Good Operation)


Test 3a Basics:

   Verify Operation of Condition Clauses with Multiple Conditions.  (May be severe OverKill.)

Test 3a Setup:

   1)   Use exact Macros as Test 3 but With More Conditions Added.
   2)   Ensure Screen Save.  (I already messed up once, Prevents unrecorded Human Error.)
   3)   Verify Preset (ALl Modules Off), Hit A7 ON (Preset), Wait 10 Sec. and Hit A6 On  (Macro Trigger)
   4)   Double Check AM to See what was recorded versus What Happened (In Case...  Missed this in 3)

Test 3a Results:
   
   1)   Modified Macros.  Added "OR" Flag 14.  Set Flag 14 in Preset Macro.  Take Screen Shots.
      During Modification, Realized I meant "AND" not "OR" (Top row of Conditions.)
      No "OR" added yet.  Preset Clears ALL, Sets 9-14.  Run Quick Test:  (Here Goes Nothing)
      All Macros Executed.  (SHould Have - All Flags Set.)
   2)   Changing Start Delays to 2 Sec FOR ALL MACROS to check Command Stacking.  (2 Sec Req'd to Run?)
      Quick Test (Means Three Executions, by the Way...): Preset and Ran:
      All Macro Executed Great.  CM15 Stacked them and ran the next clauses at approx 1 Sec intervals.
      (This is all working too Well, I had better find something, although ELse clauses running is...)
   3)   Modified Preset - Clear Flag 14.  (This should Kill ALL Macro Outputs!!)
      Quick Test:  Excellent - NO macros fired.  "AND" clauses seem totally predictable.
   4)   Modified PReset - Set 14 again but drop 10 and 11 - Should Light 9,12,13
      Quick Test:  Excellent - 9, 12 and 13 Came On Like They Should. 10 & 11 Flag stopped Macro.
   5)   Modified Macros.  Added "OR" Flag 15.  (Really put in "OR" line this time!!!!)
      Modified Preset to Clear flag 15, not set it.  No Change should be seen.
      Quick Test:  Excellent again.  Still working as it Should.  9,12,13 function.
   6)   Modified Preset:  Leave 10 and 11 Cleared but turn on 15.  Should force ALL to execute.
      Quick Test:  Perfect.  All Condition clauses are completly predictable.  As long as one
      Takes into account they ALL fire, no matter what the previous clause did, all works right.

   7)   Weird Test for Me:  Removed Delay to see if Flag Condition tests use enough time to remove
      the need to delay macro execution of module control.  (Could cause strange effects..)
      MOdified Macros:  Removed ALL Delays.
      Quick Test: Unfortunately, (Or Fortunately, depending on what you want.) the removal of
      the Macro initial delay has the same effect as in test two.  Macros fail to execute.
      AM shows the A6 but not the A ON, Shows the first macro A9 and A ON but actually sends
      neither command.


Test 3a Final Conclusions:

   1)   ELse Clauses ALWAYS TRY to execute.  They Start in correct order, but all start immeadiately.

   2)   There Must be a delay before ANY Module control command to be sent. (From Test 2 and Verified.)
      Note:  The Internal effects are not tested.  It's possible that a Dummy module on the
      monitored house code might receive these commands.  This would need seperate testing.....

   3)   Else Conditions, as far as Flags go, all verify perfectly if in the CM15.  Macros from the
      PC have not been tested, although forum postings and undocumented tests show trouble here.

   4)   The CM15 DOES NOT OVERRUN if the Macros start correctly.  I.E.  As long as the needed delay
      is at the start of a macro, the next steps don't mess up other macro commands.  If Five
      outputs (the max tested) trip at the same time, they execute sequentially without error.
      (Note:  Extremely Long Concurrant Macros might alter the execution order.  Not tested yet...)
      (Note 2:  Not tested at all.  Macro a does CMD1 and CMD2 while Macro B does 3.  If both are
      started with the same delay, the ending order is untested.  (1,2,3 or 1,3,2 ) Logic says
      the first is correct, but the second would be more likely.  This is a future test...)

Test 3a Completion:

   Note:   This Test was to Prove that ALL else clauses execute at the same time, without regard to
      execution status of any other macro.  This is now Tested enough to say "YES" !!!

      The Only way to prevent ELSE clauses to NOT execute is with conditions (Using Flags..)
      or throwing an Overrun (Test 2).  The Overrun error terminates ALL remaining else clauses
      while the flag conditions handle just the else clause you are in. 

      I am assuming that other conditions that may be tested would operate the same as flags, but
      this is not a proven fact, seeing I only tested using flags.  I am confident enough in this
      that, other that a quick check, I will not be running a full spec test to verify.  If any
      data or errors that show up that say other conditions (Module status, etc.) act differently, I
      will setup and execute a complete test cycle.

      (Note to Self:  If testing Module Status, recheck Delay requirement re: Execution time in CM15)

Hope this answers the Else clause question this all started with.  I'm sure I got carried away, but I'm really an Old-School person when it comes to testing and try to not take anything for granted.  I'll admit, I really enjoy this stuff too much for my own good.  (And probably everyone elses too.)  Thanks

[Puck]

ArtClark: Good work on the ELSE's. Thanks. There definitely appears to be a problem there that needs to be addressed.

I will do a few tests on my AHP Version as well. (Been too focused to getting some Halloween MACROS ready.)
We'll take Tuicemen's advice and move a list of the ELSE Problems over to the Software Problems & Bugs area. That way others can see what the problems are more easily and can look at this thread if they want the background.