Bug Report: Rules do not recognize Boolean extension attributes

I have a device handler that has some added text attributes and a boolean attribute.

If I select one of the text attributes when creating a rule I get offered a string field as you would expect.
When I select the boolean attribute I do not get offered a comparison field although the screen seems to think that I should be. See attached screenshot.

@Gary_Milne can you please post the link to the custom device handler so I can take a look? For the Switch attribute, there should be enum of “on”, “off” defined so rule engine knows what to be displayed as the options.

James, it is not an existing Device Handler, it’s one that I am writing.

attribute getSwitchName(1), “string”
attribute getSwitchName(2), “string”
attribute getSwitchName(3), “string”
attribute getSwitchName(4), “boolean”

Here is the doc showing the available types.

https://docs.smartthings.com/en/latest/capabilities-reference.html#capabilities-taxonomy

I can change these to enum but boolean is really all that I needed.

1 Like

Thanks for the update. I just verified and found the boolean problem. I’ve added this to my short list. Meanwhile, please use enum before the fix is released. Thanks for reporting.

There aren’t any official Capabilities which implement BOOLEAN and it was ultimately deprecated so we did not include support for it. There was a proposed capability with it.

The latest capability documentation can be found here:
Welcome to SmartThings | SmartThings Developers

Keep in mind that the Switch capability defines a single attribute called switch which is an ENUM with values ['on', 'off'] and commands on() and off().

Welcome to SmartThings | SmartThings Developers

If you are looking to control multiple switches, the most common approach in the SmartThings Groovy world is to use Composite Devices (aka. parent-child devices).
One simple home system. A world of possibilities. | SmartThings

You could use multiple custom attributes and commands on a single device, but there are compatibility concerns. The common practice would be to stick with the same style of attribute definition as the core capability you are mirroring. eg. attribute "switchN", "enum", ["on", "off"]. You can use these custom attributes and commands in the SharpTools Rule Engine, but you’re better off sticking with parent-child devices if you want to use them in the SharpTools dashboards.

1 Like

That’s right. I recalled the conversation about the deprecated attribute we had a while back after seeing this.Thanks @josh.