Ring doorbell

Tags: #<Tag:0x00007f83342727c0>

Hi…

Thanks for your help, and im hoping that you would like to continue helping me, im still having issues…

Im reciving the link but if im copy the link into my browser, nothing is happening :frowning:

I think there must be something on their end :frowning:. I just tried to step through it in Eclipse and all the API calls that previously worked are now all returning “invalid request” from the ring.com side. It will probably be a while before I can sort this out, unfortunately

Looks like the endpoints might have changed. It’s hard to write a binding that has dependencies on reverse engineered RING’s API endpoint. I’m getting a ring doorbell and I’ll start hacking on it soon.

any update here - just got one :wink:

@zolakk
fyi: I installed a doorbell 2 and the binding works like charme.

The only thing, which is missing is the battery level. Is that accessible by the API? This is an important information to monitor the battery level and inform the user to do a re-charge (e.g. sending a WhatsApp)

I saw a json propery battery_life": “93”, so the info should be available through the api.

@zolakk I forked your build and added a new channel to the doorbell (I don’t know the other Ring devices, if they are also battery driven this could be adapted)

@lindberg @tnemrap
If you want to give it a try: https://github.com/markus7017/openhab2-addons-ring/blob/master/target/org.openhab.binding.ring-2.4.0-SNAPSHOT.jar

My fork could be found here: https://github.com/markus7017/openhab2-addons-ring
A pull request has already been created

3 Likes

I’m trying your .jar Markus, but it doesn’t seem to get installed.

The only message in the log is:
2018-12-31 12:00:35.183 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing ‘openhab-binding-ring’: Error restarting bundles:
Could not resolve module: org.openhab.binding.amazonechocontrol [277]

That was caused by installing both the echocontrol binding from the addons folder and the paperui. After I fixed that there is no more mention of the ring binding. But it’s not in the bundles list in the console neither in the paperui.

you need to

  • download the jar and copy it to the addins folder
  • to avoid caching problems: stop OH, clear cache, start OH
  • wait until OH is fully initialized
  • open the OH console and run „bundle:list | grep Rung“ to check that the binding is installed and Active

Open PaperUI to create things and items

  • you need to manually add a Ring Account thing and set you credentials
  • link the event channels to items
  • after a while you should see a new door bell thing in the inbox, accept and create channel(s)

@markus7017 Thanks for the addition, I have been very busy since I last updated this thread and haven’t had the time to look at the binding more unfortunately but I did merge your pull request

Hi Markus,

Thanks for the steps, but it went wrong in using wget to get the file. I downloaded the html page :frowning:
To wget the correct file add raw=true:
https://github.com/markus7017/openhab2-addons-ring/blob/master/target/org.openhab.binding.ring-2.4.0-SNAPSHOT.jar?raw=true

But with the right file I am able to add the account and discover the doorbell thing. And they seem to be online in the PaperUI. But I’m not getting events from ringing the doorbell. And in the events.log i get this:
2019-01-01 11:46:19.242 [hingStatusInfoChangedEvent] - 'ring:account:803d3c49' changed from OFFLINE (COMMUNICATION_ERROR): Invalid response from ring.com. to OFFLINE (CONFIGURATION_PENDING): Retrieving device list 2019-01-01 11:46:19.547 [hingStatusInfoChangedEvent] - 'ring:account:803d3c49' changed from OFFLINE (CONFIGURATION_PENDING): Retrieving device list to OFFLINE (COMMUNICATION_ERROR): Invalid response from ring.com. 2019-01-01 11:46:23.855 [hingStatusInfoChangedEvent] - 'ring:account:803d3c49' changed from OFFLINE (COMMUNICATION_ERROR): Invalid response from ring.com. to ONLINE 2019-01-01 11:46:29.173 [hingStatusInfoChangedEvent] - 'ring:account:803d3c49' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Invalid response from ring.com.
Does this has to do with the api change?

