Please login or register.

Login with username, password and session length
Advanced search  

News:

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

Pages: [1] 2

Author Topic: Macros slow to execute...any ideas? (I have my own workaround for now)  (Read 53593 times)

aslamma

  • Sr. Member
  • ****
  • Helpful Post Rating: 11
  • Posts: 76

If I add a single "ON" command to a macro, it will execute quickly.  But the more modules that I add to turn on, the slower it gets.  As a test, I added all 8 modules to a macro and it was PAINFULLY slow.  Is this consistent with other's observations?  The CM15A seems to wait and then send the signal to all of them at once.

Alternatively, I added a delay in between each "ON" command of 1 second.  This forced the CM15A to just send out that command and will turn on the first light immediately, without such a long hesitation.  I prefer this because then I know if the the CM15A has received the signal rather than waiting for 5+ seconds to see if it has actually received it.

Is this the best that can be done?  It seems like there should be an option to either simultaneously turn on the lights (this is what is currently does and its reallll slow), or to consecutively turn on lights one by one.  This would be better than my workaround since I have to add a 1 second delay..it would be better to have a .1 second delay or something like that.  Anyway, just seems like the capability is there to make this work a lot quicker (not necessarily a limition of the X-10 protocol), but is rather a software issue.
« Last Edit: August 12, 2008, 01:56:09 AM by -Bill- (of wgjohns.com) »
Logged

Boiler

  • Guest
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #1 on: August 08, 2008, 12:55:16 PM »

If I add a single "ON" command to a macro, it will execute quickly.  But the more modules that I add to turn on, the slower it gets.  As a test, I added all 8 modules to a macro and it was PAINFULLY slow.  Is this consistent with other's observations?  The CM15A seems to wait and then send the signal to all of them at once.

Alternatively, I added a delay in between each "ON" command of 1 second.  This forced the CM15A to just send out that command and will turn on the first light immediately, without such a long hesitation.  I prefer this because then I know if the the CM15A has received the signal rather than waiting for 5+ seconds to see if it has actually received it.

Is this the best that can be done?  It seems like there should be an option to either simultaneously turn on the lights (this is what is currently does and its reallll slow), or to consecutively turn on lights one by one.  This would be better than my workaround since I have to add a 1 second delay..it would be better to have a .1 second delay or something like that.  Anyway, just seems like the capability is there to make this work a lot quicker (not necessarily a limition of the X-10 protocol), but is rather a software issue.

aslamma,

The words "painfully slow" struck a bell.  Have a look at your activity monitor - if you see AHP sending out "bright 100%" commands, this is the cause of the slow execution.  You can change this by going to "Tools/Preferences/Macro Options" and clicking the box for "Issue ON in place of bright 100%".  Make SURE you download to the interface after checking this box.

You are correct that inserting any delay (even 0) between modules will force AHP to send commands to one module at a time.  Here's some examples of execution -

Macro 1 (no delay, AHP set to send Bright 100%)
L1 on
L2 on
L3 on
L4 on
L5 on
L6 on
L7 on
L8 on


Activity Monitory for Macro 1

20    08/08/2008 12:23:57 pm    Receive RF    L9 On
21    08/08/2008 12:24:04 pm    Macro    L5 (New Module)
22    08/08/2008 12:24:04 pm    Macro    L3 (New Module)
23    08/08/2008 12:24:04 pm    Macro    L7 (New Module)
24    08/08/2008 12:24:04 pm    Macro    L1 (New Module)
25    08/08/2008 12:24:04 pm    Macro    L6 (New Module)
26    08/08/2008 12:24:04 pm    Macro    L4 (New Module)
27    08/08/2008 12:24:04 pm    Macro    L8 (New Module)
28    08/08/2008 12:24:04 pm    Macro    L2 (New Module)
29    08/08/2008 12:24:04 pm    Macro    L Bright 100(New Module, New Module, New Module, New Module, New Module, New Module, New Module, New Module)


