Announcement

Collapse
No announcement yet.

z-wave polling causing events to trigger even when state doesn't change

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

    z-wave polling causing events to trigger even when state doesn't change

    Problem - it appears that when a z-wave device polls, it seems to be triggering events that have that device as a trigger with "This device just had its value set or changed", even if the device's value hasn't changed, and "Do not update device last change time if device value does not change" is set.

    Background - To try to make a longer story a bit shorter, I happened to notice one day that my events that trigger a script to syncronize some cooper light switches with their slaves had started firing every 5 minutes. Upon closer inspection I noticed that also another event that triggers whenever one of the lights changes state (to update a status LED for the floor) was also firing at the same time.

    After doing a bunch of investigation I was able to narrow down the following:

    - The events are getting triggered anytime a z-wave device gets polled, regardless of whether or not the device's state changes
    - The devices all have "Do not update device last change time..." set
    - I have observed that the last change time is indeed not changing when the device is polled
    - It is not manufacturer specific - I tested this on another switch by a different manufacturer and indeed the event gets triggered

    I suspect I could probably change the event to trigger on "This device has a value that just changed", but rather than working around the problem I'd rather try to understand the root problem and make sure it's not something in my environment.

    To me it smells of a bug, especially as I'm **relatively** sure that it didn't used to exhibit this behaviour, though I couldn't tell you when the behaviour started. Anyone else seen this or have any ideas about it? I would like to keep polling on for these devices as once in awhile they do get out of sync with what state HS thinks they're in. But I'd just assume both not fill up the log with unnecessary stuff, and don't really want the events firing unnecessarily.

    regards,

    Paul

    #2
    What version of HomeSeer are you running?

    There are literately tens of thousands, maybe even hundreds of thousands z-wave devices out there in use with HomeSeer. "This device just had its value set or changed" is a fairly commonly used trigger condition. I am not doubting this is happening to you, but If this were really a bug something of this magnitude would probably have been discovered.

    You might want to open a support ticket with HomeSeer.

    Comment


      #3
      Originally posted by paul View Post
      Problem - it appears that when a z-wave device polls, it seems to be triggering events that have that device as a trigger with "This device just had its value set or changed", even if the device's value hasn't changed, and "Do not update device last change time if device value does not change" is set.
      The trigger 'This device just had its value set or changed' will trigger every time a device value has been set whether or not it has changed. The clue is in the description.

      If you want to only trigger when the value changes use the trigger:

      'This Device Has a Value that Just Changed'

      Steve

      EDIT
      On re-reading your post I think I missed that you were saying that you think that the behaviour when polling is different. As far as I am aware polling has always set the value, so would always cause this trigger to fire.

      Comment


        #4
        Originally posted by drhtmal View Post
        What version of HomeSeer are you running?

        There are literately tens of thousands, maybe even hundreds of thousands z-wave devices out there in use with HomeSeer. "This device just had its value set or changed" is a fairly commonly used trigger condition. I am not doubting this is happening to you, but If this were really a bug something of this magnitude would probably have been discovered.

        You might want to open a support ticket with HomeSeer.
        I'm running HS3 Pro Edition 3.0.0.548 on Windows, with the z-wave plugin 3.0.2.0. I'm not sure this is something worth opening a ticket for with Homeseer, since I know support is run off their feet, this isn't exactly an overwhelming issue for me (just an annoyance), and I usually get faster support in the forums anyways :P

        Comment


          #5
          Originally posted by SteveMSJ View Post

          The trigger 'This device just had its value set or changed' will trigger every time a device value has been set whether or not it has changed. The clue is in the description.

          If you want to only trigger when the value changes use the trigger:

          'This Device Has a Value that Just Changed'

          Steve

          EDIT
          On re-reading your post I think I missed that you were saying that you think that the behaviour when polling is different. As far as I am aware polling has always set the value, so would always cause this trigger to fire.
          Indeed, though I'm pretty certain this behaviour hasn't always been this way (not 100% confident of that). Additionally, the polling isn't actually setting the value (at least not visibly). "Do not update device last change time..." is checked, and when the poll takes place, the timestamp does not change. So if it is setting the value, it's not updating the timestamp that to say it has done so.

          At the end of the day, I probably can just change the trigger. But I figured I'd see if anyone else has seen this behaviour before doing so...

          Paul

          Comment


            #6
            Originally posted by paul View Post

            Indeed, though I'm pretty certain this behaviour hasn't always been this way (not 100% confident of that). Additionally, the polling isn't actually setting the value (at least not visibly). "Do not update device last change time..." is checked, and when the poll takes place, the timestamp does not change. So if it is setting the value, it's not updating the timestamp that to say it has done so.

            At the end of the day, I probably can just change the trigger. But I figured I'd see if anyone else has seen this behaviour before doing so...

            Paul
            Shouldn't the "Do not update. .." be unchecked if you are expecting the timestamp to update when the device is set even though it hasn't changed?

            When you poll a device you are instructing the plug-in that owns the device to query the physical device and set the value of the device in HS representing the status. I'm pretty sure this has always caused a Set Device to trigger. However, I've been wrong before

            ​​​​Steve

            Comment


              #7
              Originally posted by SteveMSJ View Post

              Shouldn't the "Do not update. .." be unchecked if you are expecting the timestamp to update when the device is set even though it hasn't changed?

              When you poll a device you are instructing the plug-in that owns the device to query the physical device and set the value of the device in HS representing the status. I'm pretty sure this has always caused a Set Device to trigger. However, I've been wrong before

              ​​​​Steve
              You are correct, which is why i have the checkbox checked. I do not want any sort of update unless the device has changed. But what I'm saying is that if Polling is causing the device to update on every poll, the polling is not changing the timestamp. I would have thought that if polling was setting the device every poll, it should also be updating the timestamp. I also thought that the Device is Set or Changed trigger would have only triggered if that timestamp changed.

              I'm not confident that this is behaviour that has changed, it's possible that I just didn't notice it before in the log noise. But i **think** it's behaviour that changed. if I'm wrong on that, that's cool, just trying to get clarity and see if anyone else experienced it.



              regards,

              Paul

              Comment


                #8
                Originally posted by paul View Post

                You are correct, which is why i have the checkbox checked. I do not want any sort of update unless the device has changed. But what I'm saying is that if Polling is causing the device to update on every poll, the polling is not changing the timestamp. I would have thought that if polling was setting the device every poll, it should also be updating the timestamp. I also thought that the Device is Set or Changed trigger would have only triggered if that timestamp changed.
                I think you are misunderstanding. Whether the timestamp changes is irrelevant to the trigger. The trigger is the device value being set. When you poll the device it sets the value and that fires the trigger. If the value is set but hasn't changed then the timestamp will only update if the option is unchecked.

                Steve
                ​​​​

                Comment


                  #9
                  Originally posted by SteveMSJ View Post

                  I think you are misunderstanding. Whether the timestamp changes is irrelevant to the trigger. The trigger is the device value being set. When you poll the device it sets the value and that fires the trigger. If the value is set but hasn't changed then the timestamp will only update if the option is unchecked.

                  Steve
                  ​​​​
                  Indeed in that case I was misunderstanding. My belief was that the time stamp was one of the things used to determine if a device value had been updated even when the value didn’t change. And I’m pretty sure there are at least some triggers that are impacted by that time stamp changing and the checkbox being set. Now that I think of it, guess it’s more time related triggers that it impacts - ie. if a device has been set for at least x number of minutes.

                  If this trigger is considering the value updated regardless of whether that time stamp changes, then it makes sense as to why my event is getting triggered on every poll. That being the case I’ll just go ahead and change the trigger to only trigger on actual change...

                  Comment


                    #10
                    Originally posted by paul View Post
                    And I’m pretty sure there are at least some triggers that are impacted by that time stamp changing and the checkbox being set. Now that I think of it, guess it’s more time related triggers that it impacts - ie. if a device has been set for at least x number of minutes.
                    That’s correct👍

                    Comment


                      #11
                      Hmmm.... ok so further to this discussion, by changing my events to "changed and becomes..." for the trigger i've dramatically reduced the number of events being unnecessarily triggered. However I have one that is still firing. This is one that I had forgotten about and and disabled awhile ago due to this problem, and just tried re-enabling it to see if it solved it. But it didn't.

                      I have several z-wave deadbolts for which I created an event to let me know when someone locks or unlocks the door. It's being triggered based on "device changes and becomes..." And the "becomes" is set to "Any Value"

                      With this set, every time the device polls, the event triggered.

                      I changed the trigger to be "has a value that just changed". I didn't really need the "Any Value" because because this one will accomplish the same thing. When I made this changed, it stopped triggering on polls.

                      I recognize I'm splitting hairs here and the work around is completely satisfactory, but I still think there's a bug. There's no reason that "device changes and becomes..." should trigger on polls, and "has a value that just changed" doesn't. Also to be fair, there are bigger fish that I'd rather Homeseer fries than kill a bunch of time on this one given that changing the trigger works just fine. But I did think it was worth noting this in case it saves someone grief down the road...

                      regards,

                      Paul

                      Comment

                      Working...
                      X