Kwikset SmartCode 888 - error when attempting to update User Codes

Yes, I’ll take a look. I don’t know how the architecture of the bindings work, but I am assuming that the binding code is data driven by the database for that device. So, if the database is updated and approved and merged into a build, that will change how the the device behaves. Do I have that right?

Yes. Worst case you may have to delete the thing and add via inbox once you have the snapshot binding with the fix in your addons folder.

At a high level the Zwave binding is comprised two parts 1) java classes that process messages and do all the computing work, etc. That part hasn’t changed significantly for several years and is rarely, if ever the issue. And 2) static XML files extracted from the device database. That part changes about twice a week as new devices are added and/or old devices are changed (snapshot builds).

Bob

1 Like

Ok, the device DB is definitely wrong for the two SKU fields, but I dont think they really are used for anything. I can make updates to correct them.

I am confused how the User Codes get into the DB. They aren’t listed in the Parameters section. There is an Endpoint called COMMAND_CLASS_USER_CODE_V1 … but I dont see how that may translate to the 30 fields for the User code and label for the 30 slots. Are you familiar with how that works?

I’m afraid not. I do not have the device or anything similar.

Bob

That is not required for a simple parameter change since it’s not part of the thing definition in your system. The “delete and re-add” requirement is because OH stores the definition of the channels once you create it, but this is not the case for configuration.

1 Like

They are managed directly by the binding and not part of the database.

1 Like

Ok here is some more info that might help. I am doing the following:

  1. From the config UI: Entering a code and a label in the next unused position in the user code list of 30 items.
  2. Hitting “Save”

Result: Code field shows the correct value but “Pending” forever. (The label field doesn’t show “Pending” and is correctly updated)

  1. From the config UI: Enter a value of “1” in the code field (that shows Pending.
  2. Hit “Save”

Result: Pending disappears and the Original code written in step 1 shows up.

I repeat this using the REST API with a python program I wrote. Same thing happens. By looking at the Config UI, I see the code value that I wrote using REST with “Pending” next to it, the label doesn’t.

Then using the Config UI, I enter a 1 in that user code field, hit Save. Pending disappears.

Very repeatable.

I think I’ll reset the device to factory defaults and retry this and then post the logs.

So being late here and generally results oriented personality; Does the lock open with the code (even if the UI shows pending?) Maybe the lock needs to have the code entered on the device once to clear the pending? Does the lock open with the code after adding “1” and clearing the pending? Does this work process work on the second code line? If yes you have a quirky but working lock :wink: Case closed?

Bob

I would really suggest to get a debug log to see what is happening. The pending flag in the binding should not be anything to do with setting a code in the device to or anything like that - it just means that the binding thinks it has not transferred some configuration to the device, so that configuration is still pending.

Normally for locks and mains powered devices, this should clear quite quickly (depending on exactly how many configuration parameters have been changed). Enable debug logging, then change the configuration and see what it shows - otherwise it’s really guesswork.

Answer: Yes.

The device accepts the code. Re-entering the code gives an error (expected) for duplicate code.

Yes. The lock still opens with the code that was set. The 1 is ignored because it must be at least 4 digits. I’m not sure where that check is made (UI or Binding)

The “Pending” behavior is the same regardless of whether the actions are done. i.e if I attempt to write a “1” via my python code, the UI briefly shows the “!”, then the original code returns and Pending disappears.

I think the lock is behaving as it should.

Edit: And of course, I can do that extra writing a “1” in my code to get rid of the Pending, but I assume we want to understand why this is happening so we can solve it the right way.

Yes, as I said above - I would need to see a log to understand this -:

1 Like

Ok, sorry, had a bunch of other unrelated shit to do … here is what I did:

  1. Reset the unit to factory defaults. (interesting side note, although the lock is cleared, the binding still showed values for the user codes from previously).
  2. Cleared all the user code entries in the binding to None
  3. Got it into the repeatable state of: a) Writing a 4+ digit code value, hitting save, seeing “Pending”, then writing a “1” to that same code slot and hitting save: Pending disappears.