Notice the L Bright 100 at the end of the above - this actually takes ~ 12 seconds to transmit.

Macro 2 (with delays, AHP set to send Bright 100%)
L1 on
wait 0
L2 on
wait 0
L3 on
wait 0
L4 on
wait 0
L5 on
wait 0
L6 on
wait 0
L7 on
wait 0
L8 on
wait 0


Activity Monitor for Macro 2

50    08/08/2008 12:29:17 pm    Receive RF    L9 On
51    08/08/2008 12:29:21 pm    Macro    L1 (New Module)
52    08/08/2008 12:29:21 pm    Macro    L Bright 100(New Module)
53    08/08/2008 12:29:26 pm    Macro    L2 (New Module)
54    08/08/2008 12:29:26 pm    Macro    L Bright 100(New Module)
55    08/08/2008 12:29:30 pm    Macro    L3 (New Module)
56    08/08/2008 12:29:30 pm    Macro    L Bright 100(New Module)
57    08/08/2008 12:29:34 pm    Macro    L4 (New Module)
58    08/08/2008 12:29:34 pm    Macro    L Bright 100(New Module)
59    08/08/2008 12:29:38 pm    Macro    L5 (New Module)
60    08/08/2008 12:29:38 pm    Macro    L Bright 100(New Module)
61    08/08/2008 12:29:42 pm    Macro    L6 (New Module)
62    08/08/2008 12:29:42 pm    Macro    L Bright 100(New Module)
63    08/08/2008 12:29:46 pm    Macro    L7 (New Module)
64    08/08/2008 12:29:46 pm    Macro    L Bright 100(New Module)
65    08/08/2008 12:29:50 pm    Macro    L8 (New Module)
66    08/08/2008 12:29:50 pm    Macro    L Bright 100(New Module)


The delays force AHP to address each unit individually.  The Bright 100 commands each take ~ 5 seconds to transmit.  Total time ~40 seconds.

Activity monitor for Macro 2 - AHP preferences set to send ON in place of Bright 100%

84    08/08/2008 12:32:48 pm    Receive RF    L9 On
85    08/08/2008 12:32:49 pm    Macro    L1 (New Module)
86    08/08/2008 12:32:49 pm    Macro    L On (New Module)
87    08/08/2008 12:32:50 pm    Macro    L2 (New Module)
88    08/08/2008 12:32:50 pm    Macro    L On (New Module)
89    08/08/2008 12:32:51 pm    Macro    L3 (New Module)
90    08/08/2008 12:32:51 pm    Macro    L On (New Module)
91    08/08/2008 12:32:52 pm    Macro    L4 (New Module)
92    08/08/2008 12:32:52 pm    Macro    L On (New Module)
93    08/08/2008 12:32:52 pm    Macro    L5 (New Module)
94    08/08/2008 12:32:52 pm    Macro    L On (New Module)
95    08/08/2008 12:32:53 pm    Macro    L6 (New Module)
96    08/08/2008 12:32:53 pm    Macro    L On (New Module)
97    08/08/2008 12:32:54 pm    Macro    L7 (New Module)
98    08/08/2008 12:32:54 pm    Macro    L On (New Module)
99    08/08/2008 12:32:55 pm    Macro    L8 (New Module)
100    08/08/2008 12:32:55 pm    Macro    L On (New Module)



Notice that simple ON commands are now being sent.  Total transmission time ~6 seconds.
« Last Edit: August 12, 2008, 01:57:17 AM by -Bill- (of wgjohns.com) »
Logged

HA Dave

  • Hero Member
  • *****
  • Helpful Post Rating: 174
  • Posts: 7043
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #2 on: August 08, 2008, 01:32:15 PM »


..........  Here's some examples of execution -


Boiler that is the finest example of how the delays work I have ever seen. THANK YOU!
« Last Edit: August 12, 2008, 01:57:58 AM by -Bill- (of wgjohns.com) »
Logged
Home Automation is an always changing technology

