Link to the thread: OAuth2 using just OH Rules and myopenhab.org
Are you willing to learn? That is about all you probably need.
There doesn’t need to be any working between companies. You’ve figured out how to connect to their API. You are in the process of learning how to interact with that API. At that point you are done. They don’t have to give you permission to write a binding. As long as they offer a publicly accessible API and you aren’t abusing that API (e.g. thousands of calls a minute) you are good to go.
And you don’t need our permission to write a binding either. At a minimum, any binding submitted to the baseline needs to be reviewed for quality and certain standards, but there is nothing requiring you to submit it. You can distribute it through the IoT Marketplace or just from github or your own way for people to download the binding.
Don’t wait for anyone to give you permission for something like this. Go have fun and figure it out.
This is how many of the current bindings work, to include the Nest binding. As an individual you sign up for whatever you need to sign up for to gain access to the API for personal use and the information you need gets added to the configuration to authenticate as you. The binding is now connected to the API using your personal authentication for your personal use.
You would only need to get an agreement between companies in cases where the two company’s servers authenticate with each other. But that isn’t what we are talking about here. And it is unclear whether an open source project like OH could support something like that anyway because when you create such an agreement and connection between servers, often there is a secret shared between the two servers to authenticate. Obviously this secret cannot be made public which would be required to build it into the binding. There may be a way to have that code added to the myopenhab.org servers but to my knowledge that has only happened for IFTTT, Alexa, and Google Assistant.
Other users would need to sign up for a developer’s account and access to get the tokens necessary so their instance of the binding can connect to the API for their personal use. Basically they would sign up just the way you did to get their initial AuthToken.
A modest poll would probably be how to address this in the mean time. Don’t poll too often. You don’t want to abuse your privileges.
Authcode is a token you receive is a limited time code (minutes) that OH needs to send back to skydrop to prove that the user authorized the connectivity between the two services.
AccessToken is a limited time code (lasts a day to weeks) that is kind of like a password that you pass back to skydrop in every API request. It shows that you have successfully authenticated for this user.
RefreshToken is a limited time one time use code that usually lasts longer than the AccessToken and AuthCode that you use to get a new AccessToken when your AccessToken expires.
The typical way it works is you need to pay attention to the return code you receive for every API call. When your AccessToken expires, in Dexcom’s case, it returns a 401 when the token expires. When that happens, I kick off the refresh and use the RefreshToken to get a new AuthToken and then you need to try the call again.
Handling the expiration case is something you need to do anyway so I wouldn’t bother with refreshing the token every 23 hours. Just wait for the AccessToken to expire and refresh then. Unless, for some inexplicable reason they have the AccessToken and RefreshToken expire at the same time which would make no sense because the whole purpose of the RefreshToken is to get a new AccessToken once it expires.
I’m usually a little bit against this sort of approach as it violates my fail usable requirements. I like to use Mitch Hedberg’s joke “You will never see an out of order sign on an escalator. Escalator temporarily stairs. Sorry for the convenience.” (I don’t know if I have the exact wording but the sentiment is there). When any part of my home automation fails, it should still be usable. So that means keeping some “smarts” at the device and retaining the device’s manual interfaces.
So in a case like this, I’d much rather get events from the sprinkler system when watering starts/stops, be able to turn zones on or off, or change the schedule through OH, but for day to day turning on and off at the right time I’d prefer to keep that at the device. So if OH fails for some reason the grass still gets watered.
Also, I suspect that skydrop has invested far more man hours into the software that drives your irrigation than you will be able to do. I’d rather spend my time on problems in my home automation that someone hasn’t already solved.
But I spend all day dealing with failure cases and risk mitigation so maybe I’m more sensitive to this sort of thing. It’s just my humble opinion.