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] 3

Author Topic: Dimming & brightening Commands From Software  (Read 19712 times)

PajamaGuy

  • Hero Member
  • *****
  • Helpful Post Rating: 32
  • Posts: 522
Re: Dimming & brightening Commands From Software
« Reply #15 on: August 15, 2008, 03:47:16 PM »

Hey Boiler - where does that "Events Report" come from???
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: Dimming & brightening Commands From Software
« Reply #16 on: August 15, 2008, 03:56:33 PM »

Bright and Dim commands are very difficult for a repeater to handle properly due to the fact that they deviate from normal X10 protocol.  Most repeaters skip alternate bright/dim commands that are part of a sequence, resulting in a different command from the one that was sent.  That's why I spent a lot of time trying to get it right in the XTB-IIR.

Jeff

Jeff,

Agreed (we've been here before).  The "older" repeaters would skip the first command in the X10 "doublet".  The result was that the power phase the transmitter was located on would respond correctly.  The opposite phase (receiving from the repeater) would only see one of the "doublet" dim commands and perform a "micro dim" (out of synch with the transmitting phase).

In contrast, my Leviton HCA02 appears to be transmitting the entire dim sequence and the CM15a is "hearing" this as a separate transmission.  My testerlinc does not register any "retransmission" from the opposite phase.  I'm sure the repeater is causing the issue, but I can't explain the interaction.

Boiler
Logged

Boiler

  • Guest
Re: Dimming & brightening Commands From Software
« Reply #17 on: August 15, 2008, 03:58:37 PM »

Hey Boiler - where does that "Events Report" come from???


That's actually a "massaged" output from the activity monitor.  If you "save" from activity monitor it will produce a .html file that you can import and edit.
Logged

JeffVolp

  • Community Organizer
  • Hero Member
  • ***
  • Helpful Post Rating: 106
  • Posts: 2058
    • XTB Home Page
Re: Dimming & brightening Commands From Software
« Reply #18 on: August 15, 2008, 04:57:05 PM »

The "older" repeaters would skip the first command in the X10 "doublet".  The result was that the power phase the transmitter was located on would respond correctly.  The opposite phase (receiving from the repeater) would only see one of the "doublet" dim commands and perform a "micro dim" (out of synch with the transmitting phase).

It is a little more complex than that.  You are entirely correct about skipping the first command in the "doublet".  But, that format only applies to the first bright/dim command in a sequence.  Sequential commands are not sent as "doublets".  They are tacked onto the end of the first command just a half a command at a time, with no inter-command gap.  As you say, the TW523 and older repeaters would parse that sequence forming "doublets" out of each pair of half commands, turning them into micro-dims.

Even the XTB-IIR does not repeat the first half of the first command, because that must be decoded and error checked first.  It is not possible to tack it onto the end of the sequence because that would certainly collide with any other command tailgating the dim sequence sent by the controller.

I do have a CM15A, and am interested in how it reports a dim sequence repeated by the XTB-IIR.  I am not that familiar with the CM15A, but if you could give me the step-by-step sequence for your test, I will try to repeat that here.

Jeff
Logged
X-10 automation since the BSR days

tom j

  • Hero Member
  • *****
  • Helpful Post Rating: 16
  • Posts: 1270
Re: Dimming & brightening Commands From Software
« Reply #19 on: August 15, 2008, 11:38:37 PM »

Hi Boiler thanks for the help! Say a few questions do your Leviton switches have that soft start and memory? and are you saying that yours actually work with timers? I couldn't get my timers to work with them I was thinking it was because of the memory they always come on at the last dim level that was set.

Tom j.
Logged

Boiler

  • Guest
Re: Dimming & brightening Commands From Software
« Reply #20 on: August 16, 2008, 12:41:49 PM »

It is a little more complex than that.  You are entirely correct about skipping the first command in the "doublet".  But, that format only applies to the first bright/dim command in a sequence.  Sequential commands are not sent as "doublets".  They are tacked onto the end of the first command just a half a command at a time, with no inter-command gap.  As you say, the TW523 and older repeaters would parse that sequence forming "doublets" out of each pair of half commands, turning them into micro-dims.

Sorry Jeff,
Bad phrasing on my part.  I do understand that the Dim command is a stream with no gaps between...

I do have a CM15A, and am interested in how it reports a dim sequence repeated by the XTB-IIR.  I am not that familiar with the CM15A, but if you could give me the step-by-step sequence for your test, I will try to repeat that here.

Thank you for volunteering (I was hoping that someone might).  I would be extremely interested in how the CM15a interacts with the XTB-IIR.

Allow me to state a couple of observations:
1) This problem surfaces when running commands from the PC.  When operating the switch sliders (AHP GUI) or manually activating a macro (clicking the macro start button in the GUI) the AHP software "sees" a wrap back  from my HCA02 repeater and gets confused.
2) When operating macros from the interface the problem is averted because the interface always sends the lamp module to 100% prior to dimming.  The "wrap back" receives are still in Activity monitor, the interface simply gets around them with it's method of dimming.

