Announcement

Collapse
No announcement yet.

Delays with version 3.0.1.124

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

    I've been checking many of the nodes that I know are automatically reporting status, and I just noticed something about some old Aeon Labs switches: It takes forever to retrieve their settings, even though they should be communicating just fine!

    EDIT: Okay, now trying to access the device properties of the roots for these devices is just timing out after I tried to open the Settings tab (on the Z-wave tab).
    There's something fishy with these devices now...
    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


      There's been something fishy about these for a long time. I put one of these in a drawer about 2 years ago.
      https://forums.homeseer.com/forum/de...plifier-plugin

      Comment


        Originally posted by happnatious1 View Post
        There's been something fishy about these for a long time. I put one of these in a drawer about 2 years ago.
        ... but they have been working great up to and including Z-wave plugin version .110....
        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


          If you enable debug logging, cause a delay, then send me the log file, I can see what is going on.

          In regards to routes, you can set a route, but the Sigma chip will probably overwrite the route when it "thinks" there is a better one.

          I find that with larger networks there are too many routing options and the chip picks routes poorly. To have better control over routing, back up your interface and then restore it. That will remove all routing info. You can then optimize maybe a couple key nodes, then set the routes you want. They are more likely to stick. The chip will have far less choices. I also think over time, the routing gets messed up.

          There is a command to lock routes, and this disables the chip from determining routes, but I think that's probably not a good thing to enable.

          Originally posted by Moskus View Post
          ... but they have been working great up to and including Z-wave plugin version .110....
          💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

          Comment


            Originally posted by rjh View Post
            If you enable debug logging, cause a delay, then send me the log file, I can see what is going on.
            Will do.

            Last night I spent some time individually optimizing "problem nodes", and the results were good. I also turned on logging on all Z-wave devices last night, so today I have a much clearer view of what's going on. It seems like a couple of devices are holding up, here's what's happening when I turn on the alarm.

            Code:
            jul-04 07:31:14	 	Z-Wave	Device: 1. etg Gang Ytterdr Ls, Notification Set to 121
            jul-04 07:30:46	 	Device Control	Device: 2. etg NM-rom Ovn, Switch to Off (0) by/from: CAPI Control Handler
            jul-04 07:30:46	 	Device Control	Device: 2. etg LH-rom Ovn, Switch to Off (0) by/from: CAPI Control Handler
            jul-04 07:30:46	 	Device Control	Device: 2. etg Soverom Ovn, Switch to Off (0) by/from: CAPI Control Handler
            jul-04 07:30:39	 	Z-Wave	Device: 1. etg Gang Ytterdr Ls, Door Lock Set to 255
            jul-04 07:30:37	 	Device Control	Device: 1. etg Gang Ytterdr Ls, Door Lock to Lock (255)
            jul-04 07:30:37	 	Event	Event Trigger "Automatisk (standard) Ytterdr, automatisk ls (Alarm p)"
            jul-04 07:30:37	 	Z-Wave	Device: 1. etg Gang Ytterdr Status, Sensor Set to Off/Closed/No Motion
            jul-04 07:30:37	 	Z-Wave	Device: 1. etg Stue RGB stort vindu Switch Red Set to OFF
            jul-04 07:30:37	 	Z-Wave	Device: 1. etg Kjokken Switch Multilevel 4 Set to OFF
            JUL-04 07:30:23x 	Z-Wave	Device: 1. etg Stue Ved skap, Switch Set to 0
            jul-04 07:30:23	 	Z-Wave	Device: 1. etg Stue Ved piano Set to 0
            JUL-04 07:30:10x 	Z-Wave	Device: 1. etg Stue Ved pipe Set to 0
            jul-04 07:30:10	 	Z-Wave	Device: 1. etg Stue Ved sofa Set to 0
            jul-04 07:30:10	 	Z-Wave	Device: 1. etg Kjokken Bevegelsessensor, Bevegelse Set to Off/Closed/No Motion
            jul-04 07:30:08	 	Z-Wave	Device: 2. etg Gang Taklys Set to 0
            jul-04 07:30:08	 	Device Control	Device: 1. etg Stue RGB stort vindu Switch All to Off (0) by/from: CAPI Control Handler
            jul-04 07:30:08	 	Device Control	Device: 1. etg Stue RGB skap Switch All to Off (0) by/from: CAPI Control Handler
            jul-04 07:30:08	 	Device Control	Device: 1. etg Stue Ved skap, Switch to Off (0) by/from: CAPI Control Handler
            jul-04 07:30:08	 	Device Control	Device: 1. etg Stue Ved piano to Off (0) by/from: CAPI Control Handler
            jul-04 07:30:08	 	Device Control	Device: 1. etg Stue Ved pipe to Off (0) by/from: CAPI Control Handler
            jul-04 07:30:08	 	Device Control	Device: 1. etg Stue Ved sofa to Off (0) by/from: CAPI Control Handler
            jul-04 07:30:08	 	Z-Wave	Device: 1. etg Stue Taklys Set to 0
            jul-04 07:30:08	 	Z-Wave	Device: 1. etg Kjokken Taklys Set to 0
            jul-04 07:30:08	 	Z-Wave	Device: 1. etg Gang Taklys yttergang Set to 0
            jul-04 07:30:08	 	Z-Wave	Device: 1. etg Gang Taklys Set to 0
            jul-04 07:30:08	 	Z-Wave	Device: 1. etg Toalett Taklys Set to 0
            jul-04 07:30:07	 	Z-Wave	Device: 1. etg Bad Taklys Set to 0
            jul-04 07:30:06	 	Device Control	Device: 2. etg LH-rom RGB, Channel All to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 1. etg Stue RGB skap Switch All to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom Sovelys Magnus to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom Sovelys Kristine to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom RGBW, All channels to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg NM-rom Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg NM-rom Sovelys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg NM-rom Blomstlampe to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg NM-rom Farge Kontroll to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg LH-rom Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg LH-rom Sovelys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg Gjesterom Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg Gang Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 1. etg Stue Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 1. etg Kjokken Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 1. etg Kjokken HDMI receiver to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 1. etg Gang Taklys yttergang to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 1. etg Gang Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 1. etg Toalett Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 1. etg Bad Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 0. etg Gang Verksted to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 0. etg Gang Vaskerom to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 0. etg Gang Trkegang to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 0. etg Gang Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 0. etg Gang Matbod to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 0. etg Bad Vifte to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 0. etg Bad Taklys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg NM-rom Sovelys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg LH-rom Sovelys to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom RGBW, All channels to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom Sovelys Kristine to Off (0)
            jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom Sovelys Magnus to Off (0)
            jul-04 07:30:06	 	Event	Event Trigger "Kontroll Alarm p"
            It seems like the "Ved skap" and "Ved pipe" devices are causing delays. I've now done some more optimizing on these two nodes, we'll see if that works.

            But I have a question:
            What is the "notification" device for my Yale Lock? And why does it need an additional minute to be updated?


            Originally posted by rjh View Post
            In regards to routes, you can set a route, but the Sigma chip will probably overwrite the route when it "thinks" there is a better one.
            Yeah, that's exactly what it looks like to me. Thanks for the explanation.


            Originally posted by rjh View Post
            I find that with larger networks there are too many routing options and the chip picks routes poorly. To have better control over routing, back up your interface and then restore it. That will remove all routing info. You can then optimize maybe a couple key nodes, then set the routes you want. They are more likely to stick. The chip will have far less choices. I also think over time, the routing gets messed up.
            This seems "risky" to me, but I'm tempted to try it.

            It really seems weird that looking in a table is actually slower than figuring out the paths each time.

            And my network is a mix of new and old devices, and I thought that without a routing table that could be a problem. Care to weigh in?


            Originally posted by rjh View Post
            There is a command to lock routes, and this disables the chip from determining routes, but I think that's probably not a good thing to enable.
            I'm always for giving the users the options, but this seems like a risky move indeed...
            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


              Originally posted by rjh View Post
              I find that with larger networks there are too many routing options and the chip picks routes poorly. To have better control over routing, back up your interface and then restore it. That will remove all routing info. You can then optimize maybe a couple key nodes, then set the routes you want. They are more likely to stick. The chip will have far less choices. I also think over time, the routing gets messed up.

              WAIT! The routing table is stored in the physical controller, right? A Z-NET in my case?

              I have a backup Z-NET, meaning I can try this backing up Z-NET #1 and restore it to Z-NET #2, disconnect Z-NET1, and configure Z-NET2 to use the same IP as 1 and then just restore the backup to it? Right?

              Then if it does not work like I want to, I can just power down Z-NET2 and reconnect Z-NET1 again and everything should be back to normal...? Right?!

              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


                Originally posted by Moskus View Post
                WAIT! The routing table is stored in the physical controller, right? A Z-NET in my case?

                I have a backup Z-NET, meaning I can try this backing up Z-NET #1 and restore it to Z-NET #2, disconnect Z-NET1, and configure Z-NET2 to use the same IP as 1 and then just restore the backup to it? Right?

                Then if it does not work like I want to, I can just power down Z-NET2 and reconnect Z-NET1 again and everything should be back to normal...? Right?!

                Yes, all of the routing and node info is stored in the nonvolatile memory of the Z-Wave controller. If you don't add or delete any Z-Wave devices while on Z-Net2, you can go back to Z-Net1 and be back where you were.
                HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                Comment


                  Originally posted by rprade View Post
                  Yes, all of the routing and node info is stored in the nonvolatile memory of the Z-Wave controller. If you don't add or delete any Z-Wave devices while on Z-Net2, you can go back to Z-Net1 and be back where you were.
                  Sorry for not reporting back, but yes I did the switch!

                  And Rich is right: Not having a routing table for most devices is much, MUCH faster. I've optimized a few nodes on the "edge" of the house, but most nodes are not optimized.

                  On average doing a full test with 10 packets took 1.7 to 2 seconds for most nodes. Some took longer. Now, the same test is done under half a second!


                  However, that did solve my problem. But I found that an outdoor motion sensor (Aoen Labs multisensor, but not the new one) apparently was spamming the network with motion data somehow. Changing the re-trigger time to 60 minutes did the trick.
                  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


                    I've got the Aeotec delay down to about 8 seconds by following advice here and changing parameter 5 to "2".

                    However, that's still an unacceptable amount of time. I've read about eliminating routing tables and that might be part of it. I have two sensors, one within two feet of the z-net, the other across the house. The one next to the z-net is as quick as can be, the one at the opposite end, painfully slow.

                    I put them both next to the z-net and the one from the other side of the house is still slow. To me that indicates a defective unit or more than likely a routing issue.

                    How can I eliminate (as much as possible) routing that I assume is done when optimizing? Should I optimize the device while next to the z-net and then move it to its desired location? My goal is to have lights come on based on ambient lighting. The sensor will be USB powered.

                    Any advice is welcome. FWIW, I am now on 3.0.1.140

                    Comment

                    Working...
                    X