I recently set up a new user in my system with time restricted access (all days, 10a-10p) however it doesn’t seem to be working as advertised. If I leave the restrictions in place, the code never works. If I turn access on for all times then it works fine.
How do I do this so it works?
Is this access intended for the panel or for a door lock, or both?
How are you testing the access? Are you arming and attempting to disarm using the code? (or locking/attempting to unlock?)
A couple things about the creation process, codes are active on the days that are darkened, and when selecting a time frame, when you select a starting time, the end time changes to one half hour after the start time (to avoid accidentally setting start time after end time.)
So if you make a change to the start time, make sure to re-check the end time.
Any of these a possible culprit?
The user is intended to have access to locks and panel. Shows that way under the users tab. Access is set for 10a to 10p, seven days a week. Just verified that on the ADC site again and it’s set up as you describe it should be.
The test was an attempt to unlock using the new code. It just fails with the error sounds on the deadbolt. Didn’t try the panel since they can’t get to the panel without first unlocking the door. ADC shows green for the code being transferred to the hardware.
As a test, can you try creating a user with access for 23 hours a day, every day. Just leave one hour of no access. Wait five minutes, then try the code at the lock.
I’ll try that this evening and report back then.
Ok, I set up a test user code active from 12:30am to 11:30p. Shortly after 11p, I tested it on the front door deadbolt and it worked.
Alright, I thought so. I have seen it exactly one time before, but I think your deadbolt may not have received the proper clock info from your controller when set up. Timezone is likely set for a manufacturer’s timezone on the internal clock.
To fix, remove the lock from your panel and re-add (make sure it is close to the panel) then run a network rediscovery.
You should be able to send timed codes that work properly then. The lock gets its clock set when connecting to the controller iirc.
Interesting. I’ll give that a shot and let you know what happens. It may be a day or three until I have the time to uncounted the locks or the panel to bring them close together to do the deed. I wonder if that ties into the battery life challenge I’ve had with them too.
OK, so I did this and it was a nightmare. I had to remove the deadbolts from the doors and bringing them to the panel to learn in since the Qolsys panel won’t give access to either WiFi or Home Control when it’s on battery power (I first tried to bring the panel to each of the doors to do this but nope).
I removed the devices from the network, removed them in ADC, re-added them to the system and let them sit quite literally on top of the panel for five minutes each. This should satisfy the whole time and proximity requirements that they have for communication of initial information.
I then resent my users to the locks and made sure they all took per the ADC web page.
Guess what? Didn’t change a thing. The two users with 24/7 access work, the user with now six day (Mon-Sat) access 10a to 8p didn’t. Unless the lock manufacturer’s time zone is more than 4 hours from PDT (doesn’t make sense, Yale is a US company) then this theory is busted since it was 3:51pm local when I tried this.
You should be able to see in my system log the back door tamper set at 3:51 PM.
Also, the user with timed access works just fine on the panel.
What next? I’m not giving the maid 24/7 access to the house and I sure don’t want to go through this process again 
Without going through the process again, we can do a couple more tests to narrow it down. If you create a new user with access for 12 hours, say 10pm to 10am, try it at 4pm, well outside of the time period. Then at 6, etc. Can verify whether it is giving access at the wrong time (due to lock or something else) and go from there.
OK, I’ll give that a shot next and report back.
User created per your suggestion of 10p - 10a the following day.
OK, here’s an update and it’s not happy fun times.
First I limited the access to my user (Test User) as reported above (10p - 10a). That user gained access via the deadbolts at the following times:
6:24 PM
8:15 PM
11:50 PM
8:52 AM
11:03 AM (after deletion from ADC)
Note the last bit. I was concerned that maybe the user was stuck in the lock from previous testing, so I deleted the user from ADC and was given a stern warning that this would remove all of its access…was I sure. Test User was deleted and a new user (Lock Test) was created.
After the deletion, Test User had, and still does, have access to the locks. In addition, the ADC website never showed that the new user had been accepted by the locks but some time later, access was granted. Lock Test has access from 8p to 8a but at 12:29 Pm it was able to open the locks.
ADC website still shows no access to locks for Lock Test but it works and Test User is eliminated and it still works.
Is any of this helpful? More importantly, why are user adds and deletes apparently misbehaving?
Another update, just tested both users, the one that’s been deleted and the one that’s supposed to be out of the time range and both worked to unlock the doors at 4:14 PM.
Is there some way to send an update from the backend that would clear out dead users? I find that even more disturbing than users that don’t work when they’re supposed to and vice versa.
Also, the user with timed access works just fine on the panel.
Did panel access get added and removed correctly when you were testing the codes with the new user?
If the panel is getting the commands and revoking/adding access as directed, then we are left with a very likely local communication/lock issue.
If you did not test the user access at the panel, can you do that at the same time as the locks?
It may come down to trying a factory reset on one of the locks and seeing if that makes a difference.
It looks like there are a couple locks on the account. Have both behaved the same way throughout the testing?
I need to test the panel access although I didn’t grant it to the test users, locks only. Also, note that adding a user went to the locks OK but removal didn’t. Not sure what that says about communications. Also, I looked at my zwave stats and there were thousands of ack OK without a single instance of errors. All the nodes see each other as neighbors too so while it’s possible that there a comm problem, and I’m not discounting that, the absence of errors logged or any nodes not communicating with others don’t lend much credence to that theory.
Yes, both locks exhibit the same behavior.
I would first verify that codes work correctly when sent for panel access. If so there are a couple more things to try.
I’ve spoken with alarm.com techs, and they sent a few commands and noticed that some additional automated commands used to sync devices had gone through (seeming knocked loose so to speak with the status updates) so they recommend running a network rediscovery and trying a new user.
If this does not work, it looks like they recommend a factory default on one of the locks. (I would recommend the same myself, unfortunately.)
Just try one for now to determine whether any improvement is found.
I can tell you that the original user that prompted this discussion did work properly at the panel during the prescribed times. It was only the lock access that was displaying an issue. Further, when I set that user to access all days all hours, the locks work fine. It’s only when it was set to a specific day/time schedule that we saw malfunctions.
I can add a new user and delegate panel and lock access to test. Resetting a lock to factory is way more of a time sink though.
I’m disappointed that there is no error logging or explanation as to why a user removed completely from my ADC account still had access to open locks while new users can simultaneously be added. This sort of asynchronous communications error that’s being claimed makes no sense at all from a hardware or environment standpoint but rather smells like a software issue somewhere, either with ADC or perhaps with Qolsys.
Let me point out too that the original user that kicked this off has no issues with being updated both to and from all access all the time. When I change her access, things change at the locks.
I’m disappointed that there is no error logging or explanation as to why a user removed completely from my ADC account still had access to open locks while new users can simultaneously be added. This sort of asynchronous communications error that’s being claimed makes no sense at all from a hardware or environment standpoint but rather smells like a software issue somewhere, either with ADC or perhaps with Qolsys.
Without being able to see and dig into the command data, you are right, it does seem to be software related. I do not intend “Communication issue” to only mean signal quality. Something about the transmission from ADC to Panel to Lock is causing a miscommunication, or the lock does not get everything that was originally sent by ADC.
What we have to go on in a previous case example showing similar problems is what makes me still believe the locks are the ultimate hurdle here. That’s not to say a software error from panel or ADC is impossible, or didn’t have an impact.
Ultimately we need to rule out a factory default and prove the behavior exists after, or, better yet, resolve the issue with it.
The problem with analyzing error logging is in being able to view that data. This is limited by what the panels transmit.
Unfortunately a lot of it is treated as proprietary by the manufacturers. With Qolsys though, we can upload logs to them for review. It’s not guaranteed they would be able to assist in this scenario, but if we can rule out the possible fixable causes, it is an option.
Let me point out too that the original user that kicked this off has no issues with being updated both to and from all access all the time. When I change her access, things change at the locks.
This is true of the case I am referring to as well. 24 hour access showed no issues. Timed access gave access at incorrect times and had trouble being acknowledged at the lock.
Fair enough, I just wanted to make sure that we were looking at the stuff that makes sense and moving past signal problems.
I probably can’t mess with a lock reset until Friday at the earliest just due to my work schedule and the time needed to do the panel dance.
Here’s today’s update. Prior to doing a network rediscovery, I tested the disabled users on the panel and both of them failed. Testing both disabled accounts at the locks resulted in successful openings. The original guest account is still enabled 24/7 and still works at the panel and the locks.
I did a network rediscovery and then added yet another test user on the ADC site. That new user is enabled 10a to 9p. Testing the new user at the panel and the locks worked fine. That’s new good news since previous attempts at setting daytime access had failed.
In addition, the previously deleted (one account) and disabled (one account) users no longer work at the locks.
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, would be to remove my latest test user to see if it goes away from the locks and also to reset the maid’s access to a more appropriate window and make sure that works.