[WITHDRAWN] Unofficial Ring Integration

I'm seeing something similar.

I can setMode(Home) and it works fine, I can setMode(Away) and it works fine, but setMode(Disarmed) does not work. I can run it manually through the device but not through any external rule engines.

Edit:
I modified the code to show the current value of the mode before it runs setMode() and it shows "off" when triggering setMode(Disarmed) externally (through Rule Machine or through WebCORE)

logDebug "Current Mode: ${device.currentValue("mode")}"

When triggering setMode(Disarmed) from the device itself, it shows "Current Mode: home". Any idea why the mode is not updating for external apps?

I have no idea what Device Watchdog is. Is this a Hubitat OOB app?

@codahq I think they are referring to this:

1 Like

Any idea what getLastActivity looks at? If it's looking at some internal Z-Wave or Zigbee timestamp my integration will never support Device Watchdog unless I can set that timestamp manually.

No idea... never used it ..

1 Like

According to this thread getLastActivity()? Mike says that it is based on events. If no events happen it goes inactive after 24 hours. Are you guys seeing those devices inactive always or do they show up once a device has an event? If they aren't showing up check your "Ring API Virtual Device" to see if it is connected or not. If it's not manually connect it by hitting initialize.

I have noticed that Ring is disconnecting the websocket now instead of leaving it connected indefinitely. This is probably another security precaution they have implemented. There is supposed to be a scheduled call to check every 60 minutes if the websocket is connected and reconnect it if it isn't. I have noticed this has failed a few times. I will try to make it more robust.

Can you paste the RM rule? I'm not seeing this issue. It seems to be functioning as intended. Be sure that you aren't actually see it twice in the log. Maybe you are seeing it once getting set to the correct value but then you have some other rule running and setting it again back to an incorrect value.

Along these lines, I did find a bug in the Ring Alarm Hub driver and I have pushed a fix. The only file that is changed is the alarm hub driver.

2 Likes

Just wanted to chime in and say: Thank you so much again for this integration.
For my automations, and setup when I'm on vacation, this literately is the most important custom app I have installed in my Hubitat. Thank you for the time you have spent on making this great.

3 Likes

I'm currently using WebCORE to do this as I was able to make it work modifying the driver and removing the specific check for the current ring alarm mode.

Essentially the rule just says if mode is changed to Home, Ring Alarm -> setMode(Disarmed) . I have a similar rule that says if mode is changed to Away, Ring Alarm -> setMode(Away). This works because it still thinks the alarm mode is off. I think that when WebCORE uses setMode() it does not actually modify the device.currentValue("mode")

dev:392020-01-09 03:31:00.261 pm info Ring Alarm Hub already set to Disarmed.  No change necessary
dev:392020-01-09 03:31:00.260 pm debug setMode(Disarmed)

Any thoughts how I can write a rule that when Location Mode is changed to run setMode() and also update the device's current mode status? Maybe running a refresh ? The idea is to keep everything in sync so if you modify the status through Ring, it will update the location mode & HSM status and also if you modify the Location Mode it will update HSM as well as Ring.

@codahq I appreciate these apps and device handlers so much. A lot of thought was put into writing these and I truly appreciate all of the work you've done to make Ring devices functional for the Hubitat community!

To change Ring's mode match HSM's mode you can use a trigger or rule like this:

image

Or whatever mapping you want.

To change HSM's mode to match Ring's all you have to do is toggle the checkbox on the alarm hub for that option.

1 Like

I just realized that my smoke / CO2 alarm was not detected - I get an error in the logs about that. Is there a way I can add it manually?

(From Ring API Virtual Device)
[dev:185]2020-01-09 20:24:09.471 [warn]Couldn't find device null of type alarm.smoke with zid eefa...

Also, do I need to be concerned about this?

(From Unofficial Ring Connect)
[app:113]2020-01-09 21:59:33.851 [warn]Probs need to enable OATH in the app's code, dood/ette. This is required if IFTTT will be used to receive motion and ring events.

(I’ve been having some hub slow down issues, so keeping a close eye on my logs lately...)

This is already mentioned in the thread somewhere. When you created devices did you have the smoke alarm driver and co alarm driver installed (not the listener driver. There is a difference.)? If you didn't you can install the correct drivers and click create devices again. Any devices you deleted because you didn't want will be created as well. You can delete devices you don't want in HE but then you have to live with the warnings.

For your other question the answer is right in the log and it's been mentioned here in the thread as well. You need it enabled if you want to use IFTTT for notifications for non-websocket devices.

@codahq

separate issue to my last - is the keypad supposed to come up as a device? I installed the driver code for it but it never comes up in a scan. It always mentions its missing in the logs.

When you say "scan" do you mean "Discover Devices" from the app? You don't discover devices for websocket devices. You just click the create device button under the respective hub.

You the man. :grinning:

I'm slow today.

Thanks @codahq! I thought I had all the drivers install, but I must be missing something. I'll dig into it some more to see what I'm missing.

I have to say, I really adore this integration that you have put in place! I use it all the time! Thank you so much!!!

I hooked up the web socket to an alert as from the logs I wasn’t sure if it was down for a period of time or not. I’m noticing like clock work the websocket fails after 4 hours but instantly reconnects.

Just wanted to make sure you are aware, I assume that’s a ring or websocket thing you are aware ofF but just in case posting it here. Doesn’t seem to be affecting me at all.

Edit: looks like my last one was 3 hours.

Thanks for bringing it up. I'm aware. I mentioned this about 2 days ago in a post in this thread but I'm not sure a lot of people saw it because it was inside of a post with troubleshooting for another user.

The websocket used to stay connected indefinitely but now it is disconnected on the server side periodically. I've noticed it on Ring's web app as well. It used to never disconnect.

It means that every 3 to 4 hours we have to reconnect and a few messages may be delayed for up to 30 seconds while reconnecting happens. In rare cases we will miss important messages that don't come in the refresh. Not ideal but we can't do anything to avoid it. I'm just glad that they allow us to immediately reconnect or that there is a websocket at all. Otherwise, none of this would be possible without polling for the information or Ring implementing all of this functionality into IFTTT or another service which they aren't going to do. I hate Amazon.

I initially implemented motion sensor on the alarm keypads and then halfway backed it out before I released the integration. At the time the wake-up event and the motion event were identical so there was no way to tell if the keypad was waking up or detecting motion.

I actually complained about this in github in somebody else's Ring library and either Ring saw it or fixed the issue on their own. I noticed a new impulse type coming over the websocket to differentiate a keypad wake-up event from a motion sensing event so I finished motion sensing on the keypad driver.

Unfortunately, unlike the other events and devices the websocket does not periodically send this state and does not send it on connect. Because of this I can reliably detect motion but we don't know reliably when it stops. This was good enough for me so I just scheduled it off after the timeout (which preference already existed because I saw this same behavior when I coded it initially).

At any rate, there is a change to the keypad driver that will make it fairly reliably act as a motion sensor. Just one file changed:

ring-virtual-keypad.groovy

4 Likes

Got it. Cool, And thank you for the details.