Please login or register.

Login with username, password and session length
Advanced search  

News:

The X10Hub (PiX10Hub) is here! Created by the Community, for the Community.:)% #:)

Pages: [1] 2

Author Topic: ELSE confusion and Flag Trouble  (Read 58647 times)

ArtClark

  • Guest
ELSE confusion and Flag Trouble
« on: October 26, 2006, 11:32:00 PM »

I'm hoping that this is not old information but I have found that the description of "ELSE" is totally wrong.

Using the word "ELSE" is VERY misleading because they are NOT really a logical else.  All "ELSE" clauses trigger
weather the previous clause triggers or not.  As long as conditions are used to determine if they should run, then
the normal user should not have a problem, but in complex macros, this is IMPORTANT.  I am assuming that the clauses are started in the correct order and are not random, but they all do start at the same (to us humans) time.  Without getting into technical Multi-tasking definations (1 CPU in CM15, etc.) if you alter the conditions in the first clause, if your running internal to the CM15, I'm not sure of the response versus the result.  I.E.  If flag 1 is set after a 1 second delay in the first clause, but the second clause checks for that flag immeadiately,  The second clause WILL NOT see the flag, because it hasn't been set yet.  I'm going to start timing tests to see how far this goes, but I'm sure that instruction times to >8 clauses will be of no interest to anyone but me.

Beware of flags from the PC.  I haven't finished this part of my testing yet, but flags have a problem when the macro is executing from the PC.  I will test this fully and if anyone is interested enought to post a reply to this, I will post the results.  I already have tested enough to know that one of the following is true.
1) Flags can not be set from the PC.
or
2) Flags can not be read from the PC.
or
3) Flags are not "Real Time" in the PC (This may be the most probable...)
or
4) Flags cannot be accessed at all from macros running in the PC. (I hope not, but I'll find out.)

Please Note:  This flag trouble is serious for users with OnAlert plugin.  Security remotes ONLY run in the PC.  Flag problems mean hat until the "Problem" is defined, DON'T use a flag in the PC macro.  Trigger an internal macro from the PC macro until you know what is happening.

If you want more info, let me know.   I'm going back to testing right now.
Logged

ArtClark

  • Guest
Re: ELSE confusion and Flag Trouble
« Reply #1 on: October 27, 2006, 02:27:33 AM »

Hate to add to a topic when it hasn't been requested, but I have to rant on for a few words.  I have done some basic flag status testing between the PC and the CM15.  This is the basic initial data and I have more testing to do to really pin it down.  Even if it means nothing, little techie problems like this are what I live for, and it might help others with strange problems.

The PC DOES have proper access to the flags.  It can both read the flags and set them correctly, however the true difficulity is a little more obscure than just flag access.

In the CM15, a Flag set may be checked right after it is set by an "Else" macro (Assuming you don't program in a delay, but lets not complicate things.) This just means that if Macro A1 sets flag A1 and an ELSE clause in Macro A1 checks for it, the correct result will be there.  This is NOT TRUE on a Macro running from the PC.

A PC macro A1 setting flag A1 is fine, but the "Else" clause in macro A1 ON THE PC will not "See" this flag is set.  As soon as the PC runs Any other macro, the flag has the correct value, but it is not instant.  I have not yet nailed down the delay time in a single macro yet, if there is one.  I do know that if the above macro A1 "Called" A2. A2 would see the correct flag.  I will need to create an A1 macro with else clauses with increasing delays just to see, but the Check flag status can't really be delayed without changing macros, which updates the flag status..........

The only trouble this causes is, Don't use Flags for a condition in the PC if they are to be set by a previous clause in a large single macro.  Either call a new macro or check a phantom module status instead. (Rememcer to stick with the monitored house code...)

I hope this little abnormality hasn't caught anyone else.  It hit me with a security motion detector that I set a flag for and used an else clause to see if it had already been set.  With the else timing, this cannot work for the flag can't be detected yet.  (I'm stating the obvious here, I know, but I wasted so much time I had to vent somewhere.  The moral to this is, alway recheck for the little errors you can make.)

Thanks for letting me rant on.  I'm going on to my next project to see what other trouble I can get into ;)..
Logged

KDR

  • Hero Member
  • *****
  • Helpful Post Rating: 53
  • Posts: 758
    • Home Automation Chat
Re: ELSE confusion and Flag Trouble
« Reply #2 on: October 27, 2006, 06:23:27 AM »

ArtClark...  I'm not sure if the problem existed before OnAlert plug-in was added or not but with OnAlert if you have a macro that has the Use Security button checked or MyHouse using email, both these conditions and some others only run from the PC and you have no option to check Store in Interface. When running from PC you can not use conditionals and get them to work (a few do). Testing for flag status or module status won't work.

You can get around this by creating a dummy module in the first macro that is being run from the PC. Set the dummy module to turn on and its address to the address of a second macro. The second macro can test all the conditions, flags, module status and it would be set to Store to Interface.

The first macro is a simple turn on dummy module that fires off the second macro that handles the conditionals.  There is some other postings about this I think in regards to using email from MyHouse. You can do a search and find it there i do believe. I have to use 3 macros to send an email from a security device if certain conditions are met. First macro triggers from security module, it fires off the second macro that tests conditions and when met it fires off 3rd macro that does email.
Logged
Note: "Guests" may read the X10 forum , but you must register to post!

When I'm online you can find me in the Home Automation Chat Room!

ArtClark

  • Guest
Re: ELSE confusion and Flag Trouble
« Reply #3 on: October 28, 2006, 11:37:18 PM »

OK.  I understand what you said.  I am only using Basic macros that Can be stored in either the PC or the Interface.

I have so much more testing to do on the "Else" clause that I will have to wait till I finish that before going on to
this flag situation.  My main concern here was exactly WHEN during the execution of a macro that the flag could be detected.

This may sound stupid but, if you have several macros running at once and some are in the PC and others are in the
interface then When they can detect the flag changes could become confusing without an exact method of knowing
when the change is detected.   As you say, as long as you call a new macro when you are in doubt, it does work OK.

Once I finish my "Else" tests, I'll return to this one.
Logged

ArtClark

  • Guest
Re: ELSE confusion and Flag Trouble
« Reply #4 on: November 01, 2006, 08:17:23 PM »

Info on Flag Access / Else confusion.  Initial testing of this situation has become massive.  TOO many variables.

Anyone with testing ideas for a simple test method that I can work form would be appreciated.

Let me throw my situation out there and see what you all think.

To Start.  The CM15 IS multi-tasking, being able to run multiple macros.  This is real time.
   The PC is emulating the CM15 real time sytem in a Non-real time enviroment (Windows).
   Task swaping my be interupted by:  1) PLC Cmd Recv.  2) Any PC - CM15 Communications.  3) Any RF Signal.
   
