Announcement

Collapse
No announcement yet.

Schlage instant status not working when readded to HS4 - Solved!

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

    Schlage instant status not working when readded to HS4 - Solved!

    I have an HS4 Standard Edition 4.1.18.0 (Windows), HomeSeer SmartStick+ Zwave stick and three (3) SCHLAGE Connect (BE469NX) Locks. Today I decided to remove and re-add my Schlage Connect locks as I was getting sporadic issues with zwave commands failing to send to the locks. I moved my PC with the SmartStick+ Zwave stick within in inches of my door lock. I was able to remove it and readd it however none of the instant statuses are working now. Battery level shows at 0%. When i unlock or lock the door manually or with the keypad nothing is transmitted to HomeSeer. The z-Wave version I have installed is 3.0.7.0 along with the z-wave UI. In the logs it does say "Instant status and sensor wake-up notifications are not being programmed because HomeSeer is being used as an installation tool only." What does that mean?


    Please tell me that this is fixable. I'm thinking now I should have left well enough alone.

    #2
    Your first clue was this: " getting sporadic issues with zwave commands failing to send to the locks"

    You have a Z-wave network issue, trying to remove and re-add just compounds the problems since the root cause is communication, which means the lock will then not re-add properly.

    First identify the troublesome lock and examine the Z-wave node information, it should look something like this:

    Click image for larger version

Name:	Capture.PNG
Views:	239
Size:	33.3 KB
ID:	1490046

    Identify how many neighbors it has and what the last working route was, depending on what this info says will determine next steps.

    Comment


      #3
      TC1 thanks for your reply. To combat that situation, I installed Aeotec Repeaters throughout my house which did make a difference. I've attached the one of the locks below. I figure if I can solve this, I can repeat it to the others. Shouldn't the fact that the z-wave stick is mere inches from the lock negate the communication issue?

      Click image for larger version

