Announcement

Collapse
No announcement yet.

Firmware Feature requests for HS Switches/Dimmers

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

    #91
    Yes, we added this. We have a bug that causes the node ID to get reset when you update the firmware, so we are trying to get that worked out before we release it. It allows you to control other devices directly, and use other WX200 switches as companions.

    Originally posted by Fellhahn View Post
    Is it ever likely the 200 series dimmers/switches could support BASIC and SWITCH_MULTILEVEL in their controlled classes?
    I think this would probably require a separate association group?

    Currently adding another switch device to the HS-WD200's association group does not result in control of the other switching device. Control can only be achieved through events/device linking via the HomeSeer controller. That means loss of lighting control in a server outage.

    I'm new to Z-Wave but from what I understand this is because the controlled classes of the WD200 only includes CENTRAL_SCENE.

    I'd really like this as a feature request but I've seen the comments in here already about limited code space.
    Other wall dimmers do do it, but those wall dimmers don't support status LEDs and quadruple/quintuple tap. So maybe there's only so much room.

    Reference my other thread here:

    https://forums.homeseer.com/showthread.php?t=196048
    💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

    Comment


      #92
      WooHoo! Thank you

      I don't mind the wait, just knowing it's coming is great news.


      Originally posted by rjh View Post
      Yes, we added this. We have a bug that causes the node ID to get reset when you update the firmware, so we are trying to get that worked out before we release it. It allows you to control other devices directly, and use other WX200 switches as companions.

      Comment


        #93
        Originally posted by rjh View Post
        we are trying to get that worked out before we release it. It allows you to control other devices directly, and use other WX200 switches as companions.
        To make sure I understand correctly, the new firmware will allow to use the switches as companions. Does this also mean we will have the highly requested option of disabling the internal relay? That feature will allow people who want to power smart bulbs with smart switches to provide power to the bulbs at all times without having to wire the switch as always hot.
        I'm deciding whether to buy into Homeseer switches for the whole house or to go with Inovelli because they support disabling the internal relay.

        Comment


          #94
          We have posted the new firmware for testing here:

          https://forums.homeseer.com/forum/ho...rmware-updates
          💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

          Comment


            #95
            Originally posted by rjh View Post
            We are looking at some changes to better control the LEDS, which will do what you want. Will post more when we finalize.
            I exchanged a few emails with support yesterday and it looks like this functionality has been abandoned for the WD100+. I'd love to see this put back onto a roadmap as it would be a great aesthetic improvement for the switch and a great feature that differentiates from the competition!

            RJH - Any chance of this happening or do I need to let it go? Thanks!

            Comment


              #96
              I had to go back through the forum to see what I was referring to there!

              This is in reference to disabling the LED's. Right now, no plans to make any changes to the WD100. Its out of code space due to the addition of S2 and SmartStart. That is why the 200 series is not getting SmartStart. We have more code space to work with.

              Originally posted by cocyclist View Post

              I exchanged a few emails with support yesterday and it looks like this functionality has been abandoned for the WD100+. I'd love to see this put back onto a roadmap as it would be a great aesthetic improvement for the switch and a great feature that differentiates from the competition!

              RJH - Any chance of this happening or do I need to let it go? Thanks!
              💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

              Comment


                #97
                If the 200 series is not getting SmartStart why is the 100 series?

                Comment


                  #98
                  Originally posted by rjh View Post
                  I had to go back through the forum to see what I was referring to there!

                  This is in reference to disabling the LED's. Right now, no plans to make any changes to the WD100. Its out of code space due to the addition of S2 and SmartStart. That is why the 200 series is not getting SmartStart. We have more code space to work with.
                  So does this mean the 100 series will not be receiving any more firmware updates / improvements? If so, this is really disconcerting, since firmware upgrades is a big reason I decided to invest a lot of money in the WD100 devices when they came out.

                  Comment


                    #99
                    Reasons beyond my control. I understand your concern and will note it.

                    Originally posted by teladog01 View Post

                    So does this mean the 100 series will not be receiving any more firmware updates / improvements? If so, this is really disconcerting, since firmware upgrades is a big reason I decided to invest a lot of money in the WD100 devices when they came out.
                    💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

                    Comment


                      There is a problem with the sequencing of messages from HS series switches.

                      Presently the Key Released event is sent from the switch BEFORE a Multilevel change message. The Multilevel change message should be BEFORE the Key Released message.

                      The problem...
                      By the switch sending the Scene 00x Key released event BEFORE the Multilevel Value a problem is created: You know that the Multilevel has changed, but you don't know what it was changed to. During the Scene 00x Key Released event you cannot yet read the multilevel value as it does not yet reflect the newly set value.

                      Because of this you cannot have an event that triggers upon a multilevel change AND know what the new Multilevel value is.


                      An example why this is important...
                      Sometimes a Multilevel level can be changed from several events, as well as from the switch directly. The HS application may want to know when the user has manually changed the Multilevel. The HS application doesn't want to know simply that the multilevel was changed somehow by something. The HS application wants to know that it was the user, manually. Thus, using a "Change or Set" event on the Multilevel won't work.

                      The perfect way to do this is to use the "Scene 00x Key Released" event. This way, you know it was the user doing the change. An event triggering on this will fire when the user manually changes the event, but not when other events change the Multilevel.

                      The ability to know a change was done manually, locally, is really important because it eliminates a common cause for infinite loops when two switches are interacting with each other.

                      Right now, there is no way to update a separate lamp module when the switch's multilevel is changed manually.

                      Possible solutions...
                      1. [*=1]The switch should transmit Scene 00x Key Released messages AFTER sending the Multilevel value message. This way, the user can read the multilevel value in the Scene 00x Key released event. There is really no advantage or good thing that comes from sending the Multilevel Value AFTER the Key released. Or, [*=1]A new Central Scene event could be sent that indicates a multilevel value change. Thus, a user that was interested in firing an event after the Multilevel changed by manual operation (as opposed to programmatically) could trigger an event upon "Multilevel Change". This is somewhat analogous to the way the switch now [wonderfully] operates with ON and OFF. You can have an event fire using "Scene 001 Pressed 1 times" to know that the device was manually turned off, as opposed to just being programmatically turned off by another event.

                      Comment


                        The only issue I see is that the physical light will still be changing so the key release would be delayed unless you send what the light is being changed to.

                        Other than Han that it makes sense.
                        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


                          Originally posted by Timon View Post
                          The only issue I see is that the physical light will still be changing so the key release would be delayed unless you send what the light is being changed to.

                          Other than Han that it makes sense.
                          His point is, if you are adjusting the dim level locally, it is safe to assume that the level changing stops at the moment the top or bottom paddle is released. The physical light is not a factor, only the actual output of the HS-WD200. If the dimmer would send the new multilevel setting before the Central Scene, it would be easier to synchronize other dimmers with the one being controlled locally.

                          HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                          Comment


                            Actually, no, there is no problem at all with the physical light changing. This is because the user will be holding down the up/down paddle to select their desired brightness level and the light will be changing in real-time with the light. The sequence is:
                            1. User presses and hold the up/down button to start changing the brightness level.
                            2. The light begins dimming or brightening. The load and the switch LED lights change as the brightness changes.
                            3. The user releases the up/down button.
                            4. The new Multilevel value should be sent to HS
                            5. The Button Released event should be sent to HS
                            So the light is changing as the user holds down the button. Releasing the button establishes the new load level, and the dimming LED lights are already at the correct level. So there is no timing conflict as you have suggested.

                            Comment


                              Originally posted by rprade View Post
                              if you are adjusting the dim level locally, it is safe to assume that the level changing stops at the moment the top or bottom paddle is released.

                              The physical light is not a factor, only the actual output of the HS-WD200.

                              If the dimmer would send the new multilevel setting before the Central Scene, it would be easier to synchronize other dimmers with the one being controlled locally.
                              Yes, precisely, you understand correctly.

                              And, the status LEDs on the switch are always in sync with the light load, so there is no issue.

                              If the Key Released message happened AFTER the Multilevel Value, then the Key Released event could read the multilevel and could set other devices to that level. (Using EasyTrigger or otherwise.) The Key Released event would have access to the NEW multilevel value this way.

                              I can think of no good reason that the Key Released event should be sent BEFORE the multilevel value.

                              Sending the Multilevel Value BEFORE the Key Released message would allow the Multilevel to be set by other events and the Key Released could be used to know that a new multilevel value was set manually.

                              Comment


                                Originally posted by rprade View Post
                                His point is, if you are adjusting the dim level locally, it is safe to assume that the level changing stops at the moment the top or bottom paddle is released. The physical light is not a factor, only the actual output of the HS-WD200. If the dimmer would send the new multilevel setting before the Central Scene, it would be easier to synchronize other dimmers with the one being controlled locally.
                                I will also add that even if local ramping delays the load reaching the target when the paddle is released, the dimmer still could send the target value, since it will have been set.

                                HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                                Comment

                                Working...
                                X