SkyDrop integration - potential future binding

Add-ons Bindings
,
1

I’ve spent most of my morning linking myopenhab.org to the skydrop sprinkler API using OAUTH2. Many thanks to @rlkoshak for the OAUTH2 thread.

I believe someone “more important” than me would have to put together a binding - I don’t have any binding programming experience and I’m not anyone of authority to make things like that work between companies, the API access I have is conditional on my own personal use. Additionally the skydrop API doesn’t have any push updates that can come back to OpenHAB (that I know of). That being said, the people at SkyDrop may be open to getting things linked up.

All of the OAUTH2 setup went without issue so it seems to be standard OAUTH2 without any oddities.

Rich, about your Dexcom script- do I need to persist the RefreshToken in order to authorize - or does authorization happen only with the client id and client secret? I didn’t have to really read through and get comfortable with your code there because everything worked right the first try! It was nearly as simple as just changing “dexcom” to “skydrop” everywhere…

So far I can do the following:
-Authenticate oauth2
-Update my AccessToken and RefreshToken (they’re good for 24 hours so I’ll probably run this update at startup and every 23 hours after that)
-Start watering a specific zone
-Stop all watering
-Get “next watering” schedule and durations

Things look pretty good. The downfall I see at this point is there’s no way to get to-the-minute “next watering” schedule - the API just returns the next day watering will happen. I’m a the point where I can likely make an openhab-based watering system but it wouldn’t coordinate with the skydrop automated watering. Unless I poll the API constantly I wouldn’t know if watering had started. I need to look into this.

My use-case in the near future will be to add my 4 zones to HomeKit (through Node-Red) so I can control sprinklers through that.

More distant future use-case will likely include dropping the skydrop automation system for a full blown “openhab is in charge of my sprinklers” - this means I’ll disable all of the skydrop schedules and run everything from openhab.

2

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. :smiley:

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.

3

This is the problem, it’s not public - I had to send an email to request access. I will continue to work through my setup and see where it takes me. Once I get things set up and functioning I’ll get into the “next steps” (make a binding).

This makes sense. Yes - if/when I get things more figured out then others could do the same.

I need to explore the API more - presumably I can poll the system to see when watering SHOULD start - at that point I can up the status polling to a higher resolution until watering has stopped for the day. This would solve a few problems in my brain - most importantly it could let me keep the SkyDrop automation intact while also having openhab control over the sprinklers. I would prefer to keep the SkyDrop system as it’s generally quite good. But as everything else in the world - if it has an internet connection it needs to connect with OpenHAB!

This is very helpful! And probably something I would have / should have learned from reading more documentation. I’ll keep the RefreshToken in persist so that it’s available when the 401 code comes through. Additionally the AuthToken needs to be persistent so that new requests work after restarts.

I’m beginning to understand the API interactions better. Thanks for your input. I need to go run all of the commands into the API to see what comes out. I’m sure there is enough to make the system work.

Last question: what’s the best way to send GET and POST requests from OpenHAB? I’m handling it through Node-Red (it’s VERY easy there) but may need to do some through OpenHAB later. Some documentation on that would be great. Obviously if I build it out into a binding I’ll need more information on that.

4

As is the case with all of the interfaces like this. By request access do you mean you had to send an email to someone and they emailed an AuthToken or do you mean you created an account and filed out a bunch of information? If the latter, that is pretty standard. I did the same thing for Nest and Dexcom. And anyone else can and will need to do the same.

If it is the former then writing a binding may not be worth the effort, unless you really want it for yourself. The fact that they have an API at all though implied that either they expect users like us to use it, or they are planning on releasing an API to do this in the near future.

Verify that the skydrop API uses the same return code. They might use some other 400 HTTP return code. I don’t think 401 is required by OAUTH2.

It depends. If it is a simple GET/POST then using the sendHttpGetRequest or sendHttpPostRequest Actions. However, in all likelihood you will need to create custom headers to pass the AuthToken and clientID and such with the request. In that case, you can use the executeCommandLine Action to call curl or construct the request natively using the Java libraries.

To see how to do it natively, see the Step 2 in the OAuth2 post linked above.

5

I had to email requesting access. I got an email back from Dan (software engineering director according to his email signature) asking for why I want access. After I responded and explained myself a bit more - he gave my skydrop account developer access.

It was not quick or easy.

As for the 401 error, I’ll have to wait 24 hours for my AuthToken to expire to see what comes back!

The GET/POST commands are simple, I don’t have to do send headers. Actually they’re so simple I can just copy the URL into safari and they work there. Based on your comments (and my comfort level between OpenHAB vs Node-Red) I’ll likely continue in Node-Red going back to OpenHAB to update the credentials when necessary. Reasoning for this is Node-Red has a “sprinkler” item for HomeKit while OpenHAB does not.