Announcement

Collapse
No announcement yet.

How is X10 dimming supposed to be used?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    How is X10 dimming supposed to be used?

    I'm kind of new to HomeSeer (switched from heyu a little while ago) so forgive me if this is an obvious question, but -

    I have a standard XPD3-IW controlling half a dozen LED pot lights and yes, the LEDs are dimmable. Indeed local dimming with the XPD3 paddle works quite nicely, so that's not a problem. I've also got another XPD3 controlling some incandescent halogens and they display exactly the same behaviors.

    If I set the X10 module type to "Standard" then I can turn the lights on and off with the web UI, but if I drag the brightness slider nothing happens. The slider moves but the lights don't change. If I set the slider to, say, 20% and then turn the lights off and back on, then NOW the lights are dimmed but the slider has gone back to 100%!

    Setting the module type to "PreSet" doesn't seem to change the behavior any.

    Setting it to "extended" improves the situation a bit - now if I drag the slider the lights will change brightness in real time. BUT it still has the problem that if I dim the lights, turn them off and then back on, the XPD3 remembers the last dim level but the slider goes back to 100%.

    What's the difference between Standard, PreSet and Extended modules? Which one is the correct setting for am XPD3?

    And what's the correct way to dim lights in HS3 so that everything works in real time AND stays in sync? How can I turn the lights on and have them go to a specific brightness level?

    Thanks

    #2
    For the XPD3 switches you will want to use a device type of "Standard." Device Type refers to the type of dimming protocol the switch uses, and the XPD3 devices do not use the "PreSet" dim or "Extended" Dim protocols. Also note that these switches cannot report their status back to HS so if they are changed locally HS will not know.

    Here is a link to the user guide for the XPD3 switch: http://www.authinx.com/manuals/X10/XPD3.pdf

    Note that the XPD3 devices incorporate a feature called "Resume Dim" and here is a excerpt from manual:
    Dimming from ON - Press and hold to achieve the dim level desired then release. When released, the direction of dimming is toggled, (i.e. next press and hold will cause the switch to brighten). A short paddle press from any dimmed level will fade off the Switch. A dimmed Switch will resume the level of intensity when turned back on (i.e. if dimmed to 50% then turned off, the Switch will resume at 50% when turned back on).

    Note: If you would like the Switch to always resume full intensity when turned on, then press and hold the paddle until the Switch attains full brightness before releasing. Then a short paddle press will fade off. Additionally, any X10 Controller can remotely operate the full functions of the Switch.
    This means that the switch will always return to the last dim level when commanded with "ON." This is the same behavior as the WS467 dimmers and you might read this post for more info: https://forums.homeseer.com/showthread.php?t=189866 In order to turn one of these dimmers on to 100% reliably you'll need to dim it to 99%.

    I'm not sure why you can send on/off commands to the switches but not dims. Please provide some info about your setup, specifically: operating system (Windows or Linux), HS3 version, X10 plugin version, X10 interface (CM11a, Ti103, CM15a, etc.). Also be sure that you are running the latest version of the plugin, which can be found here: https://forums.homeseer.com/showthread.php?t=185551 With the latest plugin, please enable Developer Mode (on the Manage Plugins page) and restart the plugin. This will provide a lot of debug info in the HS3 log, and posting those log entries here will help us understand what the issue might be.
    Best regards,
    -Mark-

    If you're not out on the edge, you're taking up too much room!
    Interested in 3D maps? Check out my company site: Solid Terrain Modeling

    Comment


      #3
      Originally posted by mfisher View Post
      the switch will always return to the last dim level
      Thanks - I had forgotten that. You can see that behavior locally just by tapping the paddle to turn it on. But knowing that's the way the module works, why doesn't HS (or the X10 plug in) remember the last level and set the slider to that value when I turn the module on? HS always sets the brightness slider to 100%.

      Originally posted by mfisher View Post
      Please provide some info ...
      HS3 Standard Edition 3.0.0.326 (Linux)
      X10 plugin 3.0.0.36
      CM11A

      After playing with it some more, I find that dimming does actually work with the module type set to "Standard" but it's really slow. It takes around 10 seconds between the time I drag the brightness slider and the time the lights actually respond. OTOH, with the module type set to "Extended" the response is nearly immediate.

      I notice that the exchange between the X10 plugin and the CM11 is MUCH shorter for the "extended" module than for "standard", even though both seem to produce the same result in the end. Is there any documentation on the X10 plugin regarding which X10 commands it actually sends ?

      I also notice the timeout warnings in the "standard" mode, but I don't know what the plug in is sending to the CM11 or what response it's expecting. Empirically, the CM11 works and it's interesting to note that in "extended" mode these timeouts don't happen.

      WITH MODULE TYPE SET TO STANDARD
      06:40:25:6195:[Device Control]->Device: X10 Living Room Lights to Brightness (value)% (25) by/from: CAPI Control Handler
      06:40:25:6584:[X10 DEBUG]->CM11A Sending: 4 92 Size: 2
      06:40:25:6814:[X10 DEBUG]->CM11A Got checksum: 96
      06:40:25:6839:[X10 DEBUG]->CM11A Checksum OK, sending 0
      06:40:26:1413:[X10 DEBUG]->CM11A Got ack of: 55
      06:40:26:1436:[X10 DEBUG]->CM11A Sending: B6 95 Size: 2
      06:40:26:1650:[X10 DEBUG]->CM11A Got checksum: 4B
      06:40:26:1672:[X10 DEBUG]->CM11A Checksum OK, sending 0
      06:40:28:0154:[X10 WARNING]->CM11A Possible no response to send data, still waiting
      06:40:30:2940:[X10 DEBUG]->CM11A Got ack of: 55
      06:40:30:2965:[X10 DEBUG]->CM11A Sending: 4 92 Size: 2
      06:40:30:3170:[X10 DEBUG]->CM11A Got checksum: 96
      06:40:30:3191:[X10 DEBUG]->CM11A Checksum OK, sending 0
      06:40:30:7755:[X10 DEBUG]->CM11A Got ack of: 55
      06:40:30:7780:[X10 DEBUG]->CM11A Sending: 86 94 Size: 2
      06:40:30:8017:[X10 DEBUG]->CM11A Got checksum: 1A
      06:40:30:8037:[X10 DEBUG]->CM11A Checksum OK, sending 0
      06:40:33:0127:[X10 WARNING]->CM11A Possible no response to send data, still waiting
      06:40:33:8219:[X10 DEBUG]->CM11A Got ack of: 55

      WITH MODULE TYPE SET TO EXTENDED
      06:42:01:3552:[Device Control]->Device: X10 Living Room Lights to Brightness (value)% (24) by/from: CAPI Control Handler
      06:42:01:3923:[X10 DEBUG]->CM11A Sending: 7 97 Size: 5
      06:42:01:4223:[X10 DEBUG]->CM11A Got checksum: E0
      06:42:01:4244:[X10 DEBUG]->CM11A Checksum OK, sending 0
      06:42:02:5474:[X10 DEBUG]->CM11A Got ack of: 55

      Comment


        #4
        Resume Dim is not a standard feature for most X10 devices and why the plugin doesn't handle these as you are expecting. While not a perfect solution, commanding a dim level of 99% instead of an ON command should resolve this for you.

        It appears that I was incorrect when I stated that the XPD3 does not utilize the 'Extended Dim' protocol as you have shown that it does - sorry about that!

        I see that you are running v.36 of the plugin and you will want to install the current Beta version as many bugs have been addressed and a lot of CM11a debugging info has been added.

        Based on the log snippet you provided it appears you have a noisy X10 environment. This line in your log file:
        Code:
        06:40:28:0154:[X10 WARNING]->CM11A Possible no response to send data, still waiting
        indicates that the CM11a is having to continually retry its transmission due to noise on your power line and the plugin is waiting for it to respond with an acknowledgement that the last transmission was successful. In fact you can see the delay in your log:
        Code:
        06:40:26:1672:[X10 DEBUG]->CM11A Checksum OK, sending 0
        06:40:28:0154:[X10 WARNING]->CM11A Possible no response to send data, still waiting
        06:40:30:2940:[X10 DEBUG]->CM11A Got ack of: 55
        • At 06:40:26 the plugin asks the CM11a to transmit the dim packet
        • At 06:40:28 the plugin warns that it is still waiting for an ACK (which should have happened within a second)
        • At 06:40:30 the plugin receives the ACK

        So this single dim packet took 4 seconds to get through and many of these need to be sent when using 'Standard' dimming.

        As mentioned above the newer plugin version includes a lot of debug detail regarding this very issue.

        The reason that 'Standard' dimming seems so slow vs 'Extended' dimming is that standard dimming sends a continuous stream of Dim or Brt commands on the power line until the desired dim level is reached. This can be several seconds and if there is noise on your power line the CM11a will try to resend every packet that is corrupted, which means the dim time becomes significantly longer (as you have witnessed). Extended dim sends one dim command instead of a stream of dim commands and why it works immediately.

        If you want your X10 system to be at all reliable I would strongly suggest that you begin looking into reducing or eliminating the noise on your power line.
        Best regards,
        -Mark-

        If you're not out on the edge, you're taking up too much room!
        Interested in 3D maps? Check out my company site: Solid Terrain Modeling

        Comment


          #5
          Originally posted by mfisher View Post
          you have a noisy X10 environment
          Ok, time to get out the XTBM and check. It wasn't noisy before, but plugging in just about any little old thing can change that.

          Thanks

          Comment


            #6
            Originally posted by gizmos View Post
            Ok, time to get out the XTBM and check. It wasn't noisy before, but plugging in just about any little old thing can change that.
            Jeff's XTB-232 is also worth considering. It emulates a CM11, but with more power. It can help overcome moderate line noise.
            Mike____________________________________________________________ __________________
            HS3 Pro Edition 3.0.0.548, NUC i3

            HW: Stargate | NX8e | CAV6.6 | Squeezebox | PCS | WGL 800RF | RFXCOM | Vantage Pro | Green-Eye | Edgeport/8 | Way2Call | Ecobee3 | EtherRain | Ubiquiti

            Comment


              #7
              Originally posted by Uncle Michael View Post
              It can help overcome moderate line noise.
              I have one of his repeaters (XTBR-II, I think) already, and two of his active filters (one for each 220 leg). I'm assuming (hoping!) that's as good.

              Comment


                #8
                Probably better.

                With the meter you'll locate the culprit(s) pretty quickly. I have a TV that has to have a blocking filter or I'm out of business and a LV light fixture that is still a minor nuisance even with a filter. (Plugging the CM11 as close as possible to the XTB-IIR may also help.)
                Mike____________________________________________________________ __________________
                HS3 Pro Edition 3.0.0.548, NUC i3

                HW: Stargate | NX8e | CAV6.6 | Squeezebox | PCS | WGL 800RF | RFXCOM | Vantage Pro | Green-Eye | Edgeport/8 | Way2Call | Ecobee3 | EtherRain | Ubiquiti

                Comment

                Working...
                X