So once, it was in that state, I turned on log:set debug org.openhab.binding.zwave and log:set debug org.openhab and did the test. The log was scaled down to the period that I ran the test.

debug888.log (146.8 KB)

Not sure if its related, but after the factory reset, the SKU fields (params 33, 34) were reset back to some large number. When I initially tried to write a code and hit save, nothing happened … when I clicked “show advanced” and entered small numbers into those fields, the “Save” button started working (meaning the UI would say “Thing Config updated”).

Anyway, let’s see if the logs are helpful. @chris

Please can you provide a log where you do not do this - just set the code. We want to see why the pending doesn’t change back, and updating the code again a few seconds after it is set the first time means I can’t see what’s going on.

In general I don’t see anything wrong here though - the codes are being set and read back ok, so it looks like in general everything is ok. There might be a bug in the binding for user codes, but at the moment what I see if your second “set code to 1” is at almost the same time as the binding is requesting the update that should remove the pending flag, so I don’t know if it’s the response to that, or something else. (the two things are less than a second apart).

It may also be that I need to add more debug into the binding to work this through further since from the quick look I’ve had, the code looks ok. It’s not super easy to just read the code though and I need to see what’s happening.

Anyway, let’s start with the log where you just set the code once and we’ll see what that shows.

Just an FYI - this is the relevant part of the log -:

Your first setting of the code - the code is set - sent to the device, and an update requested



Your second update -:



And the final confirmation -:

Given that the code is set to the first value, I’m assuming that your second code of 1 is invalid and rejected by the device as it returns the first code.

Again though - I need to see the log without this second command (and again, I’ll likely need to add more debug into the binding anyway).

Ok, I can get the log, but I’ve waited 24 hours before and it never changes. I’ll run the test and then look for the next NODE 16 activity.

Ok, here is a log where the process fails. I will add that it doesn’t always fail, and I’m not sure what is different when it doesn’t fail. And I’ve also discovered other behavior that is a little concerning.

First, the log: I’ve paired this down to the starting point when I hit “Save” at ~9:09 … then I waited a while… The Binding is still in the Pending state 45 minutes later. There was zero more NODE 16 activity after about 16 seconds when the last log entry related to NODE 16 is:

2021-10-12 08:09:16.402 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2021-10-12 08:09:16.403 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2021-10-12 08:09:16.404 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

Where it appears that it is done, although it’s still in Pending on the UI.

Here’s the full log:
debug888-2.log (89.2 KB)

The seconds thing is that in my testing I found that using the “X” on the far right side of the UI to clear the contents and then hitting “save”, looks like it is clearing the contents. But in fact the User Code is still in the device. The UI shows that User Code to be blank, but it’s still useable at the Lock. This could cause some major confusion by users. I did find that by put some “spaces” ie. char 32 in the User code field, then hitting save the code is in fact erased.

Edit: I forgot to mention, in earlier experiments changing other User codes had no effect on the Pending User Code. For this log, it is just the one User Code being set and I didn’t do anything else.

One random test from the cheap seats :wink: Set the Command poll interval to zero,


then try to set a code. Does it show pending? If it works I’ll explain why. If not, sorry for the wild goose chase.

Bob

Well, still showed Pending :frowning: … what was the theory?

I’m not suggesting it will - I just wanted to see the log of what is happening - without a second bunch of configuration commands making it difficult to see what’s going on.

This has nothing to do with configuration - it’s only for polling the state after sending commands - not parameters.

It was wrong :frowning_face:

As a rule, I have observed that zwave plus devices send a REPORT in response to a SET command (like I thought the code was) and that the binding was also sending a GET (command poll for a REPORT) and the REPORT from the device had different Nonce than the REPORT from the binding GET. (Callback 203 in your first log timed out after reporting non-valid NONCE (not the one the binding was expecting).

The reason I thought your second SET cleared (the pending) was because the device did not send a REPORT (as nothing was changed) so the binding GET generated REPORT had the right NONCE and the Pending was cleared. It would have made more sense if it worked :wink:

Bob

1 Like