For ALL normal macro programming, users can ignore the whole concept of task swapping in the CM15 and PC enviroment, but
as I read the forum posts.  (I've only spent around 8 Hours) I see a lot of problems or "Bugs" popping up that are directly
related to 2 CPU interacting with each other on different task scheduling.  I want to try and produce a data set that will accurately
predict ALL operations without writting a Book of testing results.  (Worked on just else clause, took me over 20 Hours!!)

I'm Sure I'm missing a simpler method, but after my last test, I mest start from scratch.  I purposely deleted the Macros, test sheet
and all related data from this test to force myself to re-think but the last result I noticed is whats got me going.

A flag access test with Large Multiple-Else clause macros running in both the PC and the CM15.  How busy the PC was had major
effects on the results.  Implication:  Task Swap timing is left to the user to handle if pushing the envelope that far.

Does anyone else think this is worth digging into to define, or is this to for over the edge for any normal user to bother with.
As long as macros are called serially and/or new macros are called prior to checking status, all works well.

What do you think.
Logged

Walt2

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 28
  • Posts: 781
Re: ELSE confusion and Flag Trouble
« Reply #5 on: December 30, 2006, 12:22:28 PM »

Using the word "ELSE" is VERY misleading because they are NOT really a logical else.  All "ELSE" clauses trigger
weather the previous clause triggers or not. 

So, the "ELSE" macro is really totally independent, logically, of the original macro, and the "ELSE" macro executes even if the original macro's conditionals evaluate out to be 'true'?

What, then, is the difference between have a "ELSE" macro, say for M1, and have a second, totally separate M1 macro?  In other words, is there a difference between having an M1 macro with an "ELSE" macro, and simply having two M1 macros?
Logged
* Sears Home Control System, Radio Shack Plug 'n Power, NuTone, Stanley LightMaker, BSR, HomeLink.
* Tecmar Device Master, CP290 (LightHouse), CM11A (AH), CM14A (AH2), CM15A (AHPro).

Puck

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 171
  • Posts: 1799
Re: ELSE confusion and Flag Trouble
« Reply #6 on: December 30, 2006, 12:30:05 PM »

In other words, is there a difference between having an M1 macro with an "ELSE" macro, and simply having two M1 macros?

No. If you create 2 separate M1 macros, AHP will automatically link (else) them together (if they are both triggered by ON or both by OFF).

Elses do work as expected as long as none start with a delay command.
Logged

steven r

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 74
  • Posts: 2189
  • Halloween with X10
Re: ELSE confusion and Flag Trouble
« Reply #7 on: December 30, 2006, 01:28:01 PM »

In other words, is there a difference between having an M1 macro with an "ELSE" macro, and simply having two M1 macros?
No. If you create 2 separate M1 macros, AHP will automatically link (else) them together (if they are both triggered by ON or both by OFF)....
If so, does the first one created become the primary condition and the second one the else?
Logged
BVC let's me tell my camera where to go!
:) Murphy is my beta testing pal. He helps me find problems whether I like it or not. :)