Configuration

Lamp module at L1
Macro at L10
Appliance module at L10 (used to trigger macro)
All transceived codes Disabled
Preferences: Issue ON in place of Bright %100 enabled.




I)Activity log with the Repeater Disabled, Macro Stored in the Interface: When run from the interface, the Macro issues a "L Bright 100%" prior to each "Dim %" command.

Event    Date/Time    Action    Data
0    08/16/2008 10:55:44 am    Transmit    L10 (Test Macro)
1    08/16/2008 10:55:45 am    Transmit    L On (Test Macro)
2    08/16/2008 10:55:46 am    Macro    L1 (New Module)
3    08/16/2008 10:55:46 am    Macro    L On (New Module)
4    08/16/2008 10:55:56 am    Macro    L1 (New Module)
5    08/16/2008 10:55:56 am    Macro    L Bright 100(New Module)
6    08/16/2008 10:55:56 am    Macro    L Dim 49(New Module)
7    08/16/2008 10:56:05 am    Macro    L1 (New Module)
8    08/16/2008 10:56:05 am    Macro    L Bright 100(New Module)
9    08/16/2008 10:56:05 am    Macro    L Dim 65(New Module)
10    08/16/2008 10:56:15 am    Macro    L1 (New Module)
11    08/16/2008 10:56:15 am    Macro    L Bright 100(New Module)
12    08/16/2008 10:56:15 am    Macro    L Dim 69(New Module)
13    08/16/2008 10:56:25 am    Macro    L1 (New Module)
14    08/16/2008 10:56:25 am    Macro    L Bright 100(New Module)
15    08/16/2008 10:56:25 am    Macro    L Dim 73(New Module)

II)Activity log with the Repeater Enabled, Macro Stored in the Interface: Same setup with the repeater enabled.  The red highlighted receives are what I refer to as "wrapback".  These only occur when my repeater is enabled.  They do not affect the lamp module operation because the interface is sending a 100% bright prior to each Dim% command.

Event    Date/Time    Action    Data
0    08/16/2008 10:52:19 am    Transmit    L10 (Test Macro)
1    08/16/2008 10:52:19 am    Transmit    L On (Test Macro)
2    08/16/2008 10:52:21 am    Macro    L1 (New Module)
3    08/16/2008 10:52:21 am    Macro    L On (New Module)
4    08/16/2008 10:52:31 am    Receive    L Dim 47(New Module)
5    08/16/2008 10:52:31 am    Macro    L1 (New Module)
6    08/16/2008 10:52:31 am    Macro    L Bright 100(New Module)
7    08/16/2008 10:52:31 am    Macro    L Dim 49(New Module)
8    08/16/2008 10:52:41 am    Macro    L1 (New Module)
9    08/16/2008 10:52:41 am    Macro    L Bright 100(New Module)
10    08/16/2008 10:52:41 am    Macro    L Dim 65(New Module)
11    08/16/2008 10:52:49 am    Receive    L Bright 100(New Module)
12    08/16/2008 10:52:52 am    Receive    L Dim 68(New Module)
13    08/16/2008 10:52:52 am    Macro    L1 (New Module)
14    08/16/2008 10:52:52 am    Macro    L Bright 100(New Module)
15    08/16/2008 10:52:52 am    Macro    L Dim 69(New Module)
16    08/16/2008 10:53:02 am    Macro    L1 (New Module)
17    08/16/2008 10:53:02 am    Macro    L Bright 100(New Module)
18    08/16/2008 10:53:02 am    Macro    L Dim 73(New Module)