aslamma

  • Sr. Member
  • ****
  • Helpful Post Rating: 11
  • Posts: 76
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #3 on: August 08, 2008, 02:32:55 PM »

Boiler, 

  Yes, I definately have the "Issue ON in place of bright 100%".  In fact, nothing worked until I did that (2 hrs of messing around with it to find that out).  I did not realize you could have a 0 second delay...so that will help for the lights that are turned on later in the macro exectution   :D.  It looks like the quickest way is to send the first ON command followed by zero second delays.  The key is to have the first module be one that lets you know if the command has been received (i.e. the light closest to the switch).  This seems to be a pretty decent solution.
« Last Edit: August 12, 2008, 01:58:43 AM by -Bill- (of wgjohns.com) »
Logged

Boiler

  • Guest
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #4 on: August 08, 2008, 04:13:54 PM »

Boiler, 

  Yes, I definately have the "Issue ON in place of bright 100%".  In fact, nothing worked until I did that (2 hrs of messing around with it to find that out).  I did not realize you could have a 0 second delay...so that will help for the lights that are turned on later in the macro exectution   :D.  It looks like the quickest way is to send the first ON command followed by zero second delays.  The key is to have the first module be one that lets you know if the command has been received (i.e. the light closest to the switch).  This seems to be a pretty decent solution.

aslamma,

Sounds as if you've already put your time into this project - you've built up quite a bit of "sweat equity". 

One additional option - This appears to be a rather extensive macro (8 lights).  Would it be possible to put these 8 units on their own dedicated housecode?  If so you could then issue a Housecode xx All on/all off commands.  This should knock execution time down to around a second.

Happy experimenting,
Boiler
« Last Edit: August 12, 2008, 01:59:42 AM by -Bill- (of wgjohns.com) »
Logged

aslamma

  • Sr. Member
  • ****
  • Helpful Post Rating: 11
  • Posts: 76
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #5 on: August 08, 2008, 06:10:10 PM »

Boiler,
  Actually, the 8 unit setup was only for test purposes (I have a total of 8 light switches).  I wanted to test my theory about how it was executing the macros.  After I realized what was going on, that was my thought as well...to put groups into their own house code and use the house code on/off command.  I think that is probably where I am headed.

So what exactly is happening during the delay?  That is the odd part.  I mean nothing happens then all lights turn on.  It is almost like the CM15A is "processing" how it wants to send out a signal such that they all turn simultaneously.

Funny thing about X-10, it does work if you know all of these little tricks.  Man, someone should write a book about how to address these issues.
« Last Edit: August 12, 2008, 02:00:11 AM by -Bill- (of wgjohns.com) »
Logged

Boiler

  • Guest
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #6 on: August 08, 2008, 07:27:36 PM »

So what exactly is happening during the delay?  That is the odd part.  I mean nothing happens then all lights turn on.  It is almost like the CM15A is "processing" how it wants to send out a signal such that they all turn simultaneously.

Funny thing about X-10, it does work if you know all of these little tricks.  Man, someone should write a book about how to address these issues.

Aslamma,

I'm not altogether sure what delay you are referring to.  In my example above, I see ~ 1 sec delay from RF reception to unit command.  If you are seeing something different, please post your macro and your activity monitor results.

Boiler
« Last Edit: August 12, 2008, 02:00:44 AM by -Bill- (of wgjohns.com) »
Logged

aslamma

  • Sr. Member
  • ****
  • Helpful Post Rating: 11
  • Posts: 76
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #7 on: August 08, 2008, 09:24:45 PM »

For the "all on.jpg" you can see that nothing happens for 4 seconds after it has received the command.  That is what I am referring to...so what is going on?

As mentioned above, the delays, as shown in the second picture, will allow it to start immediately.

As far as putting them in groups and in different house codes...that would should work.  BUT I remember now after trying it again that it won't work with my IR-543!  I can only control one house code with it so unless I get multiple ones, I need to put this all one one house code.
« Last Edit: August 12, 2008, 02:01:13 AM by -Bill- (of wgjohns.com) »
Logged