steven r

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 74
  • Posts: 2189
  • Halloween with X10
Re: ELSE confusion and Flag Trouble
« Reply #8 on: December 30, 2006, 01:32:33 PM »

...I'm sure that instruction times to >8 clauses will be of no interest to anyone but me....
Not so. While I personally have never found a need for any macro with more than 1 or possibly 2 elses, I'm always interested in hearing about obscure applications that do.
Logged
BVC let's me tell my camera where to go!
:) Murphy is my beta testing pal. He helps me find problems whether I like it or not. :)

Puck

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 171
  • Posts: 1799
Re: ELSE confusion and Flag Trouble
« Reply #9 on: December 30, 2006, 01:43:53 PM »

If so, does the first one created become the primary condition and the second one the else?

It does seem to work out that way... at least with the tests I've done.

Quote
While I personally have never found a need for any macro with more than 1 or possibly 2 elses, I'm always interested in hearing about obscure applications that do.

I have many Macro / Else combinations that are 6 levels deep. Each one is based on a combination of Flags & Times. I use different Flags for indicating home mode, security mode (and if and what camera is on), and (in some cases) if another light in the same area is already on.
Logged

Tuicemen

  • Administrator
  • Hero Member
  • ****
  • Helpful Post Rating: 265
  • Posts: 9443
  • I don't work for X10, I use it successfuly!
    • Tuicemen Software
Re: ELSE confusion and Flag Trouble
« Reply #10 on: December 30, 2006, 06:44:32 PM »

Else Macros get very trick especially when AHP auto ads one as an else.
I've been running some else macros since Smartmacros was in beta testing and with no problems until AHP auto adds one! ::) ;) :D
Heres how the work!
AHP looks at the first macro if it can trigger it(all conditions met) it does so and stops the other else macros are not triggered!
If the conditions aren't met it goes to the next else and so on until it finds one that all conditions are met and triggers that one!
Hence the last else in the series doesn't need have any conditions!
You can't have A1 set a flag and expect the next else to see it set at the same time it will only see it set on receiving the next trigger!
The more Else's you add the more complex things get
eg: trigger b2
if is before 4:00pm
turn on c2
set flag2

else
if flag 2 set
if time is exactly 6:00 pm
turn on c4
turn of c2

else
if flag 2 set
if a week day
turn on c6
turn off c2

else
if flag 2 set
turn of c2
clear flag

else
turn on c7

Moving the order of these will produce different results even causing some to never trigger (if turn c7 was placed any where else in the series the other Elses following it would never trigger)  ;) :D ;D
Now if you created another macro say:
trigger B2
if  week end
turn on G5

It would never fire ::) because AHP wouldn't place it in the correct position in the string
you would have to place it to before the "turn c7 on" macro.and some where after the "if time is exactly 6:00 pm" macro
;) :D ;D
For anyone that has done any programing Elses are a piece of cake!
For the rest of us they can be a night mare trying to sort things out!
Logged
Please Read Topic:
General Forum Etiquette
Before you post!

Find extra info @ My forum

Walt2

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 28
  • Posts: 781
Re: ELSE confusion and Flag Trouble
« Reply #11 on: December 31, 2006, 08:01:55 AM »

AHP looks at the first macro if it can trigger it(all conditions met) it does so and stops the other else macros are not triggered!
If the conditions aren't met it goes to the next else and so on until it finds one that all conditions are met and triggers that one!

Is an "ELSE" macro a true else or not?  I seem to be reading here, both answers.    :-\

What I want to do...

If M1 On AND Nighttime Then A1 On /* If motion and it is dark, turn on outside lights */

If M1 On Then A2 On /* If motion always ring the announce chime */

AHPro will "link" the second macro to the first, as the first's "ELSE" no?   And my announce chime will
only ring when it is not Nighttime?

