Announcement

Collapse
No announcement yet.

Delays between sensor and event

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

    Delays between sensor and event

    Perhaps someone can point me in the right direction to minimize the delays between the time a z-wave sensor trigger is received and when the event is ran.

    Look at the snippet of my log and you will see that it took 12 seconds from the time HS3 received the sensor trigger and when the pantry light event ran.

    Thanks!

    Current Date/Time: 2/1/2018 2:27:30 PM
    HomeSeer Version: HS3 Pro Edition 3.0.0.398
    Operating System: Microsoft Windows 7 Ultimate - Work Station
    System Uptime: 0 Days 18 Hours 2 Minutes 31 Seconds
    IP Address: 192.168.0.2
    Number of Devices: 777
    Number of Events: 351
    Available Threads: 400
    HSTouch Enabled: True
    Event Threads: 1
    Event Trigger Eval Queue: 27
    Event Trigger Priority Eval Queue: 0
    Device Exec Queue: 0
    HSTouch Event Queue: 0
    Email Send Queue: 0
    Anti Virus Installed:

    Enabled Plug-Ins
    2.0.50.0: BLBackup
    2.0.76.0: BLLock
    1.0.3.0: BLShutdown
    3.1.1.24385: Blue-Iris
    2.0.22.0: BLUPS
    3.0.0.42: EasyTrigger
    3.6.5.0: Harmony Hub
    3.0.0.14: NetCAM
    2.1.6.0: OpenSprinkler
    3.0.1.109: PHLocation
    0.0.0.37: Pushover 3P
    3.0.5.7: SDJ-Health
    3.1.0.22: Sonos
    3.0.0.73: weatherXML
    3.0.1.190: Z-Wave
    Attached Files
    Michael

    #2

    Comment


      #3
      Many times the event triggers immediately. At other times, it slows down.

      I use Aeotec recessed z-wave sensors. How would I go about achieving an appropriate on/off with a HS switch?
      Michael

      Comment


        #4
        Go to devices, and select the light switch, and then at the bottom there's a drop down that says "Linked Device". Select the sensor in that drop down, and in the sensor's page select the light switch. That makes the devices talk to each other and speeds stuff up. Eventually, you want to do some investigating on what's taking so long. There's Z-Seer SW somewhere in the HS downloads section you may want to use to figure out what's going on. Have you checked in on your 'Logs'? You may need to clean all the chatter up by turning off command reporting from devices.

        Comment


          #5
          When I select the HS switch, root or child, I cannot locate the sensor. When I select the sensor, I can find the switch. Hmmm...
          Michael

          Comment


            #6
            Originally posted by Rvtravlr View Post
            When I select the HS switch, root or child, I cannot locate the sensor. When I select the sensor, I can find the switch. Hmmm...
            It is important. to understand how device linking works. It works by setting the value of the linked device to the device you are linking from. A switch is controllable so you can link to it from the sensor, but the sensor is not controllable so you cannot link from another device to it.

            When you can get two devices linked it is important to understand that when the source devices value changes it will set the linked device to that value. If your sensor has a value of 0 for no motion and 100 for motion, it will set the linked device to those values as the source device changes. If you are controlling a light where off is 0 and on is 100, the light will turn on when motion is detected and turn off when the device goes to no motion. If the motion sensor uses values of 0 for no motion and 1 for motion, it would set the switch (linked device) to 1 when there is motion. If the linked device is a dimmer it would be set to 1%, if it is a switch it would be non valid value.

            As you can probably guess linking a light switch to a motion sensor would likely yield undesirable results. Either the light would go on and off based on the sensor's time out or would not be controlled at all. The true intent of linking is for two similar devices, 2 dimmers, 2 switches, etc.

            Your best bet is to use events. If you notice in your first post, the event was slow triggering, but the light was controlled in the same second as the event triggered. The 12 second delay was in the event being triggered.

            To chase down the delays I would
            1. Use the Node Information page and look very closely at polling. Go through device by device and disable polling if it is enabled and not needed. I found dozens of devices being polled that were energy reporting devices. I also found dozens of devices being polled that were instant status devices. After I took care of the polling settings, all of my intermittent delays were gone
            2. Another problem is excessive logging. I try to disable device logging whenever possible
            3. Make sure no events are being repeatedly triggered. If you have triggers where a device "has been for at least...", make sure there are conditions or event options to keep it from repeatedly triggering once that time has lapsed. Another problem trigger is "a timer's value is greater than".
            4. In your log snippet at 1:53:59 you have two timers started - twice, I would look very carefully as to why that is happening. It seems to be excessive use of resources. Enough of that will introduce delays
            I have a very busy system and my lights will generally come on within a second of motion detection - using events.

            Number of Devices: 2506
            Number of Events: 1546
            HS4 Pro, 4.2.19.16 Windows 10 pro, Supermicro LP Xeon

            Comment


              #7
              Originally posted by rprade View Post
              Use the Node Information page and look very closely at polling. Go through device by device and disable polling if it is enabled and not needed. I found dozens of devices being polled that were energy reporting devices. I also found dozens of devices being polled that were instant status devices. After I took care of the polling settings, all of my intermittent delays were gone
              Randy,
              How do I decide if polling is required or not for a specific device? Should I look at the polling interval for the root, or the child or both?

              Cheers
              Scott

              Comment


                #8
                Originally posted by ScottRennie View Post
                Randy,
                How do I decide if polling is required or not for a specific device? Should I look at the polling interval for the root, or the child or both?

                Cheers
                Scott
                If I am not sure, I take my iPad to the device and see if HomeSeer is updated when the device is manually controlled. Z-Wave plus devices should support Instant Status. In older devices Cooper, Lutron and Leviton do, most others don’t. GE/Jasco and others (not Z-Wave plus) support pseudo instant status when the device has direct communication with the controller.

                Once you determine if a device needs polling, use only the polling that is necessary for that device. In other words poll it at only the frequency you need for that specific device. Also try to randomize polling by making the seconds spread from 1-59 across devices so that their polling gets spread out over time. As a rule, I don’t recommend polling any more frequently than 5m, XXs unless absolutely necessary. Polling generates at least twice the traffic as reporting generated from the device.
                HS4 Pro, 4.2.19.16 Windows 10 pro, Supermicro LP Xeon

                Comment


                  #9
                  Thank you. I'll try that - might remove some of the delays I'm getting at random times.

                  Comment


                    #10
                    Originally posted by ScottRennie View Post
                    Randy,
                    How do I decide if polling is required or not for a specific device? Should I look at the polling interval for the root, or the child or both?

                    Cheers
                    Scott
                    I neglected to fully answer. If you poll a root, the child nodes are all polled. On a device with a single child, polling the root or the child is about the same. If it is a root with multiple child nodes, polling a single child node would be preferable as it would slightly reduce traffic - if the single child is all you need. On my thermostats operating state doesn’t report and I need reasonably quick reporting so that I can test if a valve is stuck or not opening. I poll that single child device at 5m, XXs. I do not need to poll all 7 devices associated with the thermostat as some do report and others are unimportant.

                    If you can get what you need by polling a single child, don’t poll the root. If you are polling multiple child nodes, it *might* be better to poll the root. If you are polling the root, do not poll the child nodes. I have not been able to confirm any significant difference between scheduled polling at the node versus polling through an event. There is also the ability to suspend polling through an event or the Z-Wave Config page if you want to see what impact polling has on the network.

                    Since I carefully went through polling last year all of our significant delays disappeared. Now normal response to motion sensors measures at less than a second and when we see any latency at all it is still less than 2 seconds and those occurrences are vanishingly rare.
                    Last edited by randy; February 2, 2018, 08:46 PM. Reason: Typo.
                    HS4 Pro, 4.2.19.16 Windows 10 pro, Supermicro LP Xeon

                    Comment


                      #11
                      That's brilliant, thank you. That's tomorrow sorted

                      Comment


                        #12
                        Randy,

                        Thanks for all the great information. I have some work to do...
                        Michael

                        Comment

                        Working...
                        X