How to make HTTP GET work?

I've got a RM action which gets the following URL:

http://pi4.home:5005/Kitchen/favorite/91.5%20HD2%20|%20opbmusic%20-%20KOPB-HD2%20(Eclectic%20Music)

This URL doesn't work (nothing happens) with Hubitat Elevation® Platform Version 2.1.8.115, but it works fine with curl, Safari, Chrome, etc... so a couple of questions:

  1. How do I troubleshoot / debug the action to see what happened?
  2. Do you have suggestions for how to trigger the desired behavior, which is to play this station on the sonos when I double tap a paddle switch.

This URL works fine in Chrome and Safari and music starts playing in the Kitchen. This is using node-sonos-http-api which has some really nice features, including the ability to search. (Note, I tried the Hubitat native Sonos app, but my hub UI and automations slowed down terribly.)

Tagging @bravenel as suggested by @aaiyar to request a bug fix for URL handling.

Expected behavior: RM handles the following URL's which are properly URL encoded:

  • http://pi4.home:5005/Kitchen/favorite/91.5%20%7C%20OPB%20(National%20News)
  • http://pi4.home:5005/Master%20Bedroom/say/Food%20is%20ready.%20Come%20down%20now.

Actual behavior: URL is not handled correctly, server never receives the request.

Thanks

I don't know the answer. But heres' a solution - just edit the name of the favorite in the mobile or desktop Sonos app to have a simpler name without special characters. I did that for a bunch of my stations.

1 Like

Excellent, thank you @aaiyar. Took me awhile to figure out how to rename the station, but once I did, the following works great:

http://pi4.home:5005/Kitchen/favorite/opbmusic

Is there an issue tracker where I could file a bug? It seems like a bug that the URL isn't handled correctly. The same favorite doesn't work for my other speakers: http://pi4.home:5005/Master%20Bedroom/favorite/opbmusic

Maybe edit your original post to tag @bravenel?

See @Ryan780's explanation below.

Your url is not formatted as a url. There are no parnes in URL. Try this url:

http://pi4.home:5005/Kitchen/favorite/91%2E5%20HD2%20%7C%20opbmusic%20%2D%20KOPB%2DHD2%20%28Eclectic%20Music%29

I missed the period you had also. None of those are legal characters in a URL.

1 Like

Your url is not formatted as a url. There are no parnes in URL.

Nope, it's a valid URL. Check out the "reserved sub-delims" section of RFC 3986. Like I said, it works fine in curl, Safari, Chrome, etc...

curl 'http://pi4.home:5005/Kitchen/favorite/91.5%20%7C%20OPB%20(National%20News)'
{"status":"success"}

Did you try the one I gave you?

Thanks, but no need. Periods are definitely valid URL characters, I'm sure you've downloaded files like README.txt before, etc... so are parens in the path segment. Check out the RFC I linked for all of the details.

So, you won't even try it? Fine, best of luck to you. MUTE.

If I was troubleshooting, I'd use Wireshark to see what goes out on the wire and compare the data payloads between curl and HE requests and note any differences. Then go from there.

My guess is still some string parsing weirdness with the URI and the libraries under the hood. It has been more finicky than I expected, and I wish there was a library or function to handle any special encoding that HE may require.

If you don't see anything in the HE case (instead of something that is just not 'right'), the next steps to troubleshoot would be different.

Another wild guess- any chance the hostname isn't being resolved correctly by the hub? Maybe try the IP address?

We can eliminate that possibility ....

Works.

1 Like

Vertical bar isn't a valid sub-delim - unless that was a typo in your original message?

I'll edit the original URL, it changed when I renamed the favorite. If we're going to keep this thread as a the place to talk about the HTTP URL bug then let's focus on this URL which is valid, is an use case I have to have a "call to dinner" button in the kitchen, but doesn't work in Hubitat:

  • http://pi4.home:5005/Master%20Bedroom/say/Food%20is%20ready.%20Come%20down%20now.

Here's the rule that doesn't work:

As for the bug, I'd expect a URL that curl accepts without an curl: (3) Illegal characters found in URL error to work in Hubitat.

Finally, I know how problematic URL handling can be. I've worked on HTTP clients in distributed systems and I found it almost impossible to get it right by "rolling my own" url library. With that said, the above URL is properly URL encoded, so I expect it to work:

echo -n 'http://pi4.home:5005/Master Bedroom/say/Food is ready. Come down now.' \
  | ruby -r net/http -e 'puts URI.encode(STDIN.read)'
http://pi4.home:5005/Master%20Bedroom/say/Food%20is%20ready.%20Come%20down%20now.

FWIW the bug seems to be handling null characters:

From the hubitat logs:

Action: Send GET to: http://pi4.home:5005/Master%20Bedroom/say/Food%20is%20ready.%20Come%20down%20now.

From the sonos API logs, it gets a mangled request:

2020-01-13T23:35:23.633Z ERROR
  { error: 'action \'masternull20isnull20comenull20now.\' not found' }

Great suggestion, thanks @tomwalling Here's the result:

URL in Rules Machine: http://pi4.home:5005/Master%20Bedroom/say/Food%20is%20ready.%20Come%20down%20now.

HTTP Request URI: /Masternull20isnull20Comenull20now.

It looks like Rules machine is mangling the % character, maybe because it's trying to do variable substitution? @bravenel what do you think?

EDIT: I can't post due to the first day limit, but here's the platform version @tomwalling

Hubitat Elevation® Platform Version

2.1.8.115

Good catch.

What hub firmware version are you running? I am on 2.1.8.115, and URLs with null characters (obviously encoded as "%20") still work in my custom drivers. So, I agree that this seems like a Rule Machine bug of some sort.

2.1.8.115