I've noticed that Hub Variable Connectors have a (leftover?) command called "Parse" that doesn't seem to do anything in most cases (except it turns Booleans/Switches to 'Off').
Yet it's one of the two commands available to these Device types in Maker API, setVariable and parse. So I assume it's original intent was to parse incoming information in some way different from setting the hub var value directly, as referenced in the Docs:
Who maintains the codebase for Hub Variable Connectors? As I'd like to formally request that the parse command be fully implemented so that:
• Sending an appropriate endpoint via Maker API would pass data to the connector Device without changing its current value, for instance: http://[hub_IP]/apps/api/[Maker_AppID]/devices/[DevID]/parse/[Secondary_Data]?access_token=xyz
• A corresponding attribute in the driver would be updated to reflect the sent value.
• Optional: attr could magically send updated event even if same value re-sent, in the same manner as Room Lighting activators respond to "On" even if already "On"
This would allow other apps, like Rule Machine, to watch that attribute and do something with it prior to updating the Hub Var Connector's value.
Working example:
Dashboard tile is tapped
> Sends endpoint URL (parse/cat)
Hub var connector updates
> (attr: cat)
Rule Machine triggers on update
> IF attr == cat THEN setVariable = Binkers
Hub var value updates
> value: Binkers
A hub variable connector is essentially a virtual device, so the information you found in the docs that refers to mostly Z-Wave and Zigbee devices is not applicable, but the note about virtual devices is. In these cases, it is up to the driver if or how it uses this command. It is generally not meant to be called directly. The fact that it happens to set your variable false is likely just an unintended side effect of calling it with invalid data (likely no data, as you'd get when trying it from the UI, as you appear to be).
I'm not sure I understand your use case:
You have a switch connector created, so the underlying variable is probably a boolean
The only valid values for a boolean are true or false (seems like you want to do something with "cat"?)
The on() and off() commands provided by the connector are the ways you set the underlying variable true or false, so, given the above, there should not be a need for parse() for (and similar with other connectors -- the entire point of making one is to get "standard" commands so apps can use those if they don't support variables directly)
If you need an HTTP endpoint to change a variable, Maker API can't do that directly (by which I mean using the variable directly without a connector; using a connector is still an option, but you'll need to use the regular device commands as above). Maybe that is something that could be added. However, Rule Machine can. You just need to create a rule with a local or cloud endpoint trigger (whatever you need, or both), then see the "Set Hub Variable" section here for the path and format to use to set variables via an endpoint:
(Note that you actually don't need to do anything in that rule; you just need to create a trigger so you get the endpoint, exposing the API over HTTP. But I suppose that creating a rule triggered by an endpoint where you actually do things in the actions in response is also an option, and one of those things could be setting a variable, perhaps different things depending on some conditional actions.)
Okay, thanks for the detailed response. I need to soak this all in.
Since you asked, the connectors I planned on using this most with are indeed String type. The ultimate goal was to allow a single dashboard control to both send data to, and independently display the resulting change in value of, the underlying hub variable.
I had not considered the possibility of using Rule Machine as a back end for that very purpose. Much appreciated suggestion!
One point of order... the RM Docs present a limited set of Actions applicable to the endpoint calls, among them:
Set Private Boolean True:
action: "setRuleBooleanTrue"
Set Private Boolean False:
action: "setRuleBooleanFalse"
Since no mention is made in the RM API of passing variable values to RM (for use with, say, setting Local Vars therein), is it safe to assume that would be impossible? That is to say, none of an RM rule's internal variables could be directly set via external HTTP Request. I just wanted to nail that down in my mind.
The endpoint I provided above can set a hub variable. I don't believe there is an endpoint to set a local variable for a particular rule.
Also, it appears you may be looking at the section intended for Groovy apps using the RM API. If you are writing a Groovy app on the hub, you do not need to use the RM API to set variables; you should use the hub variable API. If you are looking for the RM HTTP API, as you'd need from an external system, scroll down a bit and you'll see it there. There is some overlap between the two, and most (all?) of the things that can be done with the Groovy API can be done over HTTP, but I believe there are some that can only be done over HTTP and are thus only documented there.
The "formal" docs have also now been updated with this, which I saw was missing before after this prompted me to look at them: Rule Machine | Hubitat Documentation
Upon further testing, it appears (although this function may not be documented?) that you can pass a value to RM by constructing the Local End Point as follows:
where [VALUE] is any text or urlencoded string. For example, including varValue in that position results in the rule capturing this in the %value% event variable:
