Please make sure that you downloaded the jar, not just the html file. Click on the link, which opens up the GitHub folder then click the Download button. You you do a right click+Save here it just downloads the GitHub html file.
Hey Markus thanks for the tip. Looks like I did have something wrong with the jar file. I got it from a backup I had done prior to my original OH system going down and something must have gotten corrupt. I redownloaded and noticed the file sizes were off. Not sure what happened but sure glad it’s back online thanks to your tip!
fyi: I’m working on a PR to bring the binding onto 2.5 and get it into the official distro. Not sure if this works out given the timeline, but at least I’ll submit the PR for review very soon.
Could anyone support with testing? Is someone already use the binding on OH 2.5M3 or M4?
PR could be found here:
I use your binding: org.openhab.binding.rachio-2.3.0-SNAPSHOT on M4. It works although it starts with some error messages. I have Rachio3.
Hi All, I need your help to finalize the 2.5 release.
The latest build is available on the central build system:
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.rachio/2.5.0-SNAPSHOT/
README: https://github.com/markus7017/openhab2-addons/blob/rachio_snapshot/bundles/org.openhab.binding.rachio/README.md
I’m very interested in a cross test against different setups (devices, OS, features) as well as general comments like “Is the README clear enough”?
I’m also interested in 2.4 compatibility. No worries: the final release will support 2.4 and 2.5, but I switched to 2.5 for development.
If you encounter issues: Please include
- OS type, OH version
- a TRACE log
- Shelly device type
- a short description
Please note: This is a BETA! Make a copy of the existing installation, there is NO guarantee that everything works like before, but I’ll fix issues asap.
Thx and have a great weekend with testing the binding 
I had a look at the readme and I have grave concerns about the callback url. If it can’t work using https and it can’t work without authentication than it can’t work. Period.
The ability to get sprinkler events in your openHAB cannot justify the insane risk of exposing your openHAB directly to the internet without any protection at all. Any random person can see everything about your home automation, install stuffy in your machine, and from there completely own your entire home between without even needing to work at it. They don’t have to crack anything. They just can use the stuff built into openHAB that you do kindly exposed to everyone in the world.
See My personal openHAB server infrastructure hacked for one example.
If Rachio won’t support doing this securely using HTTPS and OAuth2, Rachio doesn’t really support callbacks and we should not encourage it’s use. At a minimum you need to add a paragraph telling users they should not use this under any circumstances but if they insist provide an understanding of the risks they are taking. And this paragraph needs to make it clear, don’t do this, ever.
Consequently, in my educated opinion (CISSP, do security engineering for a living) this callback feature should not be supported by the binding in the first place.
If Rachio can support https and at heart basic auth, than provide instructions for configuring the callback to work through myopenhab.org.
Edit: it might not be clear based on your write-up, but by configuring NAT, you’ve exposed your entire oh to the internet. The reverse proxy configurations are slightly better but I’m my opinion, insufficient protection. I expected more of Rachio.
If this feature is to be retained, only provide the instructions for the reverse proxy and eliminate all the other really unsafe alternatives.
The binding DOES support https callbacks (see older postings) , but yes, the README is out-dated at that point. I Already start working on that.
In general the following security pattern applies to improve security
-
The user has to register an application with Rachio Cloud and gets an api key. The binding needs to present this to the API, otherwise it can’t access the api / account.
-
Outbound communication is https-based (https://api.rach.io/1/public/, no certificates), so no unsecured communication in general.
-
The binding generates a private id, which is send with the api initialization (each time a different one), mirrored in the callback and validated by the binding.
-
The binding loads the AWS IP range list on startup and restricts incoming calls to those address ranges, because Rachio cloud is hosted on AWS in the US (e.g. also no EMEA AWS addresses are accepted).
-
The URI is validated, calls other than /rachio/webhook are ignored
-
The device and all zones have unique uuids, which are also validated
On top the README describes the setup of a reverse proxy, which accepts the inbound callbacks and redirects them to OH - separating the OH from direct Internet access + you could implement more security features on the network level.
AFAIK Rachio Cloud does not support OAuth, you need to provide a key from the registration to the App (in this case the OH binding). However, I think the security level provided by the binding is way better than other Cloud-based implementations. An OAuth registration to the API would make no difference to the security of the callbacks. I would prefer to have a Rachio X.509 cert as part of those requests, but they don’t send one and I can’t enforce them to do.
Maybe that addresses your harsh critics! Yes, the user needs to be educated and guided to a secure setup, but at the end don’t overrule the user. Any suggestions for improvement are very welcome.
-
This protects Rachio’s servers but doesn’t do anything for each user’s openHAB.
-
This provides confidentiality but confidentiality isn’t all that helpful here. Anyone can contact a server through https.
-
This does start to provide some protection for the Rachio add-on. But my over all concern is that the add-on could be as secure as Fort Knocks, but the readme as written leaves people exposing their entire openHAB to the internet and OH is really not safe to expose to the internet.
-
Again, this protects the add-on but does not protect the rest of OH that your instructions have being exposed to the internet.
-
But calls to /rest/addons are not ignored and you’ve exposed that end point too. Literally anything one can do through any of the UIs including creating rules is possible through that.
The big concern is the callback. Even exposing OH to the internet through a reverse proxy is a very risky thing to do and not something that any user should take on lightly. It comes with a responsibility to constantly monitor the system for signs of attack and compromise, monitor the cves for known vulnerabilities and sometimes needing to apply novel mitigations that most end users would not know how to do.
I’ve no doubt that your add-on is as secure as you can make it. But your add-on doesn’t exist in isolation and your instructions at first recommend completely exposing OH to the internet followed by a “copy and paste” config for a reverse proxy set up with no mention of the risks and responsibilities of doing so.
This sorry if thing is why Alexa and Google Assistant integration is implemented in the Cloud Server and not in bindings. This the user’s OH remission safely behind their firewall.
Except that you can make it work through the cloud server instead of requiring users expose their lan to the internet.
Don’t mislead the user either.
This could become a never ending discussion…
Focusing on improvements:
I checked again the API doc and in between Rachio support basic auth for the callback. You could just add user:password to the callback url and they pass this back as header fields on the call. This allows the reverse proxy to check a user id + password before routing the request to OH.
That means
- you need the token to access the API
- communication with the Rachio Cloud is encrypted (https)
- callback is encrypted
- reverse proxy validates user id+password
- binding could check the inbound url again to ensure valid credentials
What do you think?
Then it should work through myopenhab.org, correct, since myopenhab.org supports basic auth? Then that should be your primary documented approach to follow for the callback, not telling “I just started using Linux yesterday” users to set up a reverse proxy, or worse (and the main reason why I posted in the first place) just exposing all of your openHAB to the internet completely unprotected.
Definitely keep the reverse proxy stuff and mark it for more advanced users who know and understand the risks and responsibilities they are undertaking. And modify the reverse proxy configuration to accept the basic auth as well. That’s a good addition I think.
Then my only problem would be the fact that you have to store your username and password on the Rachio website, probably in plain text. But I’d rather have that than having average joe users setting up and then ignoring their own reverse proxy. The risk, though considerable, is less than the risk of exposing a port to the internet for users who don’t know what to do to protect themselves. I don’t like it but I don’t like it less than than the alternatives.
1 Like
How could I setup myopenhab.org to funnel the callbacks to my OH instance?
Nope, user and password will be passed in the callback url through the https connection, the url will be send by the binding. Yes, in fact technically it’s expose to Rachio themself, but…
myopenhab.org is basically a reverse proxy for your openHAB instance. Any URL that starts with myopenhab.org will get forwarded to your openHAB machine through the Cloud Connector add-on. So if you use: https://username:password@myopenhab.org/rachio/webhook as your callback, Rachio will authenticate with myopenhab.org using basic auth and the call will get forwarded from myopenhab.org to the Cloud Connector add-on to your actual openHAB instance and the results returned along the same path.
It works without needing to open a port because the Cloud Connector add-on initiates the connection to myopenhab.org instead of the other way around. But in all other respects, it works like an nginx reverse proxy you might configure yourself. Though it is of course limited to only proxying stuff that you access through the OH built in Jetty server so you can’t use it to, for example, get at your Grafana server.
You can create more than one user on myopenhab.org for a given account so I would recommend creating a special account for Rachio and be sure to change that password periodically to avoid needing to share your personal account and password stuff with Rachio. That helps mitigate the risk from that a bit. You can also define this user as just a user and not an admin so they can’t change any of the settings on myopenhab.org. Unfortunately, they will be able to do just about anything else on your openHAB through that account though. 
but we therefore need to trust Rachio to do the right thing and not save it out to logs that are exposed to the internet or something stupid like that. You might say “who would be so stupid to do that?” Sadly, it happens all the time.
@markus7017 any progress on using the OH cloud to proxy the requests? I am a new rachio owner and would like to use your binding. I made a binding for Somfy blinds and would be happy to try and help you if you need more help with this one.
Hi Rob, do you have any pointers to existing bindings that use this proxy technique already? I am interesting in seeing how a binding could hook into the built in Jetty server to get requests for particular Uris.
Hi, I‘m just overloaded. I also did the Shelly, re-factored the Gree binding, currently working in the Carnet one and MagentaTV requires authentication changes. So dar I didn‘t found the time to look into that. Feel free to implement this and create a PR to my repo. I could manage the review process.
1 Like
Maybe the GPS Tracker binding would be an example.
@rlkoshak im having issues with myopenhab usernames being email addresses ("@") and rachio’s handling of those being url encoded. I they put the details in the authorization header, base64 encoded “user:pass”. But i suspect they are not url decoding the %40 into ‘@’ first and so auth is failing. Im asking them about this potential bug.
Is there a way to create a myopenahb username without an email address to test this do you know?
I doubt it. Maybe if you host your own openHAB Cloud instance and change the code to allow it. Since it has to send an email to activate the account I doubt you can use anything but a valid email address to get an account set up.
@markus7017 and @rlkoshak I have successfully used the binding with MyOpenHAB.org and am able to see events coming in from Rachio via the MyOpenHAB.org proxy.
It took a bug fix on the Rachio end to handle “@” in the usernames in webhook Uri’s and they fixed that already.
@markus7017 if you dont mind i would like to tidy up the binding and remove a bunch of the code to do with IP range checking etc… I think it would be far simpler to adjust the setup docs etc… to show people how to use MyOpenHAB.org for this. It is very simple to setup. I would also like to PR some more suggestions to bring the binding up to spec on the new conventions and discovery service system. I’ll submit a PR in the next day or two when complete.
This is really exciting! no more proxy or port forwarding or NGINX needed 