Announcement

Collapse
No announcement yet.

Firmware Feature requests for HS Switches/Dimmers

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

    #31
    But the dimmers work like this now? Sure, they attempt to control a load, but you can just cap that off. Then it works as you have described. You can have HS set the dim level to anything you want (which sets the leds). 2 taps on the top turns on the first 2 LEDS, 3, turns on 3, 1 tap on the bottom turns on just one LED as a night light, or whatever you want.

    Originally posted by jamesk View Post
    Excellent idea!
    💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

    Comment


      #32
      Apologies if this was asked above, but it would be wonderful if the HS-WD100+ supported passing the step/ramp rate at the time of executing a command. Is it a limitation of Z-Wave that the device can only have the singular local and remote step/ramp values?

      For example I'd like to have events that can speed up or slow down the dimming effect...

      "On triple up tap, turn on kitchen island dimmer to ON with 99 step and timer 1." <-- Trying to go to ON state as fast as possible to mimic the HS-WS100+ behavior.

      "On double up tap, turn on kitchen island dimmer to 50% with 1 step and timer 3."

      "On double up tap, turn on kitchen island dimmer to 50% with 1 step and timer 1."


      Or simplify the event input to be something like...

      "On double up tap, turn on kitchen island dimmer to 50% over 3 seconds."


      Now that last one obviously is problematic if the light isn't in an OFF or ON state when the event fires and is somewhere in between. You'd have to decide if the system would adjust it from its existing value to 50% over 3 seconds, or calculate behind the scenes what speed it would be based on a full OFF or ON state and go with that for normalization.

      Comment


        #33
        In the z-wave actions for an event you can set the parameters on the device. So in your event, you could first set the parameters to the ramp rate you want, then send the command.

        Originally posted by scorp508 View Post
        Apologies if this was asked above, but it would be wonderful if the HS-WD100+ supported passing the step/ramp rate at the time of executing a command. Is it a limitation of Z-Wave that the device can only have the singular local and remote step/ramp values?

        For example I'd like to have events that can speed up or slow down the dimming effect...

        "On triple up tap, turn on kitchen island dimmer to ON with 99 step and timer 1." <-- Trying to go to ON state as fast as possible to mimic the HS-WS100+ behavior.

        "On double up tap, turn on kitchen island dimmer to 50% with 1 step and timer 3."

        "On double up tap, turn on kitchen island dimmer to 50% with 1 step and timer 1."


        Or simplify the event input to be something like...

        "On double up tap, turn on kitchen island dimmer to 50% over 3 seconds."


        Now that last one obviously is problematic if the light isn't in an OFF or ON state when the event fires and is somewhere in between. You'd have to decide if the system would adjust it from its existing value to 50% over 3 seconds, or calculate behind the scenes what speed it would be based on a full OFF or ON state and go with that for normalization.
        💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

        Comment


          #34
          Originally posted by rjh View Post
          In the z-wave actions for an event you can set the parameters on the device. So in your event, you could first set the parameters to the ramp rate you want, then send the command.
          Thanks for pointing this out! Is that a persistent config change for remaining events that flow through the device so you'd have to get in the habit of sending them for all events, or will it be used immediately one time and return to what it was before?


          Saving a different ramp rate values in the device management takes ~5 seconds after clicking set to return the UI refresh. I'll try to play with it later today to see how it reacts in real life through an event. My hope is it doesn't introduce a 5 second delay between an event firing and the device action taking place during the time the ramp rate is set. There may be more than 1 device within your periphery vision and if the delays stack up it could make a scene a bit jerky.

          Comment


            #35
            I tried to sniff the parameter # associated with the setting so I could try and event, but in debug logging it appears only the friendly name is shown on the line of the actual value being set.

            Or it is staring me right in the face and I don't know what to look for.

            6/5/2017_1:27:10 PM HomeSeer reports a change for 1st Dining Light - Table - Multi-Level of: Status_Support (Type=3)
            6/5/2017_1:27:18 PM HomeSeer reports a change for 1st Dining Light - Table - Multi-Level of: Status_Support (Type=3)
            6/5/2017_1:27:19 PM set_dimrate_local: Secondary K/V is local_step=2
            6/5/2017_1:27:20 PM SETTING NON-SCENE DEVICE CONFIGURATION TO 1st Dining Light - Table - Multi-Level VALUE 2

            6/5/2017_1:27:20 PM Z-Stick: Attempt 0 sending to node 18 (UnSecured)
            6/5/2017_1:27:20 PM FuncStatusReturn for ZW_SEND_DATA: STATUS set to 63
            6/5/2017_1:27:20 PM Z-Stick ENTERING WaitForFinish (ZW_SEND_DATA/73 of ZWaveAPIThreadProc) with ZW_SEND_DATA/73
            6/5/2017_1:27:20 PM Z-Stick ENTERING WaitForFinish (MASTER_Send_Data_REAL) with ZW_SEND_DATA/73
            6/5/2017_1:27:20 PM Z-Stick: FRAME BEING PLACED IN FramesQ!
            6/5/2017_1:27:20 PM Z-Stick: PROCESSING - RESPONSE - Frame
            6/5/2017_1:27:20 PM Process response frame
            6/5/2017_1:27:20 PM Z-Stick: RESPONSE: ZW_SEND_DATA, Frame=04-01-13-01-E8
            6/5/2017_1:27:20 PM Z-Stick: FRAME BEING PLACED IN FramesQ!
            6/5/2017_1:27:20 PM FuncStatusReturn for ZW_SEND_DATA: RETURN set to 1
            6/5/2017_1:27:20 PM Z-Stick: PROCESSING - REQUEST - Frame
            6/5/2017_1:27:20 PM ProcessFrame_STATUS from interface 1 (Z-Stick) Type: ZW_SEND_DATA, Length: 6, Frame=05-00-13-49-00-A0
            6/5/2017_1:27:20 PM Z-Stick: REQUEST: ZW_SEND_DATA, Frame=05-00-13-49-00-A0
            6/5/2017_1:27:20 PM FuncStatusReturn for ZW_SEND_DATA: STATUS set to 0
            6/5/2017_1:27:20 PM SEND COMPLETE FOR 19/73
            6/5/2017_1:27:20 PM Z-Stick LEAVING WaitForFinish TRUE (ZW_SEND_DATA/73 of ZWaveAPIThreadProc) with ZW_SEND_DATA/49
            6/5/2017_1:27:20 PM Z-Stick: MSDR Return: Node=18, Meta=False, Status: TRANSMIT_COMPLETE_OK
            6/5/2017_1:27:20 PM set_dimrate_local: Secondary K/V is local_timer=3
            6/5/2017_1:27:21 PM SETTING NON-SCENE DEVICE CONFIGURATION TO 1st Dining Light - Table - Multi-Level VALUE 3

            6/5/2017_1:27:21 PM Z-Stick: Attempt 0 sending to node 18 (UnSecured)
            6/5/2017_1:27:21 PM FuncStatusReturn for ZW_SEND_DATA: STATUS set to 63
            6/5/2017_1:27:21 PM Z-Stick ENTERING WaitForFinish (ZW_SEND_DATA/74 of ZWaveAPIThreadProc) with ZW_SEND_DATA/74
            6/5/2017_1:27:21 PM Z-Stick ENTERING WaitForFinish (MASTER_Send_Data_REAL) with ZW_SEND_DATA/74
            6/5/2017_1:27:21 PM Z-Stick: FRAME BEING PLACED IN FramesQ!
            6/5/2017_1:27:21 PM Z-Stick: PROCESSING - RESPONSE - Frame
            6/5/2017_1:27:21 PM Process response frame
            6/5/2017_1:27:21 PM Z-Stick: FRAME BEING PLACED IN FramesQ!
            6/5/2017_1:27:21 PM Z-Stick: RESPONSE: ZW_SEND_DATA, Frame=04-01-13-01-E8
            6/5/2017_1:27:21 PM FuncStatusReturn for ZW_SEND_DATA: RETURN set to 1
            6/5/2017_1:27:21 PM Z-Stick: PROCESSING - REQUEST - Frame
            6/5/2017_1:27:21 PM ProcessFrame_STATUS from interface 1 (Z-Stick) Type: ZW_SEND_DATA, Length: 6, Frame=05-00-13-4A-00-A3
            6/5/2017_1:27:21 PM Z-Stick: REQUEST: ZW_SEND_DATA, Frame=05-00-13-4A-00-A3
            6/5/2017_1:27:21 PM FuncStatusReturn for ZW_SEND_DATA: STATUS set to 0
            6/5/2017_1:27:21 PM Z-Stick LEAVING WaitForFinish TRUE (MASTER_Send_Data_REAL) with ZW_SEND_DATA/4A
            6/5/2017_1:27:21 PM SEND COMPLETE FOR 19/74
            6/5/2017_1:27:21 PM Z-Stick: MSDR Return: Node=18, Meta=False, Status: TRANSMIT_COMPLETE_OK

            Comment


              #36
              It will not take 5 seconds in an event. The Settings page goes out to get ALL the settings for display. In your case, you are just setting a parameter so each parameter is like turning ON a device. It should be pretty quick, but there will be a delay.

              Here are the parameters for our dimmer. Note that we have different dim values for local control and remote, so in your case, you only need to set the remote parameters, and probably just the timer. You can leave the step at a reasonable value.

              4 = switch reverse (switch and dimmer)
              0 = top on - default
              1 = bottom on

              3 = LED operation (switch only)
              0 = OFF if load is ON - default
              1 = OFF if load is OFF

              local control dim rate (dimmer only)
              9 = step (1-99)
              10 = timer (1-255)

              remote control dim rate (dimmer only)
              7 = step (1-99)
              8 = timer (1-255)

              Originally posted by scorp508 View Post
              Thanks for pointing this out! Is that a persistent config change for remaining events that flow through the device so you'd have to get in the habit of sending them for all events, or will it be used immediately one time and return to what it was before?


              Saving a different ramp rate values in the device management takes ~5 seconds after clicking set to return the UI refresh. I'll try to play with it later today to see how it reacts in real life through an event. My hope is it doesn't introduce a 5 second delay between an event firing and the device action taking place during the time the ramp rate is set. There may be more than 1 device within your periphery vision and if the delays stack up it could make a scene a bit jerky.
              💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

              Comment


                #37
                Thanks, I appreciate you sharing those. Time to play!

                Comment


                  #38
                  Can someone explain the actual meaning behind the step and timer values? I've played with them on GE switches before, but have never been able to make heads or tails of them. Why is it not a simple fade time setting in seconds?

                  Comment


                    #39
                    Originally posted by epimetheus View Post
                    Can someone explain the actual meaning behind the step and timer values? I've played with them on GE switches before, but have never been able to make heads or tails of them. Why is it not a simple fade time setting in seconds?

                    I suspect because the effect of a static fade time would result in really odd fade transitions based on where the dimmer was at the time of event execution. For example if it had one setting of "3 seconds" it would take 3 seconds to go from 0% to 100%, and also 3 seconds to go from 75% to 100%.
                    Last edited by scorp508; June 6, 2017, 03:11 PM.

                    Comment


                      #40
                      Originally posted by scorp508 View Post
                      I suspect because the effect of a static fade time would result in really fade transitions based on where the dimmer was at the time of event execution. For example if it had one setting of "3 seconds" it would take 3 seconds to go from 0% to 100%, and also 3 seconds to go from 75% to 100%.
                      Ok. I contend that's a whole lot easier to understand than this step and timer system. How do the number and steps and the (presumably) step timing relate to the actual fade time?

                      Comment


                        #41
                        Quadruple tap

                        It would be great to have quadruple tap support, if that is easy to add.

                        (I keep finding myself just one set of scenes shy of what i need in the bedrooms: shades open/close on double tap, heater on/off on triple tap, and no room for sleep/wake).

                        Thanks!

                        Comment


                          #42
                          Originally posted by Vodden View Post
                          A run of black devices would also be appreciated. I would change out every z-wave device in my house with these if I could get them in black. (40+). [emoji4]
                          You don't need a different switch/dimmer, HomeSeer just needs to make more color kits available.
                          Last edited by Timon; June 7, 2017, 11:06 AM.
                          HomeSeer Version: HS3 Standard Edition 3.0.0.548
                          Linux version: Linux auto 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
                          Number of Devices: 484 | Number of Events: 776

                          Enabled Plug-Ins: 3.0.0.13: AirplaySpeak | 2.0.61.0: BLBackup
                          3.0.0.70: EasyTrigger | 1.3.7006.42100: LiftMaster MyQ
                          4.2.3.0: mcsMQTT | 3.0.0.53: PHLocation2 | 0.0.0.47: Pushover 3P
                          3.0.0.16: RaspberryIO | 3.0.1.262: Z-Wave

                          Z-Net version: 1.0.23 for Inclusion Nodes
                          SmartStick+: 6.04 (ZDK 6.81.3) on Server

                          Comment


                            #43
                            I see a way that this "Could" be solved and done is a useful way for may conditions. Allow the paddle and the dimmer section be dissociated from each other. Then you could take two switches and cross them so the paddle on one controls the other. This would include the local timing options.

                            Originally posted by scorp508 View Post
                            I'd go for something like this as well. Our home has seen a couple additions/reconfigurations over the years before we purchased it. There are switches in locations that when originally built made perfect sense, but now that entrances and doors have been moved the locations are entirely confusing. For whatever reason the homeowners didn't have the wiring and switch locations updated when the additions took place.

                            For example I have a switch for flood lights on the front of the house in the middle of a random hallway nowhere near a an existing entry door. When originally built that area was the mudroom next to a door. There are a few examples like that scattered through the home. Another type are switches next to ceiling lights that don't control them, they control some other light elsewhere. Everyone hits the switch nearest the ceiling light thinking they operate the light above them. Nope.


                            I could spend a ton of time re-wiring things and extending lines with junction boxes in the attic or basement to make it all sensible again. I'd rather save hours of work having a device that looks/feels like a switch, but the paddle doesn't operate the local load. It turns into a remote controllable relay to keep operating the local load as I still need the ability to switch that load, but the paddle is independent so I can assign the most logically placed paddles to operate the nearest light.

                            Maybe there's some electrical code that prohibits this type of operation, I don't know and it wouldn't surprise me as it could provide a false sense of safety to someone who doesn't know how the home operates before working on a nearby fixture.
                            HomeSeer Version: HS3 Standard Edition 3.0.0.548
                            Linux version: Linux auto 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
                            Number of Devices: 484 | Number of Events: 776

                            Enabled Plug-Ins: 3.0.0.13: AirplaySpeak | 2.0.61.0: BLBackup
                            3.0.0.70: EasyTrigger | 1.3.7006.42100: LiftMaster MyQ
                            4.2.3.0: mcsMQTT | 3.0.0.53: PHLocation2 | 0.0.0.47: Pushover 3P
                            3.0.0.16: RaspberryIO | 3.0.1.262: Z-Wave

                            Z-Net version: 1.0.23 for Inclusion Nodes
                            SmartStick+: 6.04 (ZDK 6.81.3) on Server

                            Comment


                              #44
                              I +1 this especially the last part.
                              Originally posted by hoffsta View Post
                              Ok, I thought about it a little more. Here's my suggestion regarding using the HS-WS100+ as Scene Controllers only. I suggest a second, alternative firmware that runs on the same hardware but behaves completely differently, in that it has no internal 'on/off' state. It is simply a scene command sender. The LED could be set in the prefs to be a night light only or something.

                              The benefit to Homeseer is that you can market a third product, "Decora Scene Controller", which nobody else has. Hell, go crazy and offer additional 'double press+hold', 'triple press+hold'. Now you've got a 12 scene, Decora scene controller, the crowds will go nuts.

                              For me personally, this is a great product because I don't like having gaudy multi-button monstrosities cluttering my walls. I want my home automation stuff to as stealth as possible.

                              You get a third product to market and you don't even have to order/stock a different product from your vendor. Make the firmware available to existing owners so we can convert our switches to whichever one we want. Or maybe down the road, you find it's cheaper to order some without the relay and outbound AC parts and can get a slightly higher per unit margin than you do now.

                              What do you think?
                              HomeSeer Version: HS3 Standard Edition 3.0.0.548
                              Linux version: Linux auto 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
                              Number of Devices: 484 | Number of Events: 776

                              Enabled Plug-Ins: 3.0.0.13: AirplaySpeak | 2.0.61.0: BLBackup
                              3.0.0.70: EasyTrigger | 1.3.7006.42100: LiftMaster MyQ
                              4.2.3.0: mcsMQTT | 3.0.0.53: PHLocation2 | 0.0.0.47: Pushover 3P
                              3.0.0.16: RaspberryIO | 3.0.1.262: Z-Wave

                              Z-Net version: 1.0.23 for Inclusion Nodes
                              SmartStick+: 6.04 (ZDK 6.81.3) on Server

                              Comment


                                #45
                                Originally posted by Timon View Post
                                You don't need a different switch/dimmer, HomeSeer just needs to make more color kits available.
                                Yeah I knew that, but they haven't done it yet....

                                Comment

                                Working...
                                X