Nobody told that I do not have log files. I have told, that no error visible in the log file. What is strange that I have clicked on another market binding: Resol (2 lines below Rachio in binding list). It has installed fine, but no corresponding line in openhab.log about successful installation.
I had hardware issues on my original openhab2 install and finally got around to moving to a new box. I went with the 2.5.0.M3 version on the new box.
Installing via the Addon Directory shows nothing in the logs even on a restart on any of the log files except buried in there I see this one line. The interesting thing is that the binding doesnāt show up as installed in PaperUI and all the items are uninitialized so I am not even sure how this one entry showed up. I tried removing and adding the org.openhab.binding.rachio-2.3.0-SNAPSHOT.jar back but it made no difference.
==> /var/log/openhab2/openhab.log <==
2019-09-16 22:05:15.746 [ERROR] [pse.smarthome.core.items.GenericItem] - Tried to set invalid state 63.0 (DecimalType) on item IRO2Yard_ZoneRuntime of type StringItem, ignoring it
Trying to install the Market Binding version gets you only this in the event logs but nothing in the openhab.log
==> /var/log/openhab2/events.log <==
2019-09-16 21:52:17.729 [thome.event.ExtensionEvent] - market:binding-4085090: Bundle cannot be installed: Error occurred installing a bundle.
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?