PajamaGuy

  • Hero Member
  • *****
  • Helpful Post Rating: 32
  • Posts: 522
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #8 on: August 09, 2008, 06:46:12 AM »

Boiler - Great examples - 1 question.

With preferences set to Bright 100, you showed with & without delays, but with preferences set to ON, you only timed the macro with the delays, what's your timing for no delays - please?
« Last Edit: August 12, 2008, 02:02:03 AM by -Bill- (of wgjohns.com) »
Logged
PajamaGuy
Win-7 - Dell XPS -Automation
VA12a on a dedicated desktop - Video
XTB-IIR & V572RF32

Remote via LogMeIn (FREE) and Ignition

Boiler

  • Guest
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #9 on: August 09, 2008, 02:46:39 PM »

aslamma,

Thank you very much for posting your macros.  I now understand the delay that you were referring to.  I appreciate the effort that you put into this.  Unfortunately, the delay that you are observing is a result of the X10 protocol.  In order to explain this further, we'll need to get into the actual timing of the protocol.

Pajamaguy,

I hope this will answer your question as well (with hard numbers).

I) Most X10 command sequences are made up of three sections. 
1) Start Code - 4 bits/2 powerline cycles.  These are transmitted on both rising and falling edge powerline crossing so 4 bits only requires 2 cycles (see below)
2) Letter Code - 4 Bit/4 powerline cycles
3) Command Code - 5 bits/5 powerline cycles.

As stated in the "Uncle Phil Kingery" graphic below, each transmission is repeated requiring a total of 22 cycles or 0.37 seconds (22 cycles X 1/60 seconds per cycle).



II) In order to properly communicate with a unit, it is normally addressed and then commanded:
1)  Unit Addressing (per the protocol in I above) - 22 powerline cycles (0.37 seconds)
2) Communication Gap : A three cycle gap is inserted per X10 protocol - 3 powerline cycles (0.05 seconds)
3) X10 Command: Addresses units are commanded (same timing as in I above) - 22 powerline cycles (0.37 seconds)

For a "normal" command sequence (simple on/off) 47 powerline cycles are required or 0.78 seconds.  Borrowing from Uncle Phil's graphics expertise once again, the following depicts a "standard" transmission sequence.



For those interested (and in deference to "Uncle Phil Kingery", X10 Sage and fellow Hoosier), the entire article ir located here: Kingery13 - Digital X10

The entire Uncle Phil series is available from the ACT website (excellent reference material): Uncle Phil Series
 
III) Bright/Dim Sequences.  Now that we have the "normal mode" communication timing behind us we can look at bright/dim sequences.  These do not conform to the X10 protocol standard.  Bright/Dim commands are sent as a series of concatenated commands without a "normal" 3 cycle gap between them.  In section I above it was stated that commands are sent twice.  Dim commands are sent many times with no gap in order to achieve the level of bright/dim required.  AHP will send 10 bright/dim "pairs" to achieve 100%/0% brightness at the unit.

A common problem with many "new" installs is the "preference option" for "issue on in place of Bright 100%" (shown below).  If this is not checked AHP will use "Bright" commands when you think you are simply turning the lamp "ON".  These commands are slow, error prone, and extremely hard on repeaters and receivers.

The following shows an example of simple "ON" timing with "issue on in place of Bright 100%" checked and unchecked.




IV) Absolute Bright/Dim.  In order to execute an "Absolute" bright/dim command, AHP first turns the unit on to full brightness.  After that it Dims the unit to the requested level.  The following shows timing comparisons with the preferences option check and unchecked.  If you have a macro with multiple units being activated, it can take some significant time to communicate.



V) Multiple Unit On Macro (No delay between units).  When a macro is constructed with no delays between units (as shown below), AHP will first address all of the units and then send a single "ON" commands. 

aslamma
and PajamaGuy
  I believe this answers both of your questions regarding the delays for "stacked units".  The 4 second delay prior to any noticeable activity it simply due to AHP "Addressing" all of the units involved.