you don‘t need a wget, clicking the browser link should work by itself (at least with my browsers)

I can‘t say anything about the api issues, maybe @zolakk could help.

In which country are you located? Maybe it‘s region specific, because other people reported similar issues (see above). I‘m located in Germany and works fine.

I needed to download it in a terminal, since I run OpenHAB on a Linux machine without a desktop or shares configured, so I used wget.

I’m from the Netherlands, so I guess it isn’t a region issue :wink:

That’s the same issue I was having before and deleting the account thing and re-doing it seems to have fixed the issue for me. I think it’s some weird way it’s handling the login and caching the token but I haven’t been able to trace it down unfortunately.

I have had the Ring Pro doorbell and some of the Floodlights for some time now so I was very interested to try out this binding. Thank you to the binding author and all those involved thus far. The install went very smoothly on a linux 18.04 server as outlined above. I was very excited to see openhab logging the full api urls for captured video motion events.

Two Issues I am seeing:

  1. I am seeing the Ring Doorbell Item but no separate items for the Floodlights
  • From the event logs - all motion events are logged under same item so there is no way to differentiate motion from one sensor to the next
  1. Seeing a significant delay in motion activity and log event
  • I currently use IFTTT but this new binding has been consistently slower (1-3 minutes on average)

did you tried

  • a different hardware id in the thing config
  • re-create your account?
    1. I am seeing the Ring Doorbell Item but no separate items for the Floodlights
      Are the floodlights directly controlled by the doorbell?
      Could yoi suplply a TRACE log so we csn see the api json?
  • motion events: the events are returned on the account level, maybe it makes sense to include an id prefix or report them also on the specific thing - @zolakk?
  • delay: te binding is polling every x sec for events. did you checked your thing config? Lowest setting are 5sec
    in addition I have a change ready, which decouples the event poll and tge token refresh - there is no need for a token refresh every x sec, which reduces cloud api calls, but I wouldn‘t expect that this relates to event notificatin delays.
  • iftt: maybe iftt has a higher prio on their side, but 1-3min sounds strange

The weird thing is that there are already channels defined on the account thing for event source ID and description, but I have no idea why they aren’t getting exposed outside of the binding. It would make sense to probably move those channels to the specific thing but that will take a decent amount of refactoring to do that I think though. If you want to send a pull request with the separating of the event poll and token refresh that would be good too. That was truly a very quick and dirty workaround to getting it to work long term, so thanks for that.

Edit:
Spoke too soon about those channels. It looks like it was just simply adding the following to the eventGroup channel group type in ESH-INF/thing/channels.xml and now the cooresponding device ID and description are showing in my test bed for the last event shown on the account thing

<channel typeId="doorbotId" id="doorbotId"></channel>
<channel typeId="doorbotDescription" id="doorbotDescription"></channel>

I created a pull request for the event poll/token refresh seperation. Please review and then merge both changes into your repo.

You should remove target/* from the repo (right click on the target folder->Team->Ignore). Those files will be build by running mvn install and shouldn’t be in the repo. Usually I only add the jar file to the rep (target/xxxx.jar), so people could download the compiled jar and don’t need the complete repo and deal with dev tools.

What’s the purpose of the hardware id in the thing config? Is that tied to the api key? I think it would make sense to have a default based on the MAC address as default rather than the user to configure the id. Does that make sense? Are there format requirements for the id? Otherwise I could copy a sniplet from my other binding to determine the local MAC address.

Sure, go ahead and create the pull request. I’ll merge it and post a new binary here for anyone who wants to test it. As far as the hardware ID, it looks like it’s sent as part of the authentication process to get the profile object. I agree it would be best to have it pre set either by something like MAC or some other more unique identifier, even a random number. I’m not sure if there’s a format requirement but I just tested it with my machine’s MAC with dashes instead of colons (ex. AA-BB-CC-DD-EE-FF) and it seems to be working just fine.