IT Solutions Posted February 9, 2021 Posted February 9, 2021 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.
Michel Kohanim Posted February 10, 2021 Posted February 10, 2021 @IT Solutions, I don't recommend doing a query. It will cause all sorts of other traffic issues. What I suggest is to get a couple of range extender and then update neighbors. Need to get to the root cause. With kind regards, Michel
IT Solutions Posted February 10, 2021 Author Posted February 10, 2021 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.
lilyoyo1 Posted February 10, 2021 Posted February 10, 2021 1 minute ago, IT Solutions said: 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. What are the details of your setup? Michel is correct in that the best approach is to solve the problem vs a bandaid approach that will cause more problems long term. If you're not getting status 2 feet from the isy then you have a bigger issue to solve and a query will not help that
IT Solutions Posted February 10, 2021 Author Posted February 10, 2021 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.
Michel Kohanim Posted February 10, 2021 Posted February 10, 2021 @IT Solutions, I agree with @lilyoyo1, all locks do report their status unless there's something wrong with them. Did you try factory resetting first? With kind regards, Michel
lilyoyo1 Posted February 10, 2021 Posted February 10, 2021 1 minute ago, IT Solutions said: 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. We gave you an idea but you didn't like it. There are hundreds of models of locks and different ish firmwares & UIs. Since you're not providing any information about what you are using we can't help
Michel Kohanim Posted February 10, 2021 Posted February 10, 2021 @IT Solutions, Please try a factory reset, exclude, and include. I have yet to see a door lock that does not report status. With kind regards, Michel
IT Solutions Posted February 10, 2021 Author Posted February 10, 2021 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.
IT Solutions Posted February 10, 2021 Author Posted February 10, 2021 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.
IT Solutions Posted February 10, 2021 Author Posted February 10, 2021 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
IT Solutions Posted February 10, 2021 Author Posted February 10, 2021 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.
Michel Kohanim Posted February 11, 2021 Posted February 11, 2021 @IT Solutions, Thank you for the links. IMHO, it's best to replace them. Since you cannot get any events from these locks to fine tune the query, then you will need something like the following regardless. The reason is, you would not know when the door is locked/unlocked if they do it manually/physically. If From 12:00:00 AM To 12:00:00 AM (next day) Then Repeat every <you choose the duration> Query the lock Please note the following: ISY retries all commands and puts a lock on Z-Wave communications. So, when this program is run, and if there are communication issues, then no other Z-Wave device can be controlled. Events from other Z-Wave devices are sill captured and put on the queue, but the queue depth is going to increase since the program is retrying. In short, it's just a bad idea all around. With kind regards, Michel
IT Solutions Posted February 11, 2021 Author Posted February 11, 2021 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.
Michel Kohanim Posted February 11, 2021 Posted February 11, 2021 @IT Solutions, I don't think you need a Wait. The Repeat includes the wait. i.e. repeat every minute. With regard to sensing failures, you would need a State variable for each. --> State variable $doorLock1NumFailures If Control 'door lock 1' is not Responding Then $doorLock1NumFailures += 1 Else $doorLock1NumFailures = 0 //notification program If $doorLock1NumFailures >= 3 Then Notify <whomever/> <some-content/> With kind regards, Michel
IT Solutions Posted February 11, 2021 Author Posted February 11, 2021 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.
Michel Kohanim Posted February 11, 2021 Posted February 11, 2021 @IT Solutions, ISY does not work like that ( you can not use a result of an action in the program UNLESS it changes the state of something in the condition). i.e. there's no such a thing as "check lock" ... So, you need either 1 (or 3) programs the sole purpose of which is to query the locks. If any of the queries fail, then Not Responding event is generated for that lock. In which case, the program above is run and increments the number of failures. If the number of failures reaches 3 or more (or whatever you want), then the notification program sends the email. With kind regards, Michel
IT Solutions Posted February 11, 2021 Author Posted February 11, 2021 (edited) 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. Edited February 11, 2021 by IT Solutions
Michel Kohanim Posted February 11, 2021 Posted February 11, 2021 @IT Solutions, You can query devices in the same program BUT the total wait within the repeat can NOT be longer than the repeat duration. So, if you want to wait 2 minute between each, you would have Then Repeat every 6 minutes and 10 seconds Query lock-1 Wait 2 minutes Query lock-2 Wait 2 minutes Query lock-3 Wait 2 minutes Or, you can have 3 programs. It's totally up to you. I would choose 3, because it makes debugging easier (the name of the program points to the name of the door lock). There are no limits to the number of conditions and actions. So, you can put 100s of things inside one program. With kind regard, Michel
IT Solutions Posted February 11, 2021 Author Posted February 11, 2021 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.
Michel Kohanim Posted February 11, 2021 Posted February 11, 2021 @IT Solutions, Not necessarily. But, they might be close to each other. With kind regards, Michel
IT Solutions Posted February 11, 2021 Author Posted February 11, 2021 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.
Michel Kohanim Posted February 11, 2021 Posted February 11, 2021 @IT Solutions, Ends. With kind regards, Michel
IT Solutions Posted February 11, 2021 Author Posted February 11, 2021 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.
Recommended Posts