Local Variable Value Problem

As for variable names it is clear that a backslash \ is not allowed:

"DO NOT use these characters: ' " \ ~ [ ] < > in Hub Variable Names" appears as a warning within the rule machine.

My problem is with the string value in the variable. I have a node js server running that accepts the following GET, e.g. http://192.168.68.89:8080/?picpath=C:\DP3Q0011.JPG. I am using this as part of my continuing development of a Meural Canvas Driver.

In my use case I want the user to be able to enter the variable value in a format familiar to a windows user e.g. C:\DP3Q0011.JPG with a backslash.

In the server code I translate the "\" to %2F as the code expects. This works just fine in a browser.

Additionally, if I supply a variable value with Hubitat for the %2F instead of the "\" all is well.

However I get a failure when the variable value is C:\DP3Q0011.JPG. What is strange is that the current value display in the rule machine is perfect. That is, it shows precisely the url that I am expecting. In fact I can copy and paste it into a browser and it works perfectly.

Even the log looks right but in practice it fails without error. That is to say that the node js does not respond at all to the GET.

So my question is, why does it fail in practice and is there a fix that would still facilitate the use case and allow the user to enter the path in a windows manner with the "\"?

Minor point, Windows doesn't care which direction the slash goes, i.e. it will accept / as well as \ for use as a pathing delimiter. The correct answer however is that RM does include an option to do a URL Encode which should resolve your issue if used correctly.

2 Likes

@thebearmay agreed and understood on the windows point. I'm simply trying to meet a non technical user's expectations and common conventions. As an aside, I frequently find that Hubitat "stuff" quickly goes beyond ordinary user abilities so I am striving to avoid that. My two cents... as I hope that the Hubitat product continues to thrive and I want to do my part to make it accessible to all.

Anyway, many thanks for the URL Encode tip. Didn't know about that. It does require an extra step in the RM but it certainly works just fine. Thank you!

Marking your comment as a solution.

2 Likes