Yale lock not respecting Day of Week programming

[calbear]

Hi all,

I've used the Yale 4Store application to set up several users and assign day of week access logic for a few of them (ie. their access code should only work on say Tuesday). This morning (a Tuesday...) a user's code would not work at all; it triggered the tamper alarm after several correct attempts. But after I went into HE and the 4Store app to confirm the programming it suddenly worked again.

Now here's the rub, the lock is now allowing that user's code to work any day, as if it's ignoring the day of week filters. I turned on logging in HE and used the Log User Database action to see what the lock has for the users in the DOWMask field. And what I found is that the correct 0s and 1s are set in the day of week array, so changes in the 4Store app appear to be sent/stored in the lock correctly. But across all of the users, it doesn't seem to matter now whether users are turned on or off for access any given day, the lock ignores that logic and will still work.

I contacted Yale, but they said it was a software/Control4 issue. (I could certainly be wrong, but I'm not 100% sure it's only C4 since the user access data is getting into the lock, and I assume it's the lock that has to run the access logic locally...)

Thoughts on corrective actions to take? Should I wipe it to defaults and just start all over again? Any other ideas on what could be going on?

Thanks in advance!

(I should add, I have two locks - one touchscreen and one deadbolt - that both exhibit the same behavior. So this seems to be a driver or systemic lock issue, not just a one-off, single device failure...)

[zariaman]

I had a very similar issue about a month ago. I only have one yale TS on front door. The issue got resolved after refreshing events. Try doing that and see if that works.

[calbear]

After further experiments, including refreshing from composer as well as the "refresh events" action in the driver as suggested, it looks like the lock is respecting the "time of day" masks but not the "day of week."

My experiment looked like this:

User 1: Allow Wednesday, all times -- lock opens today (Wed.)

User 2: Allow all BUT Wednesday, all times -- lock still opens today

User 3: Allow Wednesday, 2-3p -- lock does NOT open at 11:30a

User 4: Allow Wednesday, 11a-3p -- lock does open at 11:30a

Since I can pull the user log from the lock itself, I know the DOWMask settings are getting into the lock correctly (eg. only allow on Wednesday is 0001000). (Note: You can tell the lock to dump the logs into Composer and then view them in the Lua programming window.

Sigh...

[turls]

As posted in some other threads, they are supposedly going to come out with a driver update but there is no indication when, and previous guess timeframes have come and went. Not sure what the holdup is.

[calbear]

Thanks for the input Turls. So you're saying this is a known bug?

[turls]

No, I'm saying we are overdue for something better than a 1.0 release on something like this and I'm getting a little frustrated since I have 4 of them (2 touchscreen, 2 button). I don't know if mine have this issue or not.

[Jobu604]

I am having a similar issue, though it seems to treat different users differently. Dumb question, if a day is white with yellow border then that means it should have access that day, right? Whereas if it is grey it should deny access?

I have one user set up for access Monday to Friday between 7am and 7pm assuming the above is correct, and it seems to work. The weird this is, I have another user who should only have access Thursdays - it only seems to work when Thursday is greyed out.

[RyanE]

I can never see from the UI whether the days are 'selected' or 'not selected'. The rest of their UI I find brilliant, but that 'setup days' part I find supremely confusing.

Not that I'm known for making good UIs...

RyanE

[calbear]

From my read of the driver and documentation, greyed out sends a "0" while white with yellow box sends a "1." The 1 is supposed to represent a day of eligible access...but that's the function that seems to be broken. Whether a user has 0s or 1s, on my end the lock works with the user's code any day.

[AK1]

I did get this working, eventually, at a client's location. It turns out the UI is supremely counter-intuitive for day of the week control. See the attached image from my house - Boys and Parents get access all days of the week and Cleaners Thu only.

[calbear]

Thanks for posting the image. That's consistent with my read of the driver too. A white box with yellow outline sends a "1" to the lock (which means the day is authorized), while a dark gray box sends the "0" for no-access that day.

Now if only the lock would honor those values in its decision making!

[AK1]

Hmm as far as I can tell my day of the week filters are being parsed correctly

[calbear]

On my end, I ran simple tests with different users having a given day on or off, and after "refreshing" everything I could find, both of my locks would still let all user codes work on that day. Yale told me to talk to Control4 though if the driver is passing the 0s and 1s correctly, isn't it the locks that are having the problem? Of course C4 will tell me to go through my dealer who frankly will just have to go back to C4 too. :-)

[Jobu604]

I did get this working, eventually, at a client's location. It turns out the UI is supremely counter-intuitive for day of the week control. See the attached image from my house - Boys and Parents get access all days of the week and Cleaners Thu only.

I have two users set up for all day access and it works fine.

For my cleaning lady I only want her to have access on one day of the week but the only way it works is for that day to be greyed out and everything else white with a yellow border. Go figure.