I am so confused....   ???
Logged
* Sears Home Control System, Radio Shack Plug 'n Power, NuTone, Stanley LightMaker, BSR, HomeLink.
* Tecmar Device Master, CP290 (LightHouse), CM11A (AH), CM14A (AH2), CM15A (AHPro).

ArtClark

  • Guest
Re: ELSE confusion and Flag Trouble
« Reply #12 on: December 31, 2006, 08:32:15 AM »

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?
Logged

Tuicemen

  • Administrator
  • Hero Member
  • ****
  • Helpful Post Rating: 265
  • Posts: 9443
  • I don't work for X10, I use it successfuly!
    • Tuicemen Software
Re: ELSE confusion and Flag Trouble
« Reply #13 on: December 31, 2006, 10:35:37 AM »

Is an "ELSE" macro a true else or not?  I seem to be reading here, both answers.    :-
What I want to do...
If M1 On AND Nighttime Then A1 On /* If motion and it is dark, turn on outside lights */

If M1 On Then A2 On /* If motion always ring the announce chime */

AHPro will "link" the second macro to the first, as the first's "ELSE" no?   And my announce chime will
only ring when it is not Nighttime?

I am so confused....   ???
The Else is truly an else "only fires if the conditions to the macro in front of it aren't met and the conditions for it are met!"
Depending on which macro is placed first if the ring chime macro is the first it will always fire you'll always hear the chime.
If it is the second macro or the else it will only fire if the first macro doen't!
Why? Because it has no conditions (I asume the if motion is the trigger M1)
Placement Is key when it comes to Elses

It is best not to let AHP place the macros as conditions  as you can never be guaranteed they will be place.
To add a macro as an else  manually edit your first macro and click add macro then build the second one there if you want a third else do it the same way. Click and else to the second macro.

 What Art is tring to do is find ways to confuse the "Else" or break it!
Quote
Push it till it breaks so I can see how it breaks.
Logged
Please Read Topic:
General Forum Etiquette
Before you post!

Find extra info @ My forum

ArtClark

  • Guest
Re: ELSE confusion and Flag Trouble
« Reply #14 on: December 31, 2006, 08:44:54 PM »

Tuiceman, I am in no way attempting to "Break" the else clause.  In fact, I downloaded to this site a very large description of testing that I did to prove that the "ELSE" clause is not an else.  Puck noted that the "BUG" only appears when there is a delay at the front of the Else commands, but I have not truly verified that.  (My personal requirements for a programming / hardware proof are a little "over the top" for further listing here.)

The "Proven Fact" that an "ELSE" is not a true "Else" if there is a delay as the first command is NOT in question.  This is actually a programing benefit!!!!  I'm VERY surprised that more people don't use it.  This allows Multiple Macros to be executed (as Walt is trying to do...) AND have conditions on them as well!!!   The Delay is REQUIRED anyway due to the lack of the CM15 having a wait capability.  (If you run a multiple macro, with conditions, with the PLC commands all trying to be sent at the same time, you can drop commands as has been reported many times in this forum.  This little glitch is OT for this thread.)

I'm sorry if I confused the problem.  I just want to be sure that people understand that an "ELSE" clause is not a true programming, logical else.  I have been writting code for over 30 years in many languages and believe me, a "True" else is from the "IF - Then - Else" mathematical reasoning (Originally established in boolean algebra, hopefully thats lost to history....).   A True Else has NO Options.  It Can ONLY execute if the "THEN" clause doesn't execute.  The mere fact that a Macro can have an "ELSE" without conditions on the first (Then) clause eliminates (to a programmer) the idea of it being an else.  It is a convenient name to use and most people understand it so I can't fault X-10 in any way for using the term, BUT, an "ELSE" in X-10 is not a programming else.  It does work that way in it's simple form, but it's really a standard macro triggered by the same command as another macro.  Order matters in the execution order of the macros only if using them as a basic else.  You can (I do) have the order altered via differing amounts of delay to force earlier macros to execute later, etc.  I use conditional triggering with flags that run and re-run a large macro "Else" chain that enables me to alter the chain "on-the-fly". 

Again, Sorry for the confusion.  I'll stop typing and leave the subject alone now that I've probably caused more confusion than the subject was deserving of.  If you use Macros normally, without delays, and are careful, Else macros DO execute as if they were an "Else", in Exactly the order written.  If you get into complex programming or Macro timing issues.........

Logged
Pages: [1] 2
 

X10.com | About X10 | X10 Security Systems | Cameras| Package Deals
© Copyright 2014-2016 X10.com All rights reserved.