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:
How do I troubleshoot / debug the action to see what happened?
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:
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.
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
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.
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?
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:
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.
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.
Yup. Might also want to report this a possible bug in the parent RM 4.0 thread. I know @bravenel watches that thread - because he found a solution when I found something inconsistent a few months ago.
There is a problem with URL encoding for URLs in RM. Unfortunately, the % character is overloaded in this context, and that is causing the problem. I will take a look at it.
Never put a URL encoded string directly into a URL field in Rule Machine. This is due to the use of % as a delimiter in RM for various things, including variable references.
If you want to put a URL encoded string into a URL in Rule Machine, put it in a String Variable at the time you create the variable, then use that variable in the URL field with %variable-name%.
Going forward, there are two ways we could possibly address this:
a. We add a URL Encode means of setting a String Variable. You would put the non-URL encoded string into that action, and RM would encode it into the String Variable.
b. We add a "literal" means of setting a String Variable, that does not apply the %xxx% transforms to the string being set into the variable in that action, thus allowing a URL encoded string to be put into a variable.