III)Activity log with the Repeater Disabled, Macro Stored in the PC: Once again, with the repeater disabled there is no evidence of receives in the activity log.  Note that the PC initiated macro is very different from the Interface initiated macro.  The PC simply issues a sequence of Dim commands, no Bright 100%.  This is because the PC "believes" it knows what level the lamp is currently at.

Event    Date/Time    Action    Data
0    08/16/2008 10:39:04 am    Transmit    L10 (Test Macro)
1    08/16/2008 10:39:04 am    Transmit    L On (Test Macro)
2    08/16/2008 10:39:06 am    Transmit    L1 (New Module)
3    08/16/2008 10:39:07 am    Transmit    L On (New Module)
4    08/16/2008 10:39:12 am    Transmit    L Dim 49(New Module)
5    08/16/2008 10:39:19 am    Transmit    L Dim 16(New Module)
6    08/16/2008 10:39:25 am    Transmit    L Dim 4(New Module)
7    08/16/2008 10:39:30 am    Transmit    L Dim 4(New Module)


IV)Activity log with the Repeater Enabled, Macro Stored in the PC: With the repeater enabled the "Wrap-Back Receives" are back again.  In this case the receives are confusing the PC. 

The below is a bit difficult to follow, so here's a summary -

Event 4 : The macro executes an absolute Dim 49% ( Requested level was 51% absolute = 100% - 49%).  AHP believes the lamp is at 51% (it is)
Event 5: AHP "sees" a wrap back from the repeater (DIM 52%).  The software now believes the lamp is at 0% ( 51% - 52% = off).
Event 6: Macro programmed level is 35% absolute.  Since AHP believes the lamp is Off, it incorrectly issues a Bright 35%.


Event    Date/Time    Action    Data
0    08/16/2008 10:27:42 am    Transmit    L10 (Test Macro)
1    08/16/2008 10:27:42 am    Transmit    L On (Test Macro)
2    08/16/2008 10:27:44 am    Transmit    L1 (New Module)
3    08/16/2008 10:27:44 am    Transmit    L On (New Module)
4    08/16/2008 10:27:50 am    Transmit    L Dim 49(New Module)
5    08/16/2008 10:27:52 am    Receive    L Dim 52(New Module)
6    08/16/2008 10:27:57 am    Transmit    L Bright 35(New Module)
7    08/16/2008 10:28:03 am    Transmit    L Dim 4(New Module)
8    08/16/2008 10:28:04 am    Receive    L Dim 5(New Module)
9    08/16/2008 10:28:09 am    Transmit    L Bright 1(New Module)
10    08/16/2008 10:28:09 am    Receive    L Bright 5(New Module)


That's it in a nutshell (maybe a coconut).  It would appear that this only affects PC initiated commands/macros.  Since I don't have any security/camera devices I can't say if there are any impacts on PC operations with these devices.

Jeff : I'm not sure if the above is sufficient for you to conduct testing of the XTB-II.  Please PM me if you'd like additional info/files.

Thanks,
Boiler
« Last Edit: October 25, 2009, 05:40:09 PM by Boiler »
Logged

Boiler

  • Guest
Re: Dimming & brightening Commands From Software
« Reply #21 on: August 16, 2008, 01:07:21 PM »

Hi Boiler thanks for the help! Say a few questions do your Leviton switches have that soft start and memory? and are you saying that yours actually work with timers? I couldn't get my timers to work with them I was thinking it was because of the memory they always come on at the last dim level that was set.

Tom j.

Tom,
Yes my Leviton switches do have the soft start and resume dim.  One of the ways to get around this is to use the extended code interface.  The easy way around the resume dim feature is to identify the units as "LM14a 2-way lamp modules" as shown below.  This interface will allow AHP to use "extended code" commands to communicate with the unit.



