Rule Machine HTTP GET Parameter Bug

I have an issue where a Rule Machine HTTP GET call fails. This was built for the node.js Sonos integration. I think the problem is RM is picking up the two percent signs and attempting to populate a variable which then causes the HTTP call to fail. Is this bug? This exact call works fine in a browser.

Bug/feature. Yes, RM is trying to do a variable substitution because of the %s. There's a conflict between that use of % and its use in an encoded URL. Perhaps a way around it would be to put the url in a variable, and use the variable in the HTTP GET action.

1 Like

Here's a workaround:


Instead of Log Message action would be the HTTP GET action.

1 Like

The Sonos integration requires the speaker name with spaces in the URI part. Your proposed fix is a bit ugly, any better way to do this? Why not use different symbols for variable filling? Don't use %?

Changing that in a subsequent version of the Hub's firmware would mean that every rule that currently exists that uses a variable would have to be updated to use the new value. I don't even want to think about the support headache such a change would cause.

Why does your speaker name have to have spaces? Why can't it just use underscore or one long name with no spaces?

1 Like

Changing that would be (a) easy, and (b) blow up every existing rule that uses them. Between what @Ryan780 says and an easy work around, you should be set.

1 Like


is what I asked myself a year ago ...... and an acceptable answer was:


Let's think outside the box when preserving the % variable fill process within RM. I'm assuming the application logic to fill variables and to encode the URL are most likely synchronous.

Why not change the order of these functions so that this URL works instead? Bedroom/join/Living Room

  1. look for variables to fill (no variables or % signs found, so skipping in this example..)

  2. encode URL

  3. send the request

RM does not encode the UR, the user does if it's required by the situation.

Thinking outside the box, why can't you just do the simple replacement shown above? Or don't use spaces in the speaker name?

Here is another work-around:

For this one use case you can use + in a URL instead of %20 and it will mean space. It also reads nicer :wink:

Most templating systems I'm familiar with translate the doubled meta character (e.g. %%) to be a single character of that type with no meta meaning. This would probably not break any existing users, and make it possible to deal with multiple Unicode characters in a URL, etc


Bruce, are you going to change the code or should I just go with replacing %20 with +? I'm fine with + for now, going to test it tonight, assuming it works..

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.