Indigo Domotics

Last activity of the developer at this Ring forum was ~ July 2018.
A lot of questions from users after that date, but unfortunately no answers...

I will add my voice to this issue. My integration of 3 ring devices was working, and suddenly stopped today, with the same error everyone else here is posting. I suspect it has to do with Ring increasing security due to the recent hacking story on 12/12.

Lets hope it gets fixed soon as I find it valuable. . .

#Ring DoorBell Error
#Failed to get devices from Ring.com

Same here. The Ring plugin was working just fine until a few days ago. Then the errors appeared.

I deleted any references to the Ring plugin in the "/Library/Application Support/Perceptive Automation/Indigo 7(.x)/Plugins/" folders, and restarted the computer. I then reinstalled the Ring plugin, and entered the necessary account parameters. No luck. Got the errors immediately: (see attachment).

I do NOT have the Ring 2-factor authentication enabled, by the way. I did turn it on temporarily but turned it back off when I discovered the Ring plugin would not work. It then functioned for a short time, but as many have noted, it no longer does.

Hi guys,

I don‘t have a ring and probably will never have. What strikes me in this discussion, is that everyone uses a closed plugin where the author chose to hide the inner workings of his code. Isn‘t that a huge security risk for you?
Maybe there should be a change of policy that would exclude closed code?
Just my 2 ct, happy Holidays

Wilhelm

Umtauscher wrote:

Hi guys,

I don‘t have a ring and probably will never have. What strikes me in this discussion, is that everyone uses a closed plugin where the author chose to hide the inner workings of his code. Isn‘t that a huge security risk for you?
Maybe there should be a change of policy that would exclude closed code?
Just my 2 ct, happy Holidays

Wilhelm

Having communicated with the developer of the existing Ring plugin in the past (and having contributed code to it ), I can say that he had a clear reason for doing it that way. There's nothing nefarious hidden there, based on my viewing of the code - the plugin does have optional telemetry collection, but it is disabled by default (and configurable in the settings).

ZachBenz wrote:

There's nothing nefarious hidden there, based on my viewing of the code -

i see... so you guys are in on it together.

dduff617 wrote:

ZachBenz wrote:

There's nothing nefarious hidden there, based on my viewing of the code -

i see... so you guys are in on it together.

Muhahaha Muhahahaha MUHAHAHAHAHA

Oh, wait, what?

Umtauscher wrote:

Maybe there should be a change of policy that would exclude closed code?

We don't think that's really fair to developers. The vast majority publish their code, and we certainly think that's great. However, there are many valid reasons why a developer might not want the plugin code to be open source (like many of our built-in plugins), none of which are nefarious in nature. We don't want to throw up artificial barriers for potential developers to contribute to the ecosystem. We think users can choose to use (or not to use) a plugin based on whatever their comfort level is with a given plugin, be it open source or not. And who knows - some day a developer may want to sell a plugin. We can envision a scenario where a developer might want to charge for a plugin and we wouldn't want to impede that in any way.