Having don the above, create an "ON" macro similar to the following.  DO NOT program the lamp to 100%.  Use a level less that 100% on.  Add a timer to the ON macro and you are done.

« Last Edit: October 25, 2009, 05:21:01 PM by Boiler »
Logged

JeffVolp

  • Community Organizer
  • Hero Member
  • ***
  • Helpful Post Rating: 106
  • Posts: 2058
    • XTB Home Page
Re: Dimming & brightening Commands From Software
« Reply #22 on: August 16, 2008, 03:32:33 PM »

Hi Boiler,

Thanks for the detailed info.  Due to migrating hard drives, I have to re-install the AH software.  I'll PM you if I need more info, and will post here when I have some results.

Update:   When sending commands from the PC, the AH log is certainly different when a smart repeater is active.  The lamp module also reacts differently, depending on whether the repeater is a dumb "doublet" repeater or a smart repeater.  It is interesting to note that a similar sequence of bright/dim ramps from the Ocelot produces exactly the same brightness levels from the lamp, regardless of whether the TW523 is running barefoot, with a "doublet" repeater, or a smart repeater.  The AH logs monitoring Ocelot activity are also identical for each configuration.

Update2:   Running the macro in the CM15A rather than through the PC produced exactly the same results in my configuration.  The "doublet" repeater showed only the transmissions in the log.  The smart repeater showed the received commands after two of the transmissions.  That result is 100% repeatable.  AH calculates the lamp intensity based on the sum of the transmitted and received commands, which is wrong.  The lamp only responds to the transmitted commands.

Now, when the lamp module cannot receive the command directly from the CM15A (by running the lamp module through a XPPF X10 filter), it obviously does not respond to direct CM15A commands.  The XTB-IIR punches enough signal through the XPPF for the lamp module to respond.  The macro running through the “doublet” repeater turns on the lamp, but no dimming is evident.  That is because the lamp module is receiving only alternate dim commands, which it interprets as micro-dims.  As I recall, it takes over 100 micro-dims (192?) to ramp the brightness from full on to full off.  Using the smart repeater, the lamp module responds to the “transmitted” commands as before.

At this point I don't understand why the CM15A sees a "received command" due to a smart repeater adding its signal in sync with each of the CM15A transmitted bits for the additional bright/dim commands in a sequence.  The results with the Leviton HCA02 repeater seem to be very similar to those for the XTB-IIR running in the "smart bright/dim repeater" mode.  So, that unit must also solve the micro-dim problem on the phase opposite the CM15A.

It looks like relative dims from the CM15A will be a problem for any repeater that fully repeats a bright/dim sequence.  The option for the XTB-IIR is to plug the CM15A directly into the X10 Boost input.  In that case, the CM15A does not see a repeated version of its own commands, and doesn't get confused.

Update3:  

Just to complete the documentation, the macro sequence I used was:

ON – 5 sec – Dim 61% - 5 sec – Dim 35% - 5 sec – Dim 27%

With the CM15A running barefoot or paired with a dumb "doublet" repeater, the AH log showed:

Transmit ON
Transmit Dim 39%
Transmit Dim 26%
Transmit Dim 8%

When the smart repeater was in the loop, the AH log showed:

Transmit ON
Transmit Dim 39%
Receive Dim 42%
Transmit Bright 16%
(no receive reported)
Transmit Dim 8%
Receive Dim 10%

That intermediate "Transmit Bright" is similar to that reported when using the Leviton HCA02.  After the first dim, the CM15A thinks the brightness is only 19% (100 - 39 - 42), so it must brighten by 16% to achieve the next 35% level.  Note: for all tests the lamp was turned off before triggering the macro so the initial conditions were the same.  In my case, the results were exactly the same when running the macro either via the PC or triggered internally in the CM15A.

Jeff
« Last Edit: August 17, 2008, 10:24:47 AM by JeffVolp »
Logged
X-10 automation since the BSR days

Boiler

  • Guest
