Thanks, I had tried that already but there is no change to that list of devices for me as the only thing I have at that level is a Doorbell and Alarm Base. What I have added is an additional smoke detector to my Base -- the sensors connected to the Alarm Base are generated in Devices as a sublevel under the Base. I haven't tried the "Reset list of discovered devices" for Ring, because I'm afraid it would reset whatever settings I've already made to the other existing devices. I'm hoping there's a way to add only the new device to HE without taking a step backwards with the other sensors already in the system.
If the device are connected to the Ring Alarm Hub. You would need to click the Create Devices buttons within that device. The smoke detector should be here.
If they are Smart Lighting, click create Devices under Ring Beams Bridge.
2 Likes
Found it. I was looking for it under the Parent device (API), not the virtual Hub underneath. Thanks all for your help.
1 Like
I am a little bit lost. I have a ring alarm and I can not figure out how to have rules tell the alarm what to do. I have tried looking through all of this and I still can't figure it out. If I pull up the device and tell it to switch modes it will. I just can't see how to write a rule that says to change the mode on the ring as you have it.
Welcome to the Hubitat community rfce19!
Setting up rules to arm or disarm can be a bit daunting the first time. It will become easier as you get use to the tools.
I will start at the very beginning, so you may skip the first couple of steps which you have most likely already done.
- I assume that you have Rule Machine installed. If not, install it from the "Apps" tab under "Add built-In App" button which is on the top right of that screen.
- Click on the "Rule Machine" link, then on the "Create New Rule" button, then give your new rule a meaningful name.
- Select what you want to trigger your rule. Ex.: Turning on a switch by clicking on "Select Trigger Events" and selecting all the devices and events you want to trigger it.
- Set the actions to run by clicking on "Select Actions to Run", then in this case, choose "Set Mode, Variables or File, Run Custom Action"
- From the actions available, select "Run Custom Action"
- From the "Select capability of action device" drop down, select "Actuator"
- From the list of devices available, select "Ring Alarm Hub"
- From the "Select custom command" drop-down, select "setMode"
- From the "parameter type" drop down, select "string" and enter the command available from your "Ring Alarm Device" (Ex.: "Disarmed", "Home" and "Away") - be mindful of the capitalization as it may not work if you write "disarmed" instead of "Disarmed".
- Click on "Done with this action", "Done with Actions", and then "Done".
- Enjoy your rule, and modify it to make it work better if you need to!
Does that answer your question?
4 Likes
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
