Yale Security YRD210-ZW-619 - Device Status in UI

[nybble]

Hey guys! First, I'd like to say, great work on 2.1.1. I'm glad my dimmers now update continuously in the UI until their state stops changing.

I wanted to report on the behavior of a device that I had integrated into my Z-Wave network a few months ago - It is a Yale Security YRD210-ZW-619 http://www.yaleresidential.com/en/yale/ ... -deadbolt/.

The device interviews without a hitch and integrates just fine into the network. Responds perfectly to UI commands, locking and unlocking when requested.

The only hiccup I have with the device, is the state of the unit in the UI. Right now for instance, the unit is in the locked position and if I issue an unlock command, the UI will report that the unit is still in the locked position.

The next subsequent command, be it unlock or lock, will update the UI to the units CURRENT state. So, to clarify, if the unit is in the locked position, and the UI reports that the unit is locked, an unlock command will not change the state, BUT the next command will update the unit status to unlocked.

To simplify this a bit, the units reported state in the UI always seems to be the last state the unit was in before a command was received.

When I inspect the server queue, I see status reports are being sent from the unit when commands are issued from the web interface. In fact, I can even see status updates are sent from the unit when the deadbolt is manually turned on the unit. So I know it's reporting back to the server.

Any ideas? Sorry if my explanation is a bit long winded.

Thanks again for all your help!

[bytedreamer]

For many months, I have been using a great module named Niffler from Jens Troest. It can be downloaded from GitHub at https://github.com/jensmoes/Niffler. It sends a get status request whenever the lock is open or closed manually. However, the module should not be necessary when lock/unlock commands are sent directly from the UI.

I was having the same issue you are describing with the latest release of ZWay Server. I had my Yale lock working great with ZWay Server using Niffler. After installing the latest release, the lock's status was no longer updating properly. I suspect that there was a change that affected the timing of commands being sent to the device. There might be an issue with the get command being sent before the set command completes it's action.

I temporarily worked around this issue by sending a second get status command 5 seconds after a status change. The code snippet below is in a function that is binded to the DoorLock.data.mode object. Note the type != 65 condition. It prevents the method from becoming stuck in a continuous loop.

Code: Select all

        if (type != 65) {
            setTimeout(function() { 
                zway.devices[5].DoorLock.Get();
            }, 5000);
        }

[nybble]

Niffler cleared this right up for me! Sorry for the delayed response!

Hopefully, in a future release, we won't need the work around, but so far so good!

[Mike Yeager]

Is this why I get multiple events for some devices?