Re: Dimming & brightening Commands From Software
« Reply #23 on: August 17, 2008, 11:51:36 AM »

Jeff,

Thank you for all the effort.  Sounds as if we have some good news and some bad.


Update:   When sending commands from the PC, the AH log is certainly different when a smart repeater is active.  The lamp module also reacts differently, depending on whether the repeater is a dumb "doublet" repeater or a smart repeater.  It is interesting to note that a similar sequence of bright/dim ramps from the Ocelot produces exactly the same brightness levels from the lamp, regardless of whether the TW523 is running barefoot, with a "doublet" repeater, or a smart repeater.  The AH logs monitoring Ocelot activity are also identical for each configuration.

Interesting - How does the Ocelot get around the problem of the "doublet" repeater transmitting micro-dims?  Different command format?

At this point I don't understand why the CM15A sees a "received command" due to a smart repeater adding its signal in sync with each of the CM15A transmitted bits for the additional bright/dim commands in a sequence.  The results with the Leviton HCA02 repeater seem to be very similar to those for the XTB-IIR running in the "smart bright/dim repeater" mode.  So, that unit must also solve the micro-dim problem on the phase opposite the CM15A.

It looks like relative dims from the CM15A will be a problem for any repeater that fully repeats a bright/dim sequence.  The option for the XTB-IIR is to plug the CM15A directly into the X10 Boost input.  In that case, the CM15A does not see a repeated version of its own commands, and doesn't get confused.

The not so good news is that the CM15A is being fooled by the repeated sequence on the opposite phase. 
The good news is that the XTB-IIR boost option drive both phases in parallel, thereby preventing the CM15a from getting confused from seeing it's own commands. 



When the smart repeater was in the loop, the AH log showed:

Transmit ON
Transmit Dim 39%
Receive Dim 42%
Transmit Bright 16%
(no receive reported)
Transmit Dim 8%
Receive Dim 10%

That intermediate "Transmit Bright" is similar to that reported when using the Leviton HCA02.  After the first dim, the CM15A thinks the brightness is only 19% (100 - 39 - 42), so it must brighten by 16% to achieve the next 35% level.  Note: for all tests the lamp was turned off before triggering the macro so the initial conditions were the same.  In my case, the results were exactly the same when running the macro either via the PC or triggered internally in the CM15A.

Here we have a difference.  When I ran from the interface, the CM15a would insert "Bright 100%" commands prior to each dim command.  In doing this the interface was able to get around the problem of the "received dims" because it was resetting the lamp level to 100% each time.  Not sure if this difference is due to the fact that I'm still running Version 3.204


Event    Date/Time    Action    Data
0    08/16/2008 10:52:19 am    Transmit    L10 (Test Macro)
1    08/16/2008 10:52:19 am    Transmit    L On (Test Macro)
2    08/16/2008 10:52:21 am    Macro    L1 (New Module)
3    08/16/2008 10:52:21 am    Macro    L On (New Module)
4    08/16/2008 10:52:31 am    Receive    L Dim 47(New Module)
5    08/16/2008 10:52:31 am    Macro    L1 (New Module)
6    08/16/2008 10:52:31 am    Macro    L Bright 100(New Module)
7    08/16/2008 10:52:31 am    Macro    L Dim 49(New Module)
8    08/16/2008 10:52:41 am    Macro    L1 (New Module)
9    08/16/2008 10:52:41 am    Macro    L Bright 100(New Module)
10    08/16/2008 10:52:41 am    Macro    L Dim 65(New Module)
11    08/16/2008 10:52:49 am    Receive    L Bright 100(New Module)
12    08/16/2008 10:52:52 am    Receive    L Dim 68(New Module)
13    08/16/2008 10:52:52 am    Macro    L1 (New Module)
14    08/16/2008 10:52:52 am    Macro    L Bright 100(New Module)
15    08/16/2008 10:52:52 am    Macro    L Dim 69(New Module)
16    08/16/2008 10:53:02 am    Macro    L1 (New Module)
17    08/16/2008 10:53:02 am    Macro    L Bright 100(New Module)
18    08/16/2008 10:53:02 am    Macro    L Dim 73(New Module)


