Using as Cloud Connector for Rachio sprinkler systems


I’m working on the Rachio Sprinkler Binding for openHAB 3 and want to replace the concept of a reverse proxy with the openHAB Cloud connector.

  • I created a new OH system
  • connected this via
  • The binding passes the URL to the Rachio cloud service and registers a webbook
  • I need to encode the following in the URL: credentials, base URL, binding specific URI

Is that the correct URL?

using as userid registered to myopenhab and mypassword as password
Due to the fact that myopenhab requires an e-mail address there are 2 @ in the URL, which might confuse Rachio’s cloud backend. When I open this URL in a browser it comes back into the binding, so I would say in general it works. However, when I register this URL to the cloud service nothing happens.

Is there a way to use the uuid instead of e-mail in the URL? or something wrong with the syntax?

Rachio documentation says:

HTTP basic authentication is supported for webhook URLs. To enable HTTP Basic authentication, prepend username:password@ to the hostname in your webhook URL. We will send the credentials in the HTTP header. For example:

The username:password fields are Base64 encoded and provided as a header value:

Authorization: Basic ZnJlZDpmcmVk

@digitaldan Any advise?

Have you tried to URL encode the first @ or both of them? It’s not unusual to have an email address as a username. I’ve successfully use basic auth this way in Tasker before, but I don’t know if it was smart enough to do the URL encoding for me behind the scenes.

All I can offer is that it should be possible.

good idea, but it seems that doesn’t accept this format
when I use in a browser I’ll be prompted for credentials. If I use @ instead of %40 the request gets through and the binding sees the call.

The challenge there is that the browser is definitely doing all sorts of URL encoding behind the scenes. What happens with wget or curl? I don’t know if those automatically URL encode or not and if they do, I bet there is a command line option to turn that off.

What happens if you url encode both @s.

curl accepts the url encoded e-mail address, but nothing changed on the Rachio side
I need to debug the binding and check what’s in the current webhook list
I also created a post in the Rachio community

That’s what Rachio shows as an example:
so they expect/support the seperator for the hostname
I depends on their parser, it need to support url decoding or take the hostname after the last @

I’m pretty sure that adding username:password@ in the URL is a purely client based feature and that the client is responsible for then adding those to the Authorization header in the actual HTTP request. I don’t remember seeing anything in the HTTP spec about URL based authentication, and we are using a popular node module for handling basic auth, so if we could support it, i would think our library (passport js) would support it as well. From what i can tell nearly all the browsers have removed this feature as it’s a security hole for end users.

1 Like

I think we need to differ “who is the client”

  • The binding submits a webhook registration providing the URL
  • Rachio Cloud parses this strong, splits into credentials and URL
  • makes the http call and adds the credentials to the http header
  • accepts the credentials and forwards the request to the local OH instance

In this case

  • I have to encode the webhook url properly
  • Rachio needs to support url-encoded credentials or proper parsing when 2 are included
  • sees a http request with basic auth (or not)

This comes down to: What das Rachio support/expect? Maybe I get an answer from their community or support.

On the other side: Why do I login with the registered e-mail address to That already exposes some personal information. I would prefer registering with a userid and having my e-mail address only for password recovery. I don’t feel comfortable with portals using the e-mail address as userid. And finally: this would bypass my problem here :wink:

Assuming this is in fact the source of the problem which is not at all guaranteed. It’s just the first suspect.

But as you indicate, it is going to be up to Rachio to tell you how to make it work.

As for the use of email as the login, that is an incredibly common practice. And since you are communicating with via HTTPS, the only things that know the email address are the two end points as all the communication in between are encrypted. On the Rachio side, they too use email as the login username so they already know this personal information.