VI) The All On Command - Another Exception.  I refer to the "All-ON/Off" command as an exception because it combines the addressing function with a command.  One command to rule them all (sorry for the Lord of the Rings reference).  If you can arrange your unit housecodes to make use of this command, it's extremely quick and reliable.  Alas, there's no "All Dim" equivalent.



VII) Extended Codes and the LM14a Interface - a Better Way to Dim.  For those of you who've been blessed/cursed? with some of the "newer" units, these are extended code "direct dim" capable.  Much faster and reliable than the old X10 Dim command sequence.  You do have to be careful...

Sorry, but duty calls.  I need to weld/paint the rocker panels on my Wife's van so she can use it on Monday.

Gotta love living in the rust belt,
Boiler

Updated/Corrected - Added colors for Address functions, Unit Commands, and Concatenated Dims.  Added graphic to section V) (missed on the first pass).
« Last Edit: October 25, 2009, 05:42:22 PM by Boiler »
Logged

steven r

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 74
  • Posts: 2189
  • Halloween with X10
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #10 on: August 09, 2008, 04:20:33 PM »

WOW!

Thanks Boiler. I added a helpful for you.
 
That is also the clearest explanation of why one should check the "On in place of Bright 100%" I've ever heard. I never found that to be question to be very clear in AHP.

This could be a good topic to sticky somewhere as a reference.
« Last Edit: August 12, 2008, 02:03:28 AM by -Bill- (of wgjohns.com) »
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. :)

PajamaGuy

  • Hero Member
  • *****
  • Helpful Post Rating: 32
  • Posts: 522
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #11 on: August 10, 2008, 06:43:19 AM »

Boiler - read yours last night - mouth just hangs open.   Thanks!


(I think you'll appreciate this - that's an XTB-IIR hiding under the CM15A - the board is fed 2-phase 240v from the main panel - 9 ft' away)
« Last Edit: August 12, 2008, 02:03:59 AM by -Bill- (of wgjohns.com) »
Logged
PajamaGuy
Win-7 - Dell XPS -Automation
VA12a on a dedicated desktop - Video
XTB-IIR & V572RF32

Remote via LogMeIn (FREE) and Ignition

steven r

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 74
  • Posts: 2189
  • Halloween with X10
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #12 on: August 10, 2008, 09:37:33 AM »

PajamaGuy: What are you controlling with the appliance module?
« Last Edit: August 12, 2008, 02:04:43 AM by -Bill- (of wgjohns.com) »
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. :)

PajamaGuy

  • Hero Member
  • *****
  • Helpful Post Rating: 32
  • Posts: 522
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #13 on: August 10, 2008, 09:56:59 AM »

The V572 - It sometimes storms the powerline with a flood of PLCs (WGLDesigns is working on it), and they usuallt contain an "A1-ON" - so I trigger a macro to cycle the power to the V572 OFF -Delay 30 sec. - ON.
Although I think telling the V572 to NOT transceive "A" may have eliminated its need.

« Last Edit: August 12, 2008, 02:05:17 AM by -Bill- (of wgjohns.com) »
Logged
PajamaGuy
Win-7 - Dell XPS -Automation
VA12a on a dedicated desktop - Video
XTB-IIR & V572RF32

Remote via LogMeIn (FREE) and Ignition

HA Dave

  • Hero Member
  • *****
  • Helpful Post Rating: 174
  • Posts: 7043
Re: Macros slow to execute...any ideas? (I have my own workaround for now)
« Reply #14 on: August 10, 2008, 11:45:58 AM »


(I think you'll appreciate this - that's an XTB-IIR hiding under the CM15A - the board is fed 2-phase 240v from the main panel - 9 ft' away)



WOW.... very impressive!
« Last Edit: August 12, 2008, 02:05:51 AM by -Bill- (of wgjohns.com) »
Logged
Home Automation is an always changing technology
Pages: [1] 2
 

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