X10 Community Forum
🖥️ActiveHome Pro => ActiveHome Pro General => Help & Troubleshooting => Topic started by: aslamma on August 08, 2008, 11:34:03 AM
-
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.
-
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.
-
.......... Here's some examples of execution -
Boiler that is the finest example of how the delays work I have ever seen. THANK YOU!
-
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.
-
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
-
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.
-
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
-
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.
-
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?
-
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).
(http://www.boiler.ucoz.com/Geocities/kingery.JPG)
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.
(http://www.boiler.ucoz.com/Geocities/Kingery2.JPG)
For those interested (and in deference to "Uncle Phil Kingery", X10 Sage and fellow Hoosier), the entire article ir located here: Kingery13 - Digital X10 (http://www.act-solutions.com/PCC/kingery13.htm)
The entire Uncle Phil series is available from the ACT website (excellent reference material): Uncle Phil Series (http://www.act-solutions.com/PCC/uncle.htm)
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.
(http://www.boiler.ucoz.com/Geocities/Timing_1.JPG)
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.
(http://www.boiler.ucoz.com/Geocities/Timing_2.JPG)
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.
(http://www.geocities.com/boiler1977/Timing_3.JPG)
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.
(http://www.boiler.ucoz.com/Geocities/Timing_4.JPG)
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).
-
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.
-
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)
-
PajamaGuy: What are you controlling with the appliance module?
-
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.
-
(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!
-
(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)
And you would be thinking correctly. Nice setup - I was going to ask about the appliance module, but Steven beat me to the punch.
Boiler
-
Hey Boiler, thanks a lot for the response...makes perfect sense! Haha...actually, I was pretty lost.
But end result for applications...best way to get multiple modules to turn give you feedback if they are triggered is to add the delay in between commands, correct? This seems to work pretty good. Since there does not appear to be a way to get it to trigger all modules quickly, this looks like the best option.
-
Hey Boiler, thanks a lot for the response...makes perfect sense! Haha...actually, I was pretty lost.
But end result for applications...best way to get multiple modules to turn give you feedback if they are triggered is to add the delay in between commands, correct? This seems to work pretty good. Since there does not appear to be a way to get it to trigger all modules quickly, this looks like the best option.
Aslamma,
Incorrect, I think you missed section V!). The quickest way to turn a group of units on is with the "All ON" command:
-
Sorry, you are correct. Actually, I realize that, but unless the grouping of lights is on the same code, that cannot be accomplished. It is good to realize these things in the setup beforehand. Unfortunately in my situation, I would need multiple IR-543's to address the additional house codes. This would be possible, but would complicate my particular setup. Is there a version of the IR-543 that will address all house codes?
-
Sorry, you are correct. Actually, I realize that, but unless the grouping of lights is on the same code, that cannot be accomplished. It is good to realize these things in the setup beforehand. Unfortunately in my situation, I would need multiple IR-543's to address the additional house codes. This would be possible, but would complicate my particular setup. Is there a version of the IR-543 that will address all house codes?
Have you found the IR543AH? Like the IR543 but does all house codes! (http://www.automatedoutlet.com/product.php?productid=1316&cat=0&page=1)
-
Ahh, did not even know it existed...thanks for pointing that out. Quite expensive for X-10 standards though...used to getting like 10 things for $90, haha.
-
If you happen to have one of the "new" version WS467 (extended code capable), you could also create an extended code "group" (scene). The new version modules were reported to support extended code group functions by Charles Sullivan : New WS467a Functions (http://www.heyu.org/docs/New_WS467.txt). Using this function you could "group" units and turn them on using a single extended code command (advanced function within the macro).
I don't have any of the "newer" units, so I can't check this out. Maybe someone else can assist?
Boiler
-
So Boiler...shall we look at dimming?
I think that some of the techniques mentioned in this thread do a good job of addressing how to turn lights on and off in a quick fashion. BUT, dimming is still "painfully" slow, especially for groups of lights in a macro. Are there any particular techniques that would make dimming groups of lights quick? I would like to be able to work with absolute brightness and relatively brightness.
The major problem for me has been with macros that consist of brightening and dimming. Since they are so slow, and I am not sure when they are complete, a subsequent trigger (for a different macro), may be unreliable. This is because I may press the second macro before the first is finished. Perhaps this has already been covered though?
-
So Boiler...shall we look at dimming?
I think that some of the techniques mentioned in this thread do a good job of addressing how to turn lights on and off in a quick fashion. BUT, dimming is still "painfully" slow, especially for groups of lights in a macro. Are there any particular techniques that would make dimming groups of lights quick? I would like to be able to work with absolute brightness and relatively brightness.
The major problem for me has been with macros that consist of brightening and dimming. Since they are so slow, and I am not sure when they are complete, a subsequent trigger (for a different macro), may be unreliable. This is because I may press the second macro before the first is finished. Perhaps this has already been covered though?
Aslamma,
The following will only work if you have one of the "new version" WS467's that began to appear in '07.
These units include a feature called "Extended code direct dim". By using an extended code command you can set them directly to a desired level. While these commands are 31 bits long, they are still far quicker than the old dim/bright commands.
To check whether you units are compatible, re-identify you WS467 as a 2-way lamp module (download to the interface). Move the bright/dim slider to 50% (not all the way on) and note whether you light responds. If it does you have a extended code compatible WS467.
The graphic below shows how activity monitor displays the extended code transmission for a 51% dim command (using the LM14a 2-way lamp module interface). If this works for you, re-try your macros and see if you notice an imprvement.
(http://www.boiler.ucoz.com/Geocities/extendedcode.JPG)
Boiler
-
Oh the irony.
Yes, I have the new modules and have done what you suggested Boiler. It worked much better than the previous setup for brightening and dimming. And, get this, I tried it without the insertion of the delay (previous approach was to use the delay in between modules)...and it worked great there as well! So it appears that at least for now I can switch all the modules to the 2 way lamp module and not worry about incorporating the delays.
Thanks!!!!!!!!!! Working much much better now!
-
Aslamma,
Sorry, I should have asked about the Date code of your units earlier. All of my units are old and do not have these "new" features.
You are correct that delays are not required when using the extended code communication. This communication mode does not allow AHP to "stack" multiple unitcodes together.
If you are interested, Charles Sullivan put together a White paper on the capabilities of the newer units: Charles Sullivan's Heyu Site (http://www.heyu.org/docs/)
One additional thing that I should mention - these units include a feature called "resume dim". If a unit is dimmed to 50% and then turned "OFF", it will return to the 50% level when it receives the next "ON" command. This drives a lot of people nuts (my Leviton units work the same way).
The extended code interface (LM14a 2-way) that you are using will bypass this feature by using the extended code command, UNLESS you issue a simple ON command. AHP will not use extended codes for a simple on or 100% bright command. You can get around this by using 99% bright in your macros rather than 100%.
Also, the extended codes only work with "absolute" bright/dim commands. If you program a macro with relative dims (dim by xx%), AHP will use the old dim command set.
Happy Automating,
Boiler