Name:	dfgdfg.png
Views:	226
Size:	65.0 KB
ID:	1490051

      Comment


        #4
        Originally posted by rotunnoe View Post
        Shouldn't the fact that the z-wave stick is mere inches from the lock negate the communication issue?
        Nope, that is one of the most common misconceptions people have about Z-wave locks. That only works if there are no other nodes around, what happens during the inclusion process is that other nodes that are close by will respond to the network communication and attempt to assist (since it's a mesh), which is not necessarily a bad thing. The important part is that those close by nodes *have to* support Z-wave beaming (which is how the node controller gets the attention of lock). not every device supports beaming. For example, the wall switches immediately next to my locks support beaming. I've got two BE469NX locks for over several years and have never had communication problems.

        Since I can't see how your network is physically laid out (what nodes are where on a floor plan), my best advice at the moment is this: identify the lock's *physical* neighbors, the ones that are very close to it. Then look at their Z-wave certifications/specs to verify they support beaming. You can do that here:
        https://products.z-wavealliance.org/...rch?regionId=2

        One thing that I am curious about, it looks like you set polling on the lock's child devices/features, not really a good idea and will drain the battery quicker than normal. I have no polling set up except for the default 12h battery one and get instant status when anything changes on the lock.

        Oh, another obvious but sometimes overlooked thing, make sure your batteries are fresh

        Comment


          #5
          yes the polling was added automatically by the system when I readded the lock. Let me ask you this, If I restored the zwave from my backup as well as my homeseer, would the locks return to their old node and functionality or did I screw myself?

          Comment


            #6
            Don't worry, nothing is screwed up here that can't be tweaked or fixed. Since you said you were having problems with lock communications before, what would you hope to gain by doing a restore?

            Comment


              #7
              Thank you for the reassurance that it can be fixed. It just seems like everything I touch lately gets worse! The lock communications were sporadic. Nothing that polling the locks didn't fix when it happened. (I setup a manual event that would do this when needed). The gain would be that I would restore my instant status such as when the lock was manually unlocked or unlocked my keypad. I have several events that kick off based on who unlocks the door (user).

              To answer your previous question I have 82 nodes on my network. Most are Z-Wave plus but some are not. Most posts say that the key to adding the lock is to move it within 10 feet of the controller. If that isn't the case I would have no idea how to add this lock properly and I was better off before. At least all of the functionality worked.

              Comment


                #8
                It's your choice, you can try to keep excluding and including the lock until somehow it magically starts working (like most people post), or attempt a restore, or try to explore the possible beaming issue that might have been causing your original sporadic issues.

                Also, have you tried to simply do a rescan on the lock node? Sometimes this can correct feature issues, but from looking at all the info on the node it looks like it included properly.

                Comment


                  #9
                  The only thing on my network that supports beaming apart from my locks is my two z-wave controlled blinds but they are battery operated. Could that have been the culprit?

                  Yes I did a rescan on the locks many times. In one post it said to delete one of this child devices which I did and it did find it and come back.

                  Why would the constant exclude and include method work? It seems like you disagree with that approach.

                  Comment


                    #10
                    Originally posted by rotunnoe View Post
                    Why would the constant exclude and include method work? It seems like you disagree with that approach.
                    Because people do it cuz they heard someone got lucky doing it. Think about it: If you have two objects separated a known distance from each other, and don't change that distance, and run the same process over and over, and you're only successful once out of N times? Sounds more like voodoo than science.

                    The reason the include process does not work properly for them is because of network/RF issues that they are unwilling to explore/troubleshoot. I'm willing to bet money that if you take a Z-wave controller and a lock, with no other z-wave nodes transmitting nearby, that lock will include with no problems.

                    Comment


                      #11
                      I understand your logic but that simply isn't feasible for where I live. I've read that sometimes including the lock non-securely sometimes resolves the issue. In other posts a newer z-wave plugin was used. I can't find other z-wave plugins now that I'm on HS4. I don't know. I'm grasping at straws here.

                      Comment


                        #12
                        I'm suddenly having similar problems with my BE469ZP lock. Now on HS4 4.2.0.0 Windows with SmartStick+. It was looking good until for some reason stopped updating couple days ago. Today I've tried all I know... replaced batteries, exclude, include, factory reset, rescan, etc. Tried Zwave commands multiple times. All I get is either an odd named device with only 4 child devices, or a single root named Sigma Entry Control with no children. Weird how the first install went pretty good and not much has changed about my network.

                        I understand RF issues and am willing to work that angle, but I'm not sure how I might isolate other zwave nodes. There doesn't seem to be an option to disable communications with them other than excluding or powering off. Neither seems like a practical or good way to do this. Maybe I'm to new to know something here. Any help is appreciated!

                        Comment


                          #13
                          davidcald What z-wave plugin are you using? I am using (the newest) version 3.0.7.0 along with the new z-wave UI 1.0.0.0. I believe that the issues started when I updated to the newest z-wave version. In addition if I try to restore to an earlier version of my z-wave configuration from backup i get the following message: "The destination interface is not supported for a restore since it is too old." I'm curious if you're experiencing the same?

                          Also try rescanning your lock from the lock's root controller then check your HomeSeer log. Are you getting the error message "Instant status and sensor wake-up notifications are not being programmed because HomeSeer is being used as an installation tool only?"

                          Comment


                            #14
                            Originally posted by davidcald View Post
                            I'm suddenly having similar problems with my BE469ZP lock. Now on HS4 4.2.0.0 Windows with SmartStick+. It was looking good until for some reason stopped updating couple days ago. Today I've tried all I know... replaced batteries, exclude, include, factory reset, rescan, etc. Tried Zwave commands multiple times. All I get is either an odd named device with only 4 child devices, or a single root named Sigma Entry Control with no children. Weird how the first install went pretty good and not much has changed about my network.
                            You need to open a ticket, this could be an artifact of the 4.2 upgrade. "Sigma Entry Control" is a generic description and indicates it doesn't know how to define the device properly. Also as previously stated you need to be on Z-wave PI 3.0.7.0 or newer. Make sure you also do a factory reset on the lock before trying to re-include it.

                            Comment


                              #15
                              Originally posted by TC1 View Post

                              You need to open a ticket, this could be an artifact of the 4.2 upgrade. "Sigma Entry Control" is a generic description and indicates it doesn't know how to define the device properly. Also as previously stated you need to be on Z-wave PI 3.0.7.0 or newer. Make sure you also do a factory reset on the lock before trying to re-include it.
                              I am using Zwave PI 3.0.7.0 and disabled the new Zwave UI to make sure it wasn't the problem. I also have done factory resets multiple times thinking that would help, but no.

                              rotunnoe - I have not tried reverting to the previous Zwave version as that seems to be problematic in itself. I've tried rescanning and other Zwave commands from both the root device Zwave menu and the PI menu. I can't even get rid of this Sigma device now by Remove Bad Node or Exclude or anything other than deleting it. I did not get the message you mentioned.

                              I think some work is needed on organizing all the Zwave related commands and operations into a single modern UI and not have them scattered all over the program. Same thing with Device management. The new UI doesn't do that, it's basically just the same thing in a new skin.

                              Thanks for the responses! Will start anew and document everything to submit a ticket.

                              Comment

                              Working...
                              X