Once again, thank you for confirming the "Dim receive" interaction between smart repeaters and the CM15a and for confirming that the XTB-IIR can boost the CM15a output without inducing this problem.  Very nice device.

Boiler
Logged

JeffVolp

  • Community Organizer
  • Hero Member
  • ***
  • Helpful Post Rating: 106
  • Posts: 2058
    • XTB Home Page
Re: Dimming & brightening Commands From Software
« Reply #24 on: August 17, 2008, 12:58:41 PM »


Update:   When sending commands from the PC, the AH log is certainly different when a smart repeater is active.  The lamp module also reacts differently, depending on whether the repeater is a dumb "doublet" repeater or a smart repeater.  It is interesting to note that a similar sequence of bright/dim ramps from the Ocelot produces exactly the same brightness levels from the lamp, regardless of whether the TW523 is running barefoot, with a "doublet" repeater, or a smart repeater.  The AH logs monitoring Ocelot activity are also identical for each configuration.

Interesting - How does the Ocelot get around the problem of the "doublet" repeater transmitting micro-dims?  Different command format?

The Ocelot has the same problem on the opposite phase with a "doublet" repeater.  But, it is not confused by any "repeated" commands, and sends exactly the same sequence of dims, regardless of whether it is working through a barefoot TW523, or paired with either kind of repeater.  The reason I added the smart repeater capability to the XTB-IIR was a result of the micro-dim problem on the phase opposite the Ocelot.

At this point I don't understand why the CM15A sees a "received command" due to a smart repeater adding its signal in sync with each of the CM15A transmitted bits for the additional bright/dim commands in a sequence.  The results with the Leviton HCA02 repeater seem to be very similar to those for the XTB-IIR running in the "smart bright/dim repeater" mode.  So, that unit must also solve the micro-dim problem on the phase opposite the CM15A.

It looks like relative dims from the CM15A will be a problem for any repeater that fully repeats a bright/dim sequence.  The option for the XTB-IIR is to plug the CM15A directly into the X10 Boost input.  In that case, the CM15A does not see a repeated version of its own commands, and doesn't get confused.

The not so good news is that the CM15A is being fooled by the repeated sequence on the opposite phase. 
The good news is that the XTB-IIR boost option drive both phases in parallel, thereby preventing the CM15a from getting confused from seeing it's own commands.

A repeater will overlay its own output on top of the source signal on both phases.  The CM15A somehow recognizes the repeated commands on its own phase even though they are in bit sync with its own output, and thinks that is another command.  Apparently, it has been programmed to ignore the output of a "doublet" repeater, since that is the version that X10 markets themselves.

(detailed stuff deleted to shorten this post)

Here we have a difference.  When I ran from the interface, the CM15a would insert "Bright 100%" commands prior to each dim command.  In doing this the interface was able to get around the problem of the "received dims" because it was resetting the lamp level to 100% each time.  Not sure if this difference is due to the fact that I'm still running Version 3.204

I installed 3.228 yesterday.  The main difference is that I always preceded the macro (run on the PC or from the CM15A) with an OFF command.  So, AH started every macro cycle from 0%, and the beginning ON always brought the lamp to 100%.  There were no intermediate ramps back up to 100% either from the PC or directly from the CM15A.  If I didn't issue the OFF at the beginning, the results were harder to understand as it ramped from a prior calculated level rather than 0%.

Jeff
« Last Edit: August 17, 2008, 01:08:36 PM by JeffVolp »
Logged
X-10 automation since the BSR days

tom j

  • Hero Member
  • *****
  • Helpful Post Rating: 16
  • Posts: 1270
Re: Dimming & brightening Commands From Software
« Reply #25 on: August 21, 2008, 01:17:51 AM »

Dave and Tom,

What I was trying to say above is that I see "Opposite commands" when I use a Macro or the Module Slider.  When I turn off the Leviton repeater the problem goes away.  Unfortunately, without the repeater I can't reliably transmit to the entire house.

Tom - if you have a repeater, try disabling it and repeating your test. 


