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.
http://192.168.1.138:5005/Master%20Bedroom/join/Living%20Room
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.
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?
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.
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?
http://192.168.1.138:5005/Master Bedroom/join/Living Room
look for variables to fill (no variables or % signs found, so skipping in this example..)
encode URL
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 
http://192.168.1.138:5005/Master+Bedroom/join/Living+Room
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.
Download the Hubitat app
