Interesting, so it appears something about how it returns the result for zid changed in HE from 2.2.3 to 2.2.4.
I have no idea if that is something we could work-around here.
Any idea @csteele?
@bcopeland - The z-wave lock updates in 2.2.4, is there something there we should be considering that could have broke this we need to work around?
Also. Go Sounder!! STH living in Bellevue.
"zid" is an internal-to-this-app construct. Hubitat (the Platform) doesn't have a zid to do anything to/at/about.
I don't own any Ring... thing. So I can't install this app and drivers and hope to get some results. However, I did take a journey through two pieces of code on Github and determined that "ring-api-virtual-device.groovy" has the task of initial creation of zid. The "refresh" option will re-establish it, apparently. Again, because I can't really install this, I am forced to just assume there's a Refresh button on the Device info page.
Maybe the inherent reboot of the Hub during an upgrade didn't resync perfectly and a manual reboot might be helpful... it's just a WAG from me. 
I tried the refresh a few days ago with no luck. I did hit it again just now and it does show in the logs and looks ok. When I go back and hit a lock/unlock I still get that warning from earlier with no zid etc. In the logs it also appears that this refresh actually runs automatically around 6AM every day. Still confused on the zid being null. I see a value in the refresh for the lock and in all the other status updates coming from ring on sensors.
Refresh of the lock log:
dev:332020-12-01 11:11:44.444 am tracecreated deviceInfo: {
"deviceType": "lock",
"src": "91619758-c723-4812-614f-7264f36d9752",
"msg": "DeviceInfoDocGetList",
"eventOccurredTsMs": null,
"level": null,
"affectedEntityType": "asset",
"affectedEntityId": "91619758-c723-4812-614f-7264f36d9752",
"affectedEntityName": null,
"accountId": "e20aa99e-1fe1-4998-8436-a8405e3c0cf5",
"assetId": "91619758-c723-4812-614f-7264f36d9752",
"assetKind": "base_station_v1",
"lastUpdate": 1606849726554,
"lastCommTime": 1606849724841,
"nextExpectedWakeup": null,
"adapterType": "zwave",
"zid": "b91dce4e-d22f-46a3-8c55-a2cccc39c139",
"roomId": 9,
"serialNumber": null,
"fingerprint": "144.3.1088",
"manufacturerName": "Kwikset",
"tamperStatus": "ok",
"name": "Back Door Lock",
"acStatus": null,
"batteryLevel": 90,
"batteryStatus": "full",
"componentDevices": [
{
"rel": "0:access-code",
"zid": "c0e6eb26-1c8e-4e56-9b11-380007e836d3"
}
],
"signalStrength": [
{
"nodeId": 1,
"quality": "ok",
"rssi": -82.0,
"status": "valid",
"zid": "4ce2e64c-e7bf-422f-a76e-3820f8db3bd3"
}
],
"firmware": "4.10",
"hardwareVersion": "4",
"deviceName": null,
"roomName": null,
"state": {
"locked": "locked"
}
}
Another idea. Does someone have the exact zwave command I would need to send to make it work? perhaps hardcoding a command would allow testing of a few of the missing parameters. I am not sure of the exact commands to send.
Does the virtual lock device show a 'zid' in the data section of the hubitat device page?
I noticed that when addChildDevice is called in ring-api-virtual-device.groovy that it passes in a bunch of unsupported things (zid, fingerprint, manufacturer, serial, type, and src) to the properties arg. I wonder if previous to 2.2.4 that these extra args just became data values for the device and now those improperly set values are being cleaned up? I think that the appropriate way to set these would be to use updateDataValue.
I have this RING||b91dce4e-d22f-46a3-8c55-a2cccc39c139 and if you drop the Ring part it seems to match the zid I get when I refresh the device. null when calling lock/unlock. This seems to be it but I am not reading the code.
As I was reading this... I wonder - are we actually sending a Z-wave command to the device? I was thinking that we are sending a command to the Ring Hub which initiated a Z-wave command to the lock. But I really have no idea...
Is this something that @roblenderman or I could test out? Is there a line of code we would need to change to try it out?
Before doing that, someone on 2.2.4 should take screenshots of the lock devices pages. Specifically the data section. If the data fields are missing, then we could throw some code together.
The ring integration linked on this page is definitely not sending any Zwave commands.
yeah realized that as I said it. What is odd is that on the dashboard when I click the icon to lock/unlock it spins for many seconds before coming back to the original state. like it is waiting on an ack but never gets it
Yep, that's what I needed.
That looks very wrong. Let me throw together some code you can try out.
There is a zid in the signal strength state variable. I have one in mine as well.
Correct, but that's not where the code gets the zid from.
Oh, I just checked the same on my 2.2.3 hub, much more data there!!! (zid, serial, src, fingerpring, hardwareVersion, type, firmware, manufacturer). Wow!
Try using this code for the ring-api-virtual-device.
After updating the code, run a 'refresh' on the ring api virtual device. You should see a bunch of warnings printed. Then try locking/unlocking one of your locks.
Yup! That fixed the issue!!! And I did get all the warnings...
Is this a fix that should be ported to the main code branch? Or is this just with hard coded information for a temporary fix?
Download the Hubitat app
