Announcement

Collapse
No announcement yet.

Delays with version 3.0.1.124

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

  • #76
    Originally posted by bebaldin View Post
    Go into your plug-ins page, and click the Z-Wave link. This brings up the Z-Wave Configuration Page, which will show the queues for each network in real time.
    Thanks,

    I think you mean

    Plugins --> Z-wave --> Controller Management --> Z-wave interfaces --> Controller Node Infromation --> Transmit Queue

    I'll look into that.

    Comment


    • #77
      So far so good

      Well I'm hoping you were right here as the delays have gone down to about a second maximum since updating to 128. Think your on the money about certain devices causing the queue to get backed up, in my case it believe it was the aeotec smart switch, I was only using it as an extender to reach my shed but appears I don't need it as the shed is direct to my controller. I hadn't set this device up with as much attention as the multi sensors so the child devices of the switch were being polled every 20 mins!

      Still confused as I disabled all polling yesterday during the update to 126 so would of thought that would have the same effect as updating to 128. I've also noted when setting the polling on the battery on aeotec multisensors it will not allow me to put it above 12 hours, polling is disabled on all other child devices but I seem to remember in the past I have altered it to be 23 hours and 59 minutes yet it seems to reset to 12 hours after a period of time. I'll recheck this to make sure this is not a fabrication of my mind.

      Cheers for the help so far, hopefully this system state holds and the Mrs will stop chewing my ear off about the lights.

      Edit: was just rereading the thread and missed the advice of belbaldin and rprade mentioning the rescans have enabled polling and reset defaults. I was not aware of this. Also as belbaldin said the rgb polling on my aeotec seems to be the main problem, well spotted.
      Last edited by Steaktastic87; June 12th, 2017, 04:06 PM.

      Comment


      • #78
        short lived

        The delays came back. Earlier I enabled debugging to gather some logs for the techs to look at and noticed the aeotec smart switch was still being polled for watt, amps etc every second so ive manually disabled everything using the node interface screen. Hopefully this will sort it, ill post back with results tomorrow.

        Comment


        • #79
          Originally posted by integlikewhoa View Post
          Thanks,

          I think you mean

          Plugins --> Z-wave --> Controller Management --> Z-wave interfaces --> Controller Node Infromation --> Transmit Queue

          I'll look into that.
          No, click on the z-wave hyperlink on the Plugins - Manage page or manually go to the /zwaveconfig web page on your HS system.
          HS 3.0.0.548: 1976 Devices 1156 Events
          Z-Wave 3.0.1.262: 123 Nodes on one Z-Net

          Comment


          • #80
            More experimentation tonight. I find that polling must be used very sparingly to prevent interference with command processing - even with .128 of the plug-in. Any queueing of polling requests at all will result in command degradation. It is very important to limit device polling to only those devices that do not instantly status, or those that cannot be set up to issue reports based upon sensors (such as motion, wattage, luminance, etc). If you can keep your data current using reporting from the individual device, it does not bog down the network.

            I have found so far in my system that the Aeotec ZW096 Smart Switches and Aeotec ZW080 Color Bulbs will hang up polling on any color channel. The Jasco 45605 and 45609 devices do not poll property. The Enerwave ZWN-SC7 will hang polling on any scene controller button. Any of these allowed to poll will bring your system to a crawl. There may be more, but these are the ones I have found so far.

            A good way to find these is to poll your devices manually using the button at the top right of the main device page. This will give you a good idea of what times out and what polls correctly.

            Right now the only thing I have polling are three of the Aeotec Smart Strips. These have always shown a variety of issues, and to keep the data current in the child devices polling helps. I am testing 3 minute polling on those three devices for right now, and it does not seem to queue the data at all unless a child hangs up sporadically.

            Comment


            • #81
              Interesting.

              The poll all devices on the device page shows "29 @ Polling: 1st Floor Porch Color Control (Status isPlugin Reports Timeout Before Result)" and "42 @ Polling: Outside Garage Color Control (Status isPlugin Reports Timeout Before Result)" for my hsm200's. zwave config send timeout set at 10 seconds.



              Current Date/Time: 6/13/2017 7:14:00 AM
              HomeSeer Version: HS3 Pro Edition 3.0.0.318
              Linux version: Linux HS3 4.4.0-79-generic #100-Ubuntu SMP Wed May 17 19:58:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux System Uptime: 2 Days 21 Hours 2 Minutes 29 Seconds
              Number of Devices: 329
              Number of Events: 79
              Available Threads: 400

              Enabled Plug-Ins
              3.0.2.0: AquaConnect
              2.0.35.0: BLLAN
              3.0.0.56: DSC Security
              3.0.0.68: HSTouch Server
              3.0.1.7: Kodi
              1.2.0.0: Monoprice Amp
              3.0.6280.35072: Ultra1Wire3
              3.0.0.68: weatherXML
              0.0.0.6: YAMAHA-RECEIVER
              3.0.1.128: Z-Wave
              If it ain't broke, don't fix it!

              Comment


              • #82
                A couple of notes on polling.

                Are you polling from an event action? When you poll from an event action, it waits for a response, so that will slow down the system the most as it could take a couple of seconds to send a request, then process the response.

                If you poll from the device properties, Z-Wave tab, that simply sends a request to the device and asks it to report its status. This is faster as the code does not wait so other things can happen. Its the same as sending a control command to the device. However, the node you are polling should respond fairly quickly and this is using Z-Wave bandwidth and you could polling in sync so many devices could be polled at once. Staggering your poll times can help here. Commands take priority over polls always, but the Z-Wave RF can only handle one command at a time.

                Originally posted by bebaldin View Post
                More experimentation tonight. I find that polling must be used very sparingly to prevent interference with command processing - even with .128 of the plug-in. Any queueing of polling requests at all will result in command degradation. It is very important to limit device polling to only those devices that do not instantly status, or those that cannot be set up to issue reports based upon sensors (such as motion, wattage, luminance, etc). If you can keep your data current using reporting from the individual device, it does not bog down the network.

                I have found so far in my system that the Aeotec ZW096 Smart Switches and Aeotec ZW080 Color Bulbs will hang up polling on any color channel. The Jasco 45605 and 45609 devices do not poll property. The Enerwave ZWN-SC7 will hang polling on any scene controller button. Any of these allowed to poll will bring your system to a crawl. There may be more, but these are the ones I have found so far.

                A good way to find these is to poll your devices manually using the button at the top right of the main device page. This will give you a good idea of what times out and what polls correctly.

                Right now the only thing I have polling are three of the Aeotec Smart Strips. These have always shown a variety of issues, and to keep the data current in the child devices polling helps. I am testing 3 minute polling on those three devices for right now, and it does not seem to queue the data at all unless a child hangs up sporadically.
                website | buy now | support | youtube

                Comment


                • #83
                  Originally posted by rjh View Post
                  A couple of notes on polling.



                  Are you polling from an event action? When you poll from an event action, it waits for a response, so that will slow down the system the most as it could take a couple of seconds to send a request, then process the response.



                  If you poll from the device properties, Z-Wave tab, that simply sends a request to the device and asks it to report its status. This is faster as the code does not wait so other things can happen. Its the same as sending a control command to the device. However, the node you are polling should respond fairly quickly and this is using Z-Wave bandwidth and you could polling in sync so many devices could be polled at once. Staggering your poll times can help here. Commands take priority over polls always, but the Z-Wave RF can only handle one command at a time.


                  Rich I have a few events that I use to poll. Example being when the washer is running, I have it poll about every 15 seconds. This gives a more accurate time off alert to the house. Once the washer is done, the event doesn't run again (it's looking at a threshold on power).

                  It seems that things aren't multi threaded. I'm not sure if it's a limitation of sorts, but it doesn't make sense to have the plugin waiting on one device and that action holds up the whole zwave network.

                  Things have been disabled on polling here and it's been much better, but I have a few things that aren't working properly now that I'd like to get back up and running.

                  Comment


                  • #84
                    Originally posted by waynehead99 View Post

                    It seems that things aren't multi threaded. I'm not sure if it's a limitation of sorts, but it doesn't make sense to have the plugin waiting on one device and that action holds up the whole zwave network.
                    It's a Z-Wave limitation I believe. It's the same on Vera.
                    Originally posted by rprade
                    There is no rhyme or reason to the anarchy a defective Z-Wave device can cause

                    Comment


                    • #85
                      Originally posted by rjh View Post
                      A couple of notes on polling.

                      Are you polling from an event action? When you poll from an event action, it waits for a response, so that will slow down the system the most as it could take a couple of seconds to send a request, then process the response.

                      If you poll from the device properties, Z-Wave tab, that simply sends a request to the device and asks it to report its status. This is faster as the code does not wait so other things can happen. Its the same as sending a control command to the device. However, the node you are polling should respond fairly quickly and this is using Z-Wave bandwidth and you could polling in sync so many devices could be polled at once. Staggering your poll times can help here. Commands take priority over polls always, but the Z-Wave RF can only handle one command at a time.
                      No, these are polls set within the device itself. I do have a couple of events that poll (door locks after locking) but I currently have polling disabled on these.

                      Commands may take priority, but any queued poll stalled by timeout causes the system to stop responding. I was able to repeat this over and over again by polling devices that I know will timeout.

                      Comment


                      • #86
                        Originally posted by bebaldin View Post
                        Commands may take priority, but any queued poll stalled by timeout causes the system to stop responding. I was able to repeat this over and over again by polling devices that I know will timeout.
                        Oooh! That's interessting.

                        I have some root devices for some Everspring motion sensors (battery operated) that weirdly have their status set to "Unknown". This does not make sense, and perhaps HomeSeer is somehow trying to poll the battery operated sensors and getting a time out (of course).

                        See image below.
                        Attached Files
                        HSPro 3.0.0.458, Z-NET with Z-wave plugin 3.0.1.190, RFXCOM + 2x RFXtrx433E, HSTouch, Squeezebox plugin, iTach IP/WF2IR & GC-100-6 with UltraGCIR, BLDenon, NetcamStudio, Jon00s Webpage builder, Harmony Hub plugin, SCSIP (with FreePBX), Arduino plugin, IFTTT, Pushalot plugin, Device History plugin.
                        Running on Windows 10 (64) virtualized
                        on ESXi (Fujitsu Primergy TX150 S8).
                        WinSeer (for Win10) - TextSeer - FitbitSeer - HSPI_MoskusSample

                        Are you Norwegian (or Scandinavian) and getting started with HomeSeer? Read the "HomeSeer School"!

                        Comment


                        • #87
                          I'm not sure if my problem is related or not, but I added two more Multisensor 6's to one I had already installed.

                          After installing the new ones and trying to put an event to turn on a light I get a huge delay. I also have a delay on my previous events (open pantry door turn on light). After not walking or using the new installed motions on the mulitsensors for a bit everything returns to normal and pantry or closet lights will turn on right away when door is opened. Until I walk infront of the new motions again and that seems to put a lock on everything.

                          Comment


                          • #88
                            Originally posted by sparkman View Post
                            No, click on the z-wave hyperlink on the Plugins - Manage page or manually go to the /zwaveconfig web page on your HS system.
                            Thank you I was able to find that!

                            Comment


                            • #89
                              Originally posted by Moskus View Post
                              Oooh! That's interessting.

                              I have some root devices for some Everspring motion sensors (battery operated) that weirdly have their status set to "Unknown". This does not make sense, and perhaps HomeSeer is somehow trying to poll the battery operated sensors and getting a time out (of course).

                              See image below.
                              That root device 'Unknown' drives me nuts when it occurs. There is an hs. command that is supposed to fix the icon and reset it but it has never worked for me. Rescan doesn't fix it either. The only success I have ever had when a device changes the root is to remove and re-add it from scratch. Annoying.

                              As far as I know setting a polling value in the root only commands it to poll every child device, and not the root itself. From what I have read on the boards, the root icon getting changed is a database anomaly and not a result of the polling. Rich can probably speak more to this though.

                              Comment


                              • #90
                                Originally posted by integlikewhoa View Post
                                I'm not sure if my problem is related or not, but I added two more Multisensor 6's to one I had already installed.

                                After installing the new ones and trying to put an event to turn on a light I get a huge delay. I also have a delay on my previous events (open pantry door turn on light). After not walking or using the new installed motions on the mulitsensors for a bit everything returns to normal and pantry or closet lights will turn on right away when door is opened. Until I walk infront of the new motions again and that seems to put a lock on everything.
                                Check each child device on those Aeon's - the device scan (or rescan) has an annoying habit of assigning polling values to every child device. Would love to see that fixed for the ZW100 in Homeseer as its not even necessary to poll them at all - they have a number of different ways to set up reporting in the parameters that work well.

                                For that matter, I would like to see the arbitrary assignment of polling values completely removed from the rescan function, as well as any custom changes to the device. I hate being forced to rescan something, and then having to redo all my custom icons and settings for that device because rescan reverts to defaults.

                                Comment

                                Working...
                                X