Triggered: Trigger End Point Set Variable My%20Variable%20Name to foo
While there is no error, there is no such variable. My variable is named "My Variable Name".
It looks like % signs are allowed in variable names. I am able to create a hub variable named "My%20Variable%20Name", so that variable could exist.
However since the command is coming in via a web request, I would expect that to access My%20Variable%20Name I would have to encode the special characters in the URL as something like "My%2520Variable%2520Name" and that "My%20Variable%20Name" would be interpreted as "My Variable Name"
Your best bet is to just avoid spaces in variables names. In any regular coding, you cannot have spaces in variable names, so I'm surprised they even allow that with hub variables.
You can just use standard camel-case, like myVariableName, for the variable name. Any web request will always substitute %20 for a space, as the html string also cannot have spaces in it.
Maybe Maker API should be substituting the %20 back to being a space for Hub Variables, but there could be a good reason why it doesn't do that, probably because it is treating all requests the same, and there is no special case being called out where it checks that you are setting a Hub Variable, to do that conversion.
I I almost wrote in my original post that I know people are going to say not to use spaces in the variable name, but I display this hub variable on a Hubitat dashboard, and it looks better with the spaces. I'm_using_underscores_for_now,_but_it_looks_better_without_them.
I don't think this is a Maker API function. To set the hub variable you have to have a Rule Machine rule set up to receive the request. The app ID in my URL isn't the Maker API app ID, it is the app ID of a rule I named "Endpoint for setting hub variables" that has a local endpoint as the only trigger and no rule actions defined. It definitely feels Maker API-adjacent, but I think the variable setting rule would work even without the Maker API app installed.
URLs can't have embedded spaces without URL encoding. As suggested by the documentation, only the value to be assigned can be URL encoded, not the variable name. At this point, I have no interest in discovering what the unintended consequences might be the hard way, that is by URL decoding the variable name. Users have relied on the implementation the way it is, and has been for years. So, Hub Variables with embedded spaces in their name cannot be set by the RM endpoint.
To put a finer point on it, any Hub Variable with an embedded + in the name can be set by the endpoint, but URL decoding the Hub Variable name would decode the + to a space. Thus, without URL decoding 'my+var' is a valid variable name that might be set by an endpoint, but only if the variable name is not URL encoded. If URL encoded, that would become 'my var'. So we can't add URL decoding for the variable name without potentially invalidating rules currently in use -- this being just one example.
It was not difficult to add an additional endpoint.
/setHubVariableEncoded=varNameEncoded:varString
For this endpoint, both the Hub Variable name and the String value to assign would be URL decoded by the rule. With this, you could use + to represent a space in the Hub Variable name.
Adding this took me about 30 seconds.... It will be in an upcoming release...
