Announcement

Collapse
No announcement yet.

Firmware Feature requests for HS Switches/Dimmers

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

  • Could be a user using the key release to trigger an event and this change would slow that down significantly, especially for slow ramp rates, so they would be broken. So these types of changes always have ramifications. We will take it under advisement though. I REALLY don't like using a feature to fix something that it was not intended for. There should not be a link between central scene and the device load control.

    Might be better to add some event trigger logic so you know for sure that the device value was changed locally at the paddle (HS knows this). That would fix the issue the correct way.

    In any event, we are finishing testing on the current round of changes so this will have to wait for the next round.

    Originally posted by SeattleDavid View Post

    It would certainly be cleaner and easier for everybody if this change were made. It seems that a number of people have run into this issue.

    This is a change which only makes logical sense, with no downside, and countless hours of grief by many people saved. It almost seems like a no-brainer type of change to make.

    It is remarkably difficult in HomeSeer to NOT use the Key Released Central Scene. Given that the Multilevel value of the light could be changed by many possible sources, it would be difficult to create logic for each and every one of those to somehow indicate that they were changing the multilevel, rather than the user. It would require adding logic everywhere, and it would be a mess to maintain.

    On the other hand, with the change made there would be no logic required, and it would "Just Work". It would work without race conditions and infinite loops, and without hours of debugging (which it is clear others have gone through as well as myself.)

    HomeSeer is (of course) perfectly entitled to build great products or pseudo-buggy products as it chooses. But I think it would be good to aspire to products that were great, and that were a joy to use, and that behaved predictably and without gotchas.

    The HS-WD-200 is otherwise just an outstanding product. It has great features, good plastics, wonderful functionality, and it is heads above other ZWave Switches. But it odes have this one rather ugly flaw.

    website | buy now | support | youtube

    Comment


    • I don't understand why this discussion of ramp rates keeps coming up. I see no connection between ramp rates and this. The finger goes down on the button, the LEDs change, the finger lifts, and always, always, always the multilevel value is the current one. It doesn't matter what the ramp rate is. When the finger lifts, this is the value.

      You mentioned that "Might be better to add some event trigger logic so you know for sure that the device value was changed locally at the paddle (HS knows this)"...

      How does HS know this, or more specifically, how can my event know this?

      What i am really trying to accomplish is to trigger an event when the user (and not some other event) has changed the multilevel. Any way of easily accomplishing that would solve the problem. But nobody has suggested any way to actually do this without unreliable waits, delays, and having to fiddle with global variables in every event that might potentially change the multilevel value.

      Comment


      • Say you have the ramp rate set to 5 seconds. The dimmer will not report the level to HS until the ramp rate finishes, so 5 seconds later. That is why the ramp rate is important. When the dimmer finishes ramping up/down the load it sends a z-wave multilevel report to HS. If HS sees this report it knows the dimmer was controlled. It does not send this report if its controlled remotely. (at least I am pretty sure it doesn't, need to double check that). So when HS sees this it can be certain it was from a local control.

        Right now though there isn't any way to trigger on this, so that is what I propose we add to the software.

        Originally posted by SeattleDavid View Post
        I don't understand why this discussion of ramp rates keeps coming up. I see no connection between ramp rates and this. The finger goes down on the button, the LEDs change, the finger lifts, and always, always, always the multilevel value is the current one. It doesn't matter what the ramp rate is. When the finger lifts, this is the value.

        You mentioned that "Might be better to add some event trigger logic so you know for sure that the device value was changed locally at the paddle (HS knows this)"...

        How does HS know this, or more specifically, how can my event know this?

        What i am really trying to accomplish is to trigger an event when the user (and not some other event) has changed the multilevel. Any way of easily accomplishing that would solve the problem. But nobody has suggested any way to actually do this without unreliable waits, delays, and having to fiddle with global variables in every event that might potentially change the multilevel value.
        website | buy now | support | youtube

        Comment


        • Originally posted by rjh View Post
          Say you have the ramp rate set to 5 seconds. The dimmer will not report the level to HS until the ramp rate finishes, so 5 seconds later. That is why the ramp rate is important. When the dimmer finishes ramping up/down the load it sends a z-wave multilevel report to HS. If HS sees this report it knows the dimmer was controlled. It does not send this report if its controlled remotely. (at least I am pretty sure it doesn't, need to double check that). So when HS sees this it can be certain it was from a local control.

          Right now though there isn't any way to trigger on this, so that is what I propose we add to the software.


          Regardless of the specific needs being discussed in this topic - It would be invaluable if there was a way to know a Z-Wave device was controlled locally versus by HomeSeer device control. If that could be accomplished, it would answer something we have been begging for since I started with HomeSeer in 2014.
          Last edited by rprade; November 19th, 2018, 11:45 PM.
          Randy Prade
          Aurora, CO
          Prades.net

          PHLocation - Pushover - EasyTrigger - UltraECM3 - Ultra1Wire3 - Arduino

          Comment


          • “Right now though there isn't any way to trigger on this, so that is what I propose we add to the software.”

            ”it would be invaluable”

            I am indifferent of how it is implemented. It would be enormously valuable to be able to differentiate between local and remote changes. One way to accomplish this for HS-WD200 Devices is to send the Multivalue Value before the Button Release. But if there is another way, then OK.

            What is needed is a way to differentiate local changes from remote ones. This is especially problematic for multilevel changes..

            Comment


            • As someone who uses WD200s to control other loads not directly wired to the dimmer, and who has no load wired to the dimmer, I'm groaning at the thought of anything that will add a delay to the central scene report, as these are what I rely on.

              Comment


              • Originally posted by Fellhahn View Post
                As someone who uses WD200s to control other loads not directly wired to the dimmer, and who has no load wired to the dimmer, I'm groaning at the thought of anything that will add a delay to the central scene report, as these are what I rely on.
                There must be a slight delay in the Central Scene, due to the fact it must count to 5, or know you stopped at 2. I think what is being discussed is sending the multilevel report prior to the key released scene which should only affect the one scene. I'm not clear if it is even being considered.
                Randy Prade
                Aurora, CO
                Prades.net

                PHLocation - Pushover - EasyTrigger - UltraECM3 - Ultra1Wire3 - Arduino

                Comment

                Working...
                X