Announcement

Collapse
No announcement yet.

Questions about zwave network optimization and battery powered devices

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

    Questions about zwave network optimization and battery powered devices

    Whats the correct procedure for doing a full optimization of the zwave network with respect to battery powered devices?

    I've always thought that they should be asleep when doing a full optimization. I cant imagine how it would be possible to awaken all the devices and do a full network optimization when you have a large network with many battery devices like I do.

    What then is the proper way to optimize battery powered devices when adding them to the network? What if you need to re-optimize that device for whatever reason...what's the proper technique?

    Is it incorrect to have more than one battery device awake when optimizing them? I've noticed problems when I optimize one battery device and another is still awake.

    Is it possible that a scheduled awake mode for a battery device could interfere with the optimization process?

    Somewhat different topic, but I was also wondering about polling and optimization. Ive got several scripts that poll every so often and I know polling can slow things down. Does it actually interfere with the optimization? If so, I should probably turn off these scripts while optimizing.

    #2
    Awaiting suggestions with baited breathe...

    Comment


      #3
      My experience and testing shows following:

      All battery powered device have a way to force wake up (about 10 minutes). During this time they listen actively for commands and can be optimized. Manual for each device will tell you how to wake them up. To ensure device is awake I typically run either configure or rescan command first to confirm it is listening.

      I go to status -> device -> full optimize node to run battery operated device optimization. This enables device to find its neighbors and sets return routes. I think in this process it pings all nodes so it is best to only wake up one battery device at a time.

      Since this process relies on existing network map, my guess is that it is best to run global network optimization first (HS folks recommend running 4 times) with all sensors asleep. This is run from setup -> interfaces -> manage full optimize network.

      This is exactly what I did as I had dropped packets from my furthest battery sensor. First I optimized network (and for one switch I had to optimize it individually first before it would pass during network optimization). Once all active devices came back as "optimized and return route added" I optimized the sensors one by one till they also came back with same message.

      Network is rock solid now.

      I also used z-seer to draw connections and test responses - this is interesting tool for visualization but I think you don't need it if you are happy with optimization results.

      From my experience wake up doesn't ensure device is listening - it just wakes up, sends packets and goes back to sleep. You have to push button on the device to make it awake so that it can be optimized.

      If there is too much traffic on network (polling) I am guessing it would be better to turn it off. It could be return map is set based on response time so device being busy due to polling would make it unfavorable even though it might be a good one. This is just my guess....

      Comment


        #4
        Hey Person, yours is the same as my experience.
        But folks are reporting battery devices becoming neighbors for powered devices if they wake during optimization and possibly messing up routing, it doesn't sound like you've seen that at all? I haven't had that, fortunately.
        All Z-Wave, #101 devices, HomeTroller Series2, HomeSeer2 v.2.5.0.81, & 1x Z-Troller

        Comment


          #5
          Originally posted by Olbrit View Post
          Hey Person, yours is the same as my experience.
          But folks are reporting battery devices becoming neighbors for powered devices if they wake during optimization and possibly messing up routing, it doesn't sound like you've seen that at all? I haven't had that, fortunately.
          Why with Z-health does homeseer try to optimize battery devices at all? My z-health at night is full of errors that it couldn't optimize the battery operated devices...

          Comment


            #6
            Hey Jayman13, the quick unhelpful answer is because that's how it works! In my little Z-Wave world it doesn't matter at all that HS has log entries showing that Z-Health tried to optimize the battery devices, in fact it actually gives me peace of mind to see that Z-Health is trying every device regardless and that the battery ones, correctly, don't get optimized.

            Also how often are you running Z-Health to be bothered by the logs? Alot of Z-Wave Users recommend only running Z-Health for a few nights after adding, removing, or relocating devices, after that it shouldn't be needed.
            All Z-Wave, #101 devices, HomeTroller Series2, HomeSeer2 v.2.5.0.81, & 1x Z-Troller

            Comment


              #7
              Originally posted by Olbrit View Post
              Hey Jayman13, the quick unhelpful answer is because that's how it works! In my little Z-Wave world it doesn't matter at all that HS has log entries showing that Z-Health tried to optimize the battery devices, in fact it actually gives me peace of mind to see that Z-Health is trying every device regardless and that the battery ones, correctly, don't get optimized.

              Also how often are you running Z-Health to be bothered by the logs? Alot of Z-Wave Users recommend only running Z-Health for a few nights after adding, removing, or relocating devices, after that it shouldn't be needed.
              I do leave my z-health on every night. Perhaps I should stop doing that, a waste of log. I'm always moving things around though so maybe I should keep it. Ah, decisions! If life were only this simple.

              Comment


                #8
                If you're not getting any other unwanted outcomes from running Z-Health every night and you're still moving devices around, then you should probably just continue with Z-Health. If the only downside is a bunch of log entries about battery device failed optimizations, then what does it matter? Once you've stopped moving devices around for a few weeks/months, then I'd recommend you turn off Z-Health for a while.
                All Z-Wave, #101 devices, HomeTroller Series2, HomeSeer2 v.2.5.0.81, & 1x Z-Troller

                Comment


                  #9
                  Guys, sorry about bumping an old thread but the title is still appropriate

                  I've been using only AC-powered Zwave devices to date (HS2 2.5.0.80, Ztroller FW 1.15). I just added my first battery device, an Everspring leak detector. I included it via the Ztroller without any problem, and scanned its properties to receive what I believe is the correct root device and child nodes. Homeseer can also receive leak alerts when the sensor is within direct range of the Ztroller, but not when it's located in its final location.

                  With the sensor in its final location (and awake/listening) I optimized the whole network 4+ times, and then I optimized the device itself 4+ more times. Because the sensor was awake during the full network optimization, I can see the sensor node number has been added to the neighbor list for several of the AC-powered devices. Is this expected, or a cause for concern?

                  If the sensor's node should be removed from all AC-powered neighbor lists, how is this done? (As a quick test, I removed the batteries from the sensor, and performed several more "full network" optimizations, but this did not bump the sensor node number from any neighbor lists).

                  Also, is there any way to view what return route the sensor uses when it attempts to reach the Ztroller/Homeseer with a leak alert?

                  Thanks,
                  Don

                  Comment


                    #10
                    I tried a few more things without any real improvement:

                    1) Updated Ztroller firmware to 1.17.
                    2) Removed and re-added the Everspring leak sensor.
                    3) Verified proper child nodes were created.
                    4) Moved the Everspring leak sensor to its final location.
                    5) Added an extra plug-in module (HomePro ZRP100) in the vicinity of the Everspring leak sensor roughly between it and the Ztroller.
                    6) Ran full optimization on the whole network 4+ times successfully (about a dozen devices total).
                    7) Ran optimization and full optimization on the Evergreen sensor itself 4+ times each. Full optimization reported return routes saved successfully and I had no issues accessing the sensor configuration page or scanning the sensor at this point while awake.
                    8) Nevertheless, at the optimized location, dipping the probe in water caused the sensor to beep without any status change reaching Homeseer. When I continued to activate/deactivate the sensor while moving it closer to the Z-troller, homeseer eventually did receive the notification.

                    This suggests to me that the Everspring isn't choosing a viable route to homeseer from its optimized/permanent location or possibly that it is only able to communicate with the ztroller directly. It sure would be interesting to know what route(s) the Everspring is or is not trying to use.

                    Cheers,
                    Don

                    Comment


                      #11
                      (Wow, 2 years has flown by). I still have a bunch of water leak sensors all over the house and in the attic, and HS gets updated the moment they alarm, so it seems it can be made to work - sorry it's being a pain for you, it looks like you've tried just about everything. Some ideas:
                      1. Try upgrading to HS2 2.5.0.81
                      2. Try a hard power cycle on the Z-Troller, (I found I need to do this each time after I've finished 'fiddling' with the mesh, e.g. adds/removes, optimizes, or whatever - the final Z-Troller hard power cycle seems to create 100% stability for me)
                      3. Try Z-Seer to graphically display all connections to neighbor nodes with their routing paths
                      4. The best way I found to keep the Everspring awake for optimization is to remove the batteries for a minute and then replace them, (or power it down for a minute if you have remote power to it) - this gives me more than enough time for 4 optimizes and is way easier than the triple tap finger dance on the switch

                      Hope this helps...

                      (From your earlier question I have never been concerned about my battery devices appearing or not appearing on AC-powered neighbor lists).
                      All Z-Wave, #101 devices, HomeTroller Series2, HomeSeer2 v.2.5.0.81, & 1x Z-Troller

                      Comment


                        #12
                        Thanks for the tips Olbrit. I installed 2.5.0.81 and power cycled the Z-troller a couple of times. Still no luck. So, I just ordered additional modules (Aeon and GE plug-ins) to attempt to build a stronger mesh. The environment containing the leak sensor is quite challenging. It is in my shop area beneath my garage which has concrete walls and concrete above. There is a doorway leading into a closet (which contains a couple of plugin modules) and then in the upper part of the closet is an access door leading into the main house crawl. So the Zwave signal must propagate through this path to reach the Z-troller in the main house. If adding extra plugin modules still doesn't help then perhaps I'll need to consider a remote Z-troller for the shop area.

                        Since you have several everspring sensors throughout your house, all working well, I guess it is safe to assume the sensor is capable of routing through multiple hops to the controller. Thanks again.

                        Comment


                          #13
                          That does sound like a tough route for the signal. A second Z-Troller is a good idea and you'll need HS2Pro for that I believe.

                          Tink posted a while back that RF stands for 'Really Funny' referring to how logic, line of sight, least distance, etc., don't always apply. So for grins you could try relocating the Everspring a few feet and try different orientations too, just in case you find a sweet spot for the internal antenna and optimum propagation. (You could also try this with the Z-Troller).

                          Once you've got it working the way you want, you should make sure you keep an eye on the battery level and test the alarm monthly (I use a damp q-tip across the terminals in situ). Or, convert it to a wall power source, but still test frequently.
                          All Z-Wave, #101 devices, HomeTroller Series2, HomeSeer2 v.2.5.0.81, & 1x Z-Troller

                          Comment


                            #14
                            This Utilitech (Everspring) leak sensor is still giving me fits, even after adding extra repeating nodes to the mesh. The leak sensor now has 6 neighbors. When the sensor is located at its final position, awake and listening, HS has no problems communicating with it, optimizing it, etc. HS can also receive an "alarm" at this point (at least once) when the sensor is tripped.

                            However, once the sensor goes to sleep, alarm notifications no longer reach HS, though the sensor continues to reach neighbor nodes that require no hops. So, as a temporary workaround, I placed a Z-wave appliance module within direct range of the leak sensor. I then added this module as a slave (Group 2 association) to the leak sensor and I configured HS to periodically poll the plug-in appliance module.

                            Now when a leak occurs, the leak sensor commands the nearby plug-in module to ON. A short while later (per the configured polling interval) HS detects the module's status change and interprets it as a leak event.

                            Comment


                              #15
                              That's an interesting workaround to a fugly situation. I've never (to my knowledge) had a battery sensor fail to update my controller with an alarm after it has been asleep, so I guess I'm lucky. Relocation of your Z-Troller, or getting a second one as you suggested, may be the direct solution.

                              I guess if you use an Instant Status Z-Wave appliance module next to the Everspring then that would give HS an alarm signal without the polling delay?

                              In any case, it sounds like you've been testing the Everspring quite a bit so it may be a good idea to put in fresh batteries regardless of what HS battery level reports (fwiw, if I have to use batteries I've been using Energizer Ultimate).
                              All Z-Wave, #101 devices, HomeTroller Series2, HomeSeer2 v.2.5.0.81, & 1x Z-Troller

                              Comment

                              Working...
                              X