Thank you so much. I was in that area but I would have never figured that out. This is perfect. I have been banging my head against the wall for the last couple of days trying to figure this out.
1 Like
Happy I could help! You will find that there are A LOT of very knowledgeable people in this community (I don't count myself it that list yet... but sometimes even I can help!), and that it is very active... So don't hesitate to ask when you have questions!
2 Likes
Having the same issues with locks. The status stays in sync on my dashboard but I cannot trigger a lock or unlock. Worked a few weeks ago. Sensors and floodlights work. Just locks are broken. My guess is a message format changed. Still researching.
@roblenderman, what is your Hubitat firmware number? When you try to lock or unlock, does the alarm system become unavailable from your phone or the Ring.com web site?
See my related description above:
I discovered something new about Ring Connect's Hub Firmware version 2.2.4 issue where sending a lock command crashes the Ring Hub.
To bypass the issue, I decided to setup a HubConnect connection from the 2.2.4 hub to the 2.2.3 hub, thinking that having the .3 hub send the command via HubConnect would allow me to resolve the locks issue introduced with 2.2.4.
Unfortunately, it did not. Sending a lock or unlock command to the .3 hub via the .4 still crashes the Ring Hub.
@csteele, I with the expertise you have regarding HubConnect, would you be able to understand how sending a command from a 2.2.4 hub to a 2.2.3 hub ends-up with sending some extra 2.2.4 stuff (sorry for the highly technical terminology... 
) to the device? I would have thought that the command sent to the Ring Hub Lock device would use the 2.2.3 commands (be the same) regardless of if it was sent directly from the hub or via HubConnect... (Note: The result is the same when connected via Socket or HTTP.)
Some background... Sending a lock or unlock command to the Ring Hub from the Hubitat Ring Integration (Unofficial) running on a hub with firmware version 2.2.4 crashes the Ring Hub and doesn't lock or unlock the lock. Sending the same commands (directly) from the same hub with firmware version 2.2.3 either locks or unlocks the lock as it should - no issues. Unfortunately, the original code author no longer takes care of it and the cause of the issue is not yet known.
Although it's a user app, I wonder if @gopher.ny or @bravenel might be able to shed some light on any http or other ip changes in 2.2.4?
2 Likes
Seems 2.2.3.x worked and 2.2.4 doesn't. I tried rolling back to my latest 2.2.3 backup but it's didn't seem to work so I think it might be an issue with a later 2.2.3.x version and not 2.2.4. I blindly updated the post few weeks and it seemed to stop in early November.
When you say rolling back to your 2.2.3 backup, did you also roll black the firmware / Platform Version?
I have a hub that I downgraded from 2.2.4.X to 2.2.3.148 and on that hub, it works perfectly well after the downgrade. When that same hub was on 2.2.4.X, the locks didn't work through Ring Connect.
Using Socket, HubConnect on the 2.2.4 hub is not involved, EventStream will contain everything. You push a button on the Device Info page, the stream contains that Event. The Hub listening, your 2.2.3 hub would 'hear' the event on the LAN and stuff it into the Event Processor. ( sendEvent() )
That would get processed by v2.2.3 and handed to the Device Driver to be performed. The 2.2.4 Event contents would arrive on the v2.2.3 hub and be interpreted by that driver. An Event is small and not full of options, so I'm not sure what 'new' got added. You can use a WebSocket client to just listen into the EventStream... I do.. pretty often too, actually.. and see how bland it is.
{ "source":"DEVICE","name":"motion","displayName" : "MultiSenDomeU (office3)", "value" : "inactive", "unit":"null","deviceId":840,"hubId":0,"installedAppId":0,"descriptionText" : "MultiSenDomeU (office3) motion is inactive"}
That's from a Mac tool available called WebSocket Client. There isn't a lot in an Event that's particularly interesting. Value and Unit are the most likely things to matter to the driver... in other words, most everything else is just there to identify what driver gets the Event, and the driver's likely to only care about value = Lock or Unlock. Unit should be null, but even if it isn't, the driver should know not to care and just discard it.
The WS Client tool will display the event as either Raw (above) or JSON formatted:
{
"deviceId" : 1448,
"displayName" : "KidsRoom Fan Module",
"value" : "539.53 Days",
"hubId" : 0,
"source" : "DEVICE",
"installedAppId" : 0,
"unit" : "null",
"descriptionText" : "KidsRoom Fan Module energyDuration is 539.53 Days ",
"name" : "energyDuration"
}
Obviously not the same event, but that's the point, there's not much in an Event. I don't remember seeing "hubId" or "installedAppId" before, but they seem to contain nothing of value either. Maybe that' 'tripping' the driver?? Fields it's not expecting, even if those fields are worthless.
I used the "backup and restore" section of settings. Looking back at it I think I only went from 2.2.4.141 back to 2.2.4.139. I didn't have anything old enough to go back further. A few weeks ago my wife said the door was not locking at midnight. I use RM 4. I looked and could not see a lock in the history. I had been blindly upgrading and remember a few upgrades to the firmware and everything seemed to work just fine but since I go to bed before midnight most nights I didnt notice the locks not working. It had worked for months and I don't recall any firmware upgraded in Oct. Something from Nov as far as I remember.
When I use backup and restore do I ALSO need to roll back the firmware? It seemed to show an older version in the rollback so I assumed that occured during the restore. I also noticed my Ring was offline/stuck after trying some lock commands. I had to unplug it to make it work but have not had a problem in weeks even though locking still does not work. Odd thing is the dashboard shows the right status within seconds of me locking the door manually/Alexa/Ring.
Seems I do need to roll back the firmware AND the config. I only did the config. The table with backup info is not clear that the firmware will not be rolled back. Listing it there is a bit confusing at first.
So if I understand this correctly, the 2.2.3 hub just sends the event as received from the 2.2.4 hub - this would explain that the issue remains there.
I think that would be a great way to identify the difference in the messages. Unfortunately, I don’t know what program I could use on the PC to do listen to the EventStream (This is something I have never done...).
If anyone knows of a good and easy to use tool to do this on the PC, I’ll try to see if I can see the message coming from both a 2.2.3 and a 2.2.4 hub to identify the difference. I’m hoping that with this information in hand, either someone can make a tweak to the RingConnect driver for the Door Lock, or if there is a Hubitat issue, it can be brought to the attention of whomever can do something about it...
That would be very possible! @ardichoke, any idea who would have the expertise to see how the code would handle this type of a change, and if we can make some changes, if it happens to be what is tripping up the Ring Hub, or if we can find out what else is causing the issue?
I can make the change in my app/driver and test it, but identifying what to change is very probably above my skill level...
I'd say a better word is "reacts":
...the 2.2.3 hub just reacts to the event as received...
It's very low probability that the "new" fields are a problem. My experience is that Programmers are Lazy. And being one, I know there's a large level of accuracy to that. The only way new fields would be a factor is if the programmer counted fields. And that's just too much 'work' for this. An Event is a Map and each field is directly accessible by name. There's no reason to look at the 'third field' when just looking at a field names 'value' is fractionally easier. 
2 Likes
Woah, it looks like i totally missed you shared these.
Having said that, it doesn't look like you have/had tracing enabled on the 2.2.4, so we can't see if the data and parameters are the same between the two.
In particular I'm wondering if there are any formatting difference, added or missing properties, or different unexpected values coming from 2.2.4 that could help us narrow down your problem and @roblenderman's problem.
I don't have any locks directly paired to Ring Alarm (I pair them to HE), so can't really do it myself.
1 Like
Here is what I am seeing. My Lock shows very little but does update the dashboard with the current status properly. The hub logs have a bit more but not much. There is a warning about not updating. I also noticed the zid is null in the warning about setting the device info.
Lock Log:
dev:642020-11-30 11:27:40.723 pm debuglock()
I clicked the lock button in the lock device at 11:27:40
Hub Log:
dev:332020-11-30 11:28:00.879 pm warn42["message",{"msg":"DeviceInfoSet","datatype":"DeviceInfoSetType","seq":6,"dst":"91619758-c723-4812-614f-7264f36d9752","body":[{"zid":null,"command":{"v1":[{"commandType":"lock.lock","data":{}}]}}],"sessionId":745790378,"status":-66}]
dev:332020-11-30 11:28:00.878 pm warnI think a DeviceInfoSet failed?
I also have this from the hub log when I tried to control it from HE.
dev:332020-11-30 11:27:40.738 pm tracerequest: ["message",{"body":[{"zid":null,"command":{"v1":[{"commandType":"lock.lock","data":{}}]}}],"datatype":"DeviceInfoSetType","dst":null,"msg":"DeviceInfoSet","seq":6}]
dev:332020-11-30 11:27:40.735 pm traceparams: [type:lock.lock, zid:null, dst:null, data:user_driver_ring_hubitat_codahq_Ring_Virtual_Lock_413$_lock_closure2@14264a3]
dev:332020-11-30 11:27:40.733 pm debugsimpleRequest(setcommand)
dev:332020-11-30 11:25:09.643 pm warn42["message",{"msg":"DeviceInfoSet","datatype":"DeviceInfoSetType","seq":5,"dst":"91619758-c723-4812-614f-7264f36d9752","body":[{"zid":null,"command":{"v1":[{"commandType":"lock.unlock","data":{}}]}}],"sessionId":745790378,"status":-66}]
dev:332020-11-30 11:25:09.640 pm warnI think a DeviceInfoSet failed?
dev:332020-11-30 11:25:07.591 pm debugUpdating device Ring Virtual Alarm Hub
I'm really curious if the ZID and DST values should be empty (null) or not, and if what you see in "Data" is right.
@Sebastien - Any comparisons you have on your working 2.2.3?
This is what I see with a working lock request in 2.2.3.
42["message",{"body":[{"zid":"aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee","command":{"v1":[{"commandType":"lock.lock","data":{}}]}}],"datatype":"DeviceInfoSetType","dst":null,"msg":"DeviceInfoSet","seq":2}]
Differences I see with the commands @roblenderman posted are: dst is null, zid is not null, and the sessionId/status fields are omitted.
1 Like
This is what I would expect to see. A null zid seems wrong. The initial request occurs and then 20 seconds later I get the warning of failure. Both the request and fail logs show zid is null.
Request:
dev:332020-12-01 10:23:17.446 am tracerequest: ["message",{"body":[{"zid":null,"command":{"v1":[{"commandType":"lock.unlock","data":{}}]}}],"datatype":"DeviceInfoSetType","dst":null,"msg":"DeviceInfoSet","seq":3}]
dev:332020-12-01 10:23:17.434 am traceparams: [type:lock.unlock, zid:null, dst:null, data:user_driver_ring_hubitat_codahq_Ring_Virtual_Lock_413$_unlock_closure3@efaae]
Warn message 20 seconds later:
dev:332020-12-01 10:23:37.554 am warn42["message",{"msg":"DeviceInfoSet","datatype":"DeviceInfoSetType","seq":3,"dst":"91619758-c723-4812-614f-7264f36d9752","body":[{"zid":null,"command":{"v1":[{"commandType":"lock.unlock","data":{}}]}}],"sessionId":931938442,"status":-66}]
dev:332020-12-01 10:23:37.553 am warnI think a DeviceInfoSet failed?
Also all the other log traffic for Ring shows a value for zid. The lock is the ONLY one with it being null.
