[Limitation] Boolean Custom Attributes disallowed?

This was discussed once or twice previously – even considered for adoption several years ago – so I'll have to read up on whether this is still a known/intentional limitation in Rule Machine, or might be fair game to request going forward:

Expected behavior: Support triggering RM rule on change to True/False value in Boolean device attribute, in line with other attribute types.

Use case: In my example above, I'm seeking to "mirror" the Connected status of a pinged network device with a boolean Hub Variable, which in turn is used in Required Expressions, etc.

(Alternative feature request: Enhance the Mirror app by allowing "Custom Attribute" as a capability type for setting variables/booleans/switches; although this strays a bit far from the intentional simplicity of Mirror.)

Rule Machine is correct in stating that "BOOLEAN" is not a supported attribute type (on the platform in general, not just something that isn't implemented here; this was not always clear). The driver should be modified to use something else, most commonly "ENUM" or "STRING".

See:

2 Likes

I'll go ahead and modify the custom device driver accordingly, and thanks for pointing out that work-around. Tagging @gilshallem since this involves his PC Controller driver.

Boolean, in the programming language sense of the name, has never been a supported attribute type for Hubitat drivers. While Groovy does have the type Boolean, and variables can be of that type with values true and false, that is Groovy the language, not the platform.

RM does support the supported driver attribute types. Easy to do this using a Boolean attribute of type ENUM, with ["false", "true"] as the possible values. Or, as @bertabcd1234 suggests, the attribute type could simply be STRING, with the "false" and "true". The corresponding RM Custom Attribute trigger would need to match -- it pulls the attribute type and possible values from the device (as defined by the driver) to present in the Rule UI.

2 Likes