[BUG] [2.3.4.150] Lock Code Manager Broken

🧰 Built-In Apps and Drivers Built-in Apps
21

I scheduled an enable and disable. The enable worked fine. I'll report back if the disable doesn't work. Otherwise you can assume it did.

BTW, I'm not doubting that some people are having problems. Just another data point that on my lock it appears to be fine.

22

Why? The pin code should be numbers...

23

That looks like something is inserting a line return. Are you perhaps copying and pasting this code into LCM? Or is there some way that LCM may be inserting that line return when it writes that code to the lock? I don't have any experience with LCM, i just recognize that \n\r as a way to force a new line when appending text to a file, etc.

1 Like
24

It's been like that since it was originally set up. That was a code that was initially set on the lock.

That said, I have since reset that particular PIN and this does not show up anymore.

I had a code enable schedule for this morning on 2.3.4.153 and it again repeated the no code added and user deleted from LCM.

25

Nope. That was the original code programmed on the lock.

26

So, to recap:

  • The primary issue is that Lock Code Manager is failing on scheduled enable/disable events. User code is not enabled and User is deleted from Lock Code Manager.
  • This appears to occur starting with 2.3.4.148, possibly at a point between 2.3.4.139 and 2.3.4.148 since I was unable to test every point release.
  • This has been verified by others to also occur on virtual locks, so it does not appear to be hardware dependent.
  • Regarding hardware, code functions work as expected directly from the device page. Failure only occurs with Lock Code Manager actions.
  • Issue occurs in 2.3.4.153.
  • Built-In app has been removed, hub rebooted, and app reinstalled. This does not resolve the issue.

What are @Hubitat_Staff @mike.maxwell @bravenel @bobbyD @bcopeland next steps to fix this?

27

As you can see, Hubitat staff have acknowledged that they are looking at the issue. Calling them out and demanding to know what they’re doing or when they might have a solution isn’t going to make it happen any sooner, and may actually slow them down as they attempt to read every post around the issue to determine if new information is being provided.

6 Likes
28

I disagree with your assessment that this is being actively looked at. There has also been no clear response from staff on that matter. I also did not "demand" anything. In fact, I've been actively trying to troubleshoot this on my own and providing information to assist with resolution. Asking what are the next steps is an active part of assisting with that.

Thank you for your expressed opinions.

29

So....the fact that they've been asking questions and seeking clarification of you for the last 22+ hours doesn't count as actively examining, and tagging 9 staffing members in question shouldn't come over as demanding... Interesting.

7 Likes
30

Thank you for your expressed opinions.

1 Like
32

We will look at this as soon as practical.
I'm running some tests now, takes a few hours obviously...

running build 150, enable and disable on date worked as expected
will update to 153 and repeat tests

10 Likes
33

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.