Hi Boiler, say you know I do have a repeater a x10 Pro actually but if you're using the software it's just going through the household wiring isn't it can't see who the repeater is involved, but maybe I'm missing something. I don't know what's going on here I just dimmed the hallway lights from 50 to 43 percent and they actually got brighter hmm. Thanks!!

Tom j.
.


« Last Edit: August 25, 2008, 02:38:27 AM by tom j »
Logged

tom j

  • Hero Member
  • *****
  • Helpful Post Rating: 16
  • Posts: 1270
Re: Dimming & brightening Commands From Software
« Reply #26 on: August 25, 2008, 02:53:39 AM »

Hi thanks Boiler for the help with the Leviton switches! I plan on trying this right away. But come on guys give me a hand here if you're just trying to adjust the dim level from the software using the sliders with "none for the transceiver house codes checked"  I'm using my Protector Plus to receive my wireless commands. With that setup the repeater wouldn't have any effect on me trying to adjust my dim levels from the software would it?? Like for example if I try to dim from say 50% to 30% it might actually get brighter, this doesn't always happen but enough to be very irritating. Could someone tell me what they thing might be going on here, I hope I've explained it clearly. Just trying to adjust my dim levels from the software with the CM15a connected to the computer via the usb port with would be sending the commands over my house wiring.

Tom j.
Logged

dave w

  • Community Organizer
  • Hero Member
  • ***
  • Helpful Post Rating: 136
  • Posts: 5955
Re: Dimming & brightening Commands From Software
« Reply #27 on: August 25, 2008, 12:41:24 PM »

With that setup the repeater wouldn't have any effect on me trying to adjust my dim levels from the software would it??
What repeater are you talking about?

If you have the X10 Pro (XPCR) or Leviton PLC repeater(s) Sure it would. The DIMS go through the house wiring, so the repeater would be repeating the sequence and coupling to the other phase. The Leviton and X10 Pro units are notorious for having, or creating problems with DIM and BRI commands.

If you are talking about the SR731 RF repeater, then no, it would only effect DIM or BRI commands from a RF remote like Palm Pad.

As suggested before; disable your repeater and see if you still have the problem.

Logged
"This aftershave makes me look fat"

Boiler

  • Guest
Re: Dimming & brightening Commands From Software
« Reply #28 on: August 25, 2008, 05:48:13 PM »

Tom,

I apologize - I missed your previous post.

Dave W makes an excellent point - the repeater that we have been referring to is an Active Repeater wired across the phases of your load panel (sometimes referred to as an "Active phase coupler").  I was not referring to a RF repeater.

When using Dim (or bright commands) Active repeaters (phase couplers) appear to confuse AHP.  This can sometimes lead to AHP brightening a lamp when you tell it to dim.

If you have an active repeater (phase coupler), disable it and retry your Dim command test.



Logged

tom j

  • Hero Member
  • *****
  • Helpful Post Rating: 16
  • Posts: 1270
Re: Dimming & brightening Commands From Software
« Reply #29 on: August 26, 2008, 10:13:12 PM »

Tom,

I apologize - I missed your previous post.

Dave W makes an excellent point - the repeater that we have been referring to is an Active Repeater wired across the phases of your load panel (sometimes referred to as an "Active phase coupler").  I was not referring to a RF repeater.

When using Dim (or bright commands) Active repeaters (phase couplers) appear to confuse AHP.  This can sometimes lead to AHP brightening a lamp when you tell it to dim.

If you have an active repeater (phase coupler), disable it and retry your Dim command test.





Ooh I see!!! I thought you guys were talking about a RF Repeater. Thanks Boiler!!! Yes I do have a active coupler it's made by Leviton a HCA02-10E  please see link below so you think this might be causing the problem hmm guess I could try to temporarily disable it take a look at the one I have  and tell me what you think. WOW!!! I didn't know that.


http://www.smarthome.com/4823.html

Tom j.


 #:)    :)+
« Last Edit: August 26, 2008, 11:27:57 PM by tom j »
Logged
Pages: 1 [2] 3
 

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