Sending HTTP commands to a ZWave Thing (Yale Lock) shows as 'pending' in HabMin

Hi All,

I see this as pending, for all user labels and codes configured. I configured 3 codes, 2 works and 1 does not.

Does anyone know why this occurs? It occurs randomly. On some occasions, all codes when programming the lock work just fine. Then sometimes, it wont do one correctly. I cant explain it.

I did a test program of a user and looked at the zwave log and tested it, worked fine.

I could see the code being sent etc (which surprises me as I thought it was encrypted). @chris is it possible that commands sent to the thing are not accepted or rejected, and if so, how could I determine thats occuring?


These are configuration parameters and not commands. This happens because the ZWave binding marks them as pending until it gets a response from the device - this is to provide some visibility that the request is still queued which is especially an issue with battery devices that normally sleep.

Once the read-back is received the pending flag is removed.

It will be encrypted, but the logfile also logs it unencrypted to allow debugging.

Hi Chris

Thank you. Thats odd though.

Lets say ive sent some configuration parameters, 3 user codes and 3 user labels. They are all shown as pending, however 2 work on the lock itself, 1 doesn’t

Why would that be? How long would I expect for something to be pending? I configured a code about 14 hours ago, it still doesnt work and is showing pending. The other codes, some configured only minutes ago, work just fine.

Im trying to get an interface to program the lock, which is working 95% of the time.


I don’t know - it’s really hard to just guess here. Have you checked the logs to see what is happening?

1 Like

Ill have to get a log of every single user creation to see if I can capture one of them failing…

Hi chris, ive attached a log of the time frame I created the user, this looks OK to me though. I need to be home to actually verify if the code was programmed successfully or not by trying it on the actual lock.

The lock is node 35lock.log (1011.8 KB)

I did notice that Node 7 was sending its power values constantly, overly chatty, so i’ve stopped that.

Thanks. Can you confirm what happened - ie what you see in HABmin?

It looks like you set code 5, and this was set, and read back ok, so the pending flag should have been removed. I do note that it was set 3 times - probably because you are sending multiple commands in very quick succession, so maybe there’s an issue with the detection of the readback. Probably you should also avoid setting this parameter to different values so quickly as well as that can’t be right (ie you set the code to different values within a few milliseconds).

HI Chris,

I set code ‘1234’ in slot 5, yes. How this is done is via a javascript file called via Habpanel, where we have a widget created with fields to program codes. This avoids using PaperUI or Habmin.

This is what HabMin shows

Now that is odd, we only set the code ‘1234’ once. Where in the log does it show being sent multiple times in quick succession? Potentially it’s the ‘way’ it’s being sent. I can put some more information as to how we send that.

I’ve made a change that will hopefully fix this.

Hi @chris what’s changed ? We couldn’t find an issue in our code. Ive upgraded to the binding as per Build #622 which I assume has your fixes. Id be very interested to know whats changed or what you found may have been problematic

Just the handling of the label - the pending flag was also set when the label was configured. Since your problem is just that the pending flag is set in HABmin, that should stop this.

Hi Chris i thought you said there were issues with the data being sent multiple times? I couldnt find evidence of that though or that it was sent in very rapid succession