IT Solutions

@MrBill We have already looked into this. Locks from different manufacturers, with a few exceptions, are not compatible (i.e. can't be re-keyed to work with a different brand of key). On one door we used a Kwickset 99140-102 that covers the existing deadbolt inside knob and turns it. That was our best choice for that because that lock uses a Medeco Key. Medeco is a pick proof restricted distribution key systems that requires a special machine to duplicate. Only authorized dealers have the machines and can get blanks. Possession of a key alone is not supposed to allow a copy to be made. One must also have special authorization. That means a key can be issued to an employee, and when it comes back, one knows there is not an additional copy still out. Some commercial deadbolts use removeable cylinders that allows one to change the cylinder to be able to use a different key. This is what we did on our office front door. I too am not a locksmith, but too know how to rekey a lock, do master key systems, and I have a friend that is a 3rd generation locksmith so if I need answers, I know were to go. We do not know of every single ZWave lock available, and are still looking for a ZWave (preferable ZWave Plus) door knob lock that will work with ISY and take a Schlage key. So far, we have not found one, but it might be out there. The one we are using works most of the time, but does not report status changes to the lock.

@MrBill do you know of a "door knob" ZWave (preferably ZWave Plus) lock that works correctly with ISY and a Schlage key? Thank you.

@MrBill Do you know of a ZWave "door knob" other than Schlage that works with a Schlage key (and ZWave)?

@MrBill Do you know of a ZWave "door knob" other than Schlage that works with a Schlage key (and ZWave)?

@DennisC Does your Schlage FE469CNXV lock report back the status after being sent a Lock or Unlock command? What about if you lock or unlock it by turning the knob? Thank you. I have a call into Schlage Tech Support about the lock not automatically reporting status after a change, but I doubt I will ever get a call back. @lilyoyo1 I already stated we are not replacing the locks as that would require replacing a lot more than just the 5 that don't work. Lots of other mechanical locks keyed the same.

We have done a lot of moving things around and gotten a lot of results that do not make sense. For example, at one point the trouble locks would not work at all going through two repeaters, but would work going through one repeater. We ended up moving the ISY about half way between the locks so both would work at the same time. A wireless connection will NEVER be as reliable as a wired connection, period. As long as it works MOST of the time, and we can check when it does not work, that is all we can except from any wireless connection.

You have a deadbolt and we are having problems with ZWave door knobs. The Schlage deadbolt we have does work reliably. They likely have different ZWave chips and/or firmware in them. While the problem could be our ZWave network, the fact the everything on the network is reliable except these two locks suggests that is not the issue. On another note, we are quite sure Schlage has little to nothing to do with the ZWave technology in their locks. They likely outsource that, which is probably a good thing to some extent. That also mean each time they build a batch of locks, the could source the ZWave from a different vendor. That mean two locks with the same model number could work very differently on the same ZWave network. I have personally seen Dell desktop computers with the same model number and three different motherboards, which makes them very different computers. Having troubleshoot electronics (and other things) for almost 50 years, I can tell you the key to troubleshooting ANYTHING, is to look for what works, not for what does not work. Just last weekend we had bad switch on network that flooded the network making it very difficult to figure out which switch was bad. We took the network down to one switch so it was stable, then added one at a time until it went unstable, then removed the last switch we added, which made it stable again, so we know which switch was bad. Looking for what works, not what does not work, is especially important when there are multiple problems. I am troubleshooting a radiant floor heat problem this winter. Long ago I figured out we were dealing with two different problems, but since part of the systems is built into the floor, making changes to parts of the system is not easy. I think we identified one of the problems this week. We need to get that fixed before we make any more changes. Always change one thing at a time when troubleshooting. What does work on this ZWave network is EVERYTHING except these two locks. We have them to the point that they work over 90% of the time. They still NEVER report a change in status. The Schlage deadbolt we have does report a change in status, even if it is initiated with a turn of the knob. @DennisC, you are correct, we need to figure out the root cause of the problem, and everything points to it being the locks. The locks are on metal doors, which definitely does not help. Thank you for your ideas on this problem.

@DennisC What model lock do you have?

Thanks. I will need to go with 6 or 7 minutes as 3 time outs could make the run time of the program longer than 5 min. I just did a manual Query on a door and it came back unlocked. I sent a lock command and got back this: I sent a second lock command which worked, then a Query command which came back with locked. This is why we need to re-try lock commands before giving up and reporting a failure to lock a door.

Does a wait after a Z-Wave query start when the Query is sent, or when the query "ends" (i.e. a reply is received, or it times out)? The Z-Wave time out is quite long, so this can make a big difference, especially if there are multiple time outs in one program? Thank you.

Thank you. Yes, I understand that the total wait time needs to be less than the every x minutes time. If we do 3 programs (one for each lock), and do repeat every 5 minutes for each program, won't all 3 run at the same time each time, which is what we are trying to avoid? That is why I am proposing doing all in one program. Run program every 5 min, wait one minute between each query. A failed query takes a long time so won't a failed query plus wait 2 minutes x 3 (6 minutes) be over 6 minutes? Or does the 2 minute wait start when the Query is sent vs. when the query "ends" (reply received or it times out)? Thank you, again, for the help understanding ISY.

I think we are differing here on terms, but not the process. The "check lock" is the Query. What I am prosing is using the Query program you provided, but using one program to check 2 or 3 locks with a wait between each query. The "if 'Control door lock 1' is not responding" will change the state variable, and state variable will trigger the 3rd program when the state variable changes to a number >=3. I think we also need to reset the state variable in the 3rd program to 0 if we want it to notify again, right? It is my understanding that the ISY Pro has a limit of 1,024 programs, but there is not a limit on the size of each program. I am also guessing that too many really big programs may fill the memory in the ISY before one gets to 1,024. While we could use one program per lock to do the queries, we are better doing it in one program so we don't go past the 1,024 limit as soon. Also doing multiple queries in one program better controls how we tie up the Z-Wave network with a WAIT between Queries allowing other Z-Wave traffic to get processed between lock Queries. Am I understanding this correctly? Thank you.

Thank you. We need to check 2/3 locks per location, so the wait would be between checking the different locks to let other Z-Wave traffic catch up. We could repeat every 5 min, then in the program check lock #1, wait 1 min, check lock #2, wait 1 min, check lock #3. This way the queries pause and let other Z-Wave traffic get processed before tying up the Z-Wave network again for the next lock query. Am I missing something? Does this mean we need one program to send the queries, then two programs per lock to capture and notify of failures? Thank you.

Thank you for the help on this. Yes, I agree, it is a bad way of doing it, but it is the only way at this time. We have the Z-Wave system stable now so a query only takes a few seconds and we only have 2/3 locks per location to query. We will likely add a wait X minutes to the program above, then query the next lock so other Z-Wave data can be processed between the query requests. How can we monitor and alert if the Query fails to get a valid reply? I have a call into Schlage tech support on this issue, but have not heard back. It makes no sense that the lock is capable of sending the status, but does not send it after it receives a command to change the status. Their "customer service" blames it on ISY, or course, but I don't see how that could be the problem. They will have to convince me of that, and that won't be easy?. Replacing the locks is not really an option because that would require going to a different brand of lock and rekeying a lot more than just the 5 "bad" ones. Thank you for the query program. We could still use some help with the lock/query 3 times then notify if failed to lock program. Yes, I understand that ISY automatically does a retry on the lock command, but lock is important enough that I want more attempts. I have been programming since 1972 (grade school). Once I better understand the ISY programming system I will be the one posting the solutions rather than asking the questions. We have done some very complex things with ELK programming and look forward to moving them to ISY. Again, thank you for your help with this, and for better understanding ISY so we can deploy it to more locations.

Here is another post confirming the Schlage FE599NX does not report back status on changes. We would not have purchased and installed that lock if we knew that, but it is too late now. We are stuck with 5 of them. https://www.amazon.com/hz/reviews-render/lighthouse/B0083GJ1JO?filterByKeyword=smartthings&pageNumber=1 So, we are back to my initial post. How does one send a lock command, query the lock to see if it is locked, then send and query again up to 3 times until it is locked, and send an email if it fails to lock. We just need help with the IF,THEN,ELSE. We can get the email part done. Thank you.

This post says that Schlage ZWave Plus locks will report status. This suggests Schlage locks that are NOT ZWave Plus will not report status. The one Schlage Lock that does report status is ZWave Plus. The two that do not, are not ZWave Plus. https://forum.universal-devices.com/topic/27193-frequent-polling-battery-life/?tab=comments#comment-267901

The locks have been factory reset many times, and we done many excludes and includes. Either the locks do not send the status update, or there is an incompatibility between them and the ISY. The two locks that don't send the status updates, but do respond to a query with the status are: Schlage FE599NX CAM 619 ACC 619 Home Keypad Lever with Nexia Home Intelligence Thank you to everyone for their help on this.

Factory reset on what? We have removed and added the locks and repeaters countless time just to get them to work. Just yesterday we finally got things to work reliably, and they still work today. If we make another change, they may stop working completely.

The issue is simple. The firmware in the lock does not send status updates after a change. We have 3 locks. One does send the status updates, and the other two do not. The one that does is a different model #. Not sure how we can force the lock to send a status update (other than a query) when the firmware in the lock does not do it. A Query is very fast when we have a good connection to the lock. When we don't, it does it up the ZWave network for quite some time. We welcome any other ideas. Thanks.

In this case, the root cause is the looks do NOT report back their status after a change. We can have the ISY two feet from the lock and it still does not report back the status. It simple does NOT report it. We probably need to do a query every X minutes or we won't know the status after someone manually changes it. At this point our primary concern is sending the LOCK command and verifying the door is really locked. We need to know if the LOCK command fails to lock the door.

We purchased an ISY with the primary intention of using it to interface ZWave Locks to our ELK, then found out it can do a whole lot more. We finally have our Schlage locks working (that was not easy), but two of the three do not report back the status after sending a lock or unlock command. They are ZWave, and the one that does report back is ZWave Pro. Being new to ISY, we could use some help writing a program to Lock a door and then query to see if it is locked, then repeat up to 3 times until the lock happens, then send an error email if the lock fails. We can get the error email setup. We just need some help formulating the program to run up to 3 times, then branch out depending on if the lock is successful or not. We would prefer to do all this in one program, but if it needs more than one, I guess we will need more than one. TIA for your assistance with this.

@larryllixthank you for that information. Tracking total run time in a day is something else we are looking to do. For this solution I was looking for something simpler like set counter to zero and start counting when the door opens, and stop when the door closes. Maybe using a WAIT 1 MINUTE then add one to the counter and repeat until the door closes. Again, I can do that with multiple programs, but was hoping to get it done with one program. Thank you to anyone that can assist.

Hello. We are new to ISY, but been working with ELK Products for over 12 years. We are looking for some help to write a program in ISY to have a timer that counts how long a door is open, or an output is turned on in the ELK. We have the ISY connected to the ELK and it is working. The ISY logs shows when a door is opened, and when it closed. We are looking for some help with determining the best way to count the number of minutes the door is open and saving that in an integer variable. For those that have not done much in ELK and are curious, this is how we do it in ELK. We set the counter to zero when the door opens or output turns on, then this code runs the timer. When the door closers or the output turns off, the counting stops. We have it set at 61 seconds rather than 60 seconds because we don't need it to be that accurate, and if too many things are set to run once a minute, then add things set to run once an hour, too much load is put on the CPU on the ELK at the top of each hour. We have another time we put at 59 seconds to spread out the load. The Whenever Every rule in ELK is based on starting at midnight, so 60 seconds would be the top of every minute. I think I can do with with the ISY with a few different programs, but I was hoping to get it done in one program. We only have 1024 programs available, and we do a lot of automation. We have two ELK systems that we can't add any more programming to because they are full. We will be transferring some of the programming from the ELK to the ISY to free up space in the ELK, and lighten the load on the ELK CPU.

The Update Neighbors helped. Thank you. The metal doors are definitely a problem with the locks. We need to be on the inside (non-keypad) side for the Z-Wave to work. What range (how many feet/meters) for Z-Wave should we be getting from the ISY to the first Z-Wave device (not on the wrong side of a metal door) and get a reliable connection?

Thank you Mr. Bill. We will take a look at Pushover.Net.