It would appear that whatever ADC did to “knock loose” the stuck commands has worked. The final test for me, but probably won’t happen until late this week,
Well that is good. The ADC rep I was working with was a bit confused as the status and command acknowledgements shown were not all an expected response to commands sent, as though the panel did not forward them at the appropriate time for whatever reason.
I have no doubt that something was/is fooked with the relaying of commands. What I’m curious about though is where the issue lies since it’s actually a fairly egregious issue that revoked users still had access to the premises. Due to the fact that panel access was working as expected but locks weren’t, I’ll make an educated guess that the challenge lies within the panel and not ADC.
More testing to follow but I’m happy that the state of the system now reflects what I see on ADC.
So I don’t think we’re in the clear yet. It appears that any changes to timed access windows is summarily ignored by the locks. This morning, I attempted to change the access window for one of the previous 24/7 access accounts, it showed updated on ADC but yet on the lock access was uninterrupted.
Hmm. I see 4 active codes, which one would be the one that did not update? (1, 2, 3, or 4) I’ll talk with ADC and see if we can get to the bottom of this. Now that there has been a success and a second failure we may be able to establish a pattern of sorts.
Of the active users, #2 had access changed from 24/7 to restricted m-f, 10a-8p.
I also tested #4 at the lock outside the access window. Both of them successfully opened the front door deadbolt outside the set times.
Try manipulating those codes now.
It looks like this is a new issue that can occur with that lock model and Qolsys. ADC was able to recreate the issue.
It looks like the panel time can fail to sync properly with the locks, and when removing access/adding timed access, all the parameters do not match up to the lock users.
Looks like resetting the panel time through the back-end has a positive effect. I just sent that command, so when you get a chance test out sending one of the codes.
The issue as a whole is being pushed up the chain for resolution, but may require Qolsys intervention.
I’m happy to hear that the issue isn’t confined to my environment. Let me know if you need me to upload any logs from the panel but I’m assuming you have access to that stuff already.
I’ll push some new user access rules tonight or tomorrow and report back.
Thanks for your (and ADC’s) diligence with this. I’m about ready to add another z-wave deadbolt but I’ll probably buy something different this time around. I don’t want the touchscreen in this new location either so that makes it easier to pick something else as well.
Jason, I tried messing with some stuff on Saturday. I first tried the user 4 code outside of its allotted time period as it was currently set and was denied entry as I should have been. I then pushed another change to that user, allowing access on Saturday, waited until it showed updated on ADC and did a network rediscovery. There was no change to the status at the lock, meaning access was still denied at a time that should now have been allowed.
Not sure what else I can do to help this along but it’s broke for sure lol.
Well if you need to provide access, just set up a code for the user, let us know when you do, and we can push a command to sync up the time. You can then test to make sure it is working as intended.
If there are still problems, try changing the code access very shortly after we send a sync command. That seemed to work all the time in testing.
Not sure what else I can do to help this along but it’s broke for sure lol
Yes, there is a strange error certainly occurring. It’s been replicated so the issue can be worked on independently of your system. We’ll be following up on the issue, but it looks like it may need firmware intervention. Can’t say for certain yet.
Ok, I’ll let you know if I need to make any changes to existing or to add users. I hope it doesn’t take six months to remedy this though as it appears to be a fairly egregious bug. Then again, this is Qolsys and they update firmware fairly frequently from what I’ve seen.