[DTH Multi-Component devices] Components not showing correctly

nayelyz · January 29, 2021, 4:49pm

Continuing the discussion from Custom Capability and CLI Developer Preview:

Hi, @krlaframboise. Here we can continue our conversation.
Can you share with me your DTHs source code, please? I want to see your configuration (Metadata, VID, etc.)

For the supportedButtonValues, you can use the enabledValues property in the device configuration, for example:

{
    "component": "main",
    "capability": "button",
    "version": 1,
    "values": [{
        "key": "button.value",
        "enabledValues": [
            "pushed",
            "held"
        ]
    }],
    "patch": []
}

This is how the device looks in Automations and the Detail View:

krlaframboise · January 29, 2021, 5:52pm

The Button Capability has the supportedButtonValues attribute that’s supposed to determine which buttons are shown in Automations and that has been working for over 6 months.

What’s the point of having that attribute in the Capability if you’re also going to have to specify it in the presentation?

A couple of days ago this was just an Android issue, but I just went to take a screenshot of iOS app to show you the difference and it’s now doing the same thing.

I’m a bit frustrated by this because it just broke about 10 of my handlers and most of them are paddled switches that support up to 5x for down and up so changing all the presentations is going to be time consuming.

krlaframboise · January 29, 2021, 6:03pm

The presentation provides a way to prevent all actions from being shown, but how do I solve the issue of a device with 4 buttons showing “pushed” 4x without being able to tell which components they go with?

@nayelyz, is the change that makes Automations ignore the supportedButtonValues attribute permanent or a bug that will be corrected in the near future?

nayelyz · January 29, 2021, 10:24pm

I see what you mean about the supportedButtonValues, I’m reviewing this with our engineering dept., I’ll let you know their answer.
About the components label missing on Automations I will open a report for them to review this behavior, as soon as I receive an update, I’ll post it here

krlaframboise · February 2, 2021, 2:12pm

Have they made a decision as to whether or not they’ll be restoring support for supportedButtonValues?

nayelyz · February 2, 2021, 6:57pm

Hi, their comments were:

supportedButtonValues is a field that is not included by every device, that’s why you need to specify if it’s used or not in yours.
To do so, you need to add this in your device configuration:

{
    ...
    "automation": {
        "conditions": [
            {
                "component": "button1",
                "capability": "button",
                "version": 1,
                "patch": [
                    {
                        "op": "replace",
                        "path": "/0/list/supportedValues",
                        "value": "supportedButtonValues.value"
                    }
                ]
            }
    ...
}

I noticed that when we create the device config with the same configuration as before and we add these new values in patch, it is not included in the creation, like this:

automation:
  conditions:
    - component: main
      capability: button
      version: 1
      values: []
      patch:
        - op: replace
          path: /0/list/supportedValues
          value: supportedButtonValues.value
    - component: main
      capability: healthCheck
      version: 1
      values: []
      patch: []
  actions: []
type: dth
presentationId: 3d3312c5-1be6-3fed-8b30-257180e6c3cc
manufacturerName: SmartThingsCommunity
vid: 3d3312c5-1be6-3fed-8b30-257180e6c3cc
mnmn: SmartThingsCommunity
version: 0.0.1

We have to make a modification to the device config and a new VID will be generated. (We can add/delete capabilities that don’t affect the device UI, eg. Refresh, HealthCheck).
I already notified the team about this behavior, for now, I suggest that workaround. I’ll see if there’s something else that we can do.

krlaframboise · February 2, 2021, 9:41pm

So they made a change that broke the default behavior that it’s had for 6+ months and they have no intention of fixing it so the device configs of all DTHs using the button capability need to be modified to fix it…

Which solution is less likely to break in the future? Explicitly specifying the enabledValues like you originally suggested or this patch workaround?

orangebucket · February 2, 2021, 11:03pm

Nayely, I don’t really want to interrupt the flow of this thread but I can instantly see broader implications here.

If this applies to supportedButtonValues in the Button capability, does the same thing also apply to other capabilities where there are supportedAttributeName type attributes for the actual values being used?

There actually seems to be quite a few capabilities like that, albeit with no consistent pattern to the attribute names, and varying as to whether there are any enumerated values or if it is a free for all. For example, fanMode / supportedAcFanModes, and inputSource and supportedInputSources.

To be blunt, the variations in the ‘supported’ attribute names are such that they just seem like bespoke attributes to support bespoke capability UIs. They don’t really look like part of a grand plan.

I am struggling to think of a use case for attributes like supportedButtonValues apart from in presentation, and is that really what attributes should be used for? They feel like a bit of a fudge. The enabledValues key in the device config seems to be a better idea. This really is an area where knowing the goal would help.

Correction: Although they still feel like a bit of fudge, using supportedButtonValues does, of course, mean the presentation will work with multiple device types in a single DTH, whereas enabledValues seems to be static.

krlaframboise · February 3, 2021, 2:19pm

That’s a good point about there being others and I suspect the change impacts all capabilities with “supported…” attributes.

If the attribute is part of a capability then I wouldn’t consider it a “free for all”. It’s also still being used by Smart Lighting and Speaker Companion, but I’m assuming those apps will be going away around the same time as the IDE…

I agree that enabledValues is the standard way of limiting options in presentations so I plan on fixing my handlers that way instead of using that patch workaround.

Automations not using the “supported…” attributes isn’t necessarily a bad change because consistency across all capabilities is good, but it would have been nice if the engineers acknowledged that they made a breaking change.

I also wish they’d let us know ahead of time when they plan on making breaking changes so that developers can update their handlers before the change is made, but I know that will never happen.

I guess my frustration expressed in previous posts stems from repeatedly having to modify my handlers because of changes they make. Fixing things in the presentation is also really frustrating because the caching of the presentation often results in existing users not seeing the changes for a long time after updating the handler.

On a completely different note, does it bother anyone else that the Button capability has 3 instances of “6x”, which hardly any devices support, but it doesn’t support “released”? I’ve been complaining about that since they modified the button capability and that seems like an extremely simple change they could make that wouldn’t end up breaking anything…

That’s another really good point and it’s probably the reason why it was added to those capabilities, but there are other capabilities like “Alarm” that should have it and don’t.

It seems like that will be an issue for the built-in generic handlers, but I create custom device configs for all my custom handlers anyways so I still plan on using the enabledValues feature to fix mine.

orangebucket · February 3, 2021, 2:38pm

Probably lazy wording on my part. I was trying to contrast capabilities like Button where the allowed values are all enumerated, with something like Air Conditioner Mode where airConditionerMode/ supportedAcModes are strings but there are no restrictions on the values (OK there are values in the reference documentation but they do not exist in the actual capability in the API).

I was going to do the same thing until I released I had a handler that supported about four different button types, all with different values.

Curiously, the configs used with the stock Ikea Button handler show no sign of needing to patch the supported values or use enabledValues.

krlaframboise · February 3, 2021, 4:09pm

I think they added that “patch” workaround to the built-in presentations so that change only needs to be made for handlers using custom presentations.

nayelyz · February 3, 2021, 9:58pm

Hi, folks. Thanks, both of you for your comments. I’ve reported this behavior and I’ll see if I can get an official answer about the supportedValues future. As soon as I receive an update, I’ll post it here.
About the difference between both workarounds, you’re right:

enabledValuesrequires a device-config update
Using the values in patch allows you to update the supportedButtonValues from the DTH and the new values will be shown.

krlaframboise · February 3, 2021, 10:17pm

We’re still going to have to update the device configs of all our custom handlers because the “patch” needs to be added to the device config…

orangebucket · February 3, 2021, 11:20pm

Ideally I’d like to have the option to set enabledValues from e.g. supportedButtonValues.value.

RBoy · February 5, 2021, 7:11pm

nayelyz:

"patch": [
                    {
                        "op": "replace",
                        "path": "/0/list/supportedValues",
                        "value": "supportedButtonValues.value"
                    }
                ]

Can you explain how the path and value works? The documentation seems to be incomplete

Also visibleCondition also doesn’t seem to be working (I think there’s an open ticket for it).

nayelyz · February 5, 2021, 10:49pm

Hi, I see there’s no description for the value property, I’ve reached out to our engineering team to let them know and to see if they can provide an overview about it. I’ll let you know their comments.

Yeah, I also verified the status of this issue, the fix development has been finished but there’s no ETA for its release yet.

krlaframboise · February 10, 2021, 4:12am

Any news on this?

The built-in zooz power strip handler has the same problem.

nayelyz · February 10, 2021, 7:29pm

Hi, Kevin. Our team continues checking this issue, however, I’ve seen that the options showed in Automations correspond to the order of the components at the device presentation.
For example, the Zooz Power Strip device uses this VID SmartThings-smartthings-Zooz_Power_Strip, this is verified in the device description:

{
    "deviceId": "xxxx-xxxx-xxxx",
    "name": "ZoozPower",
    "label": "ZoozPower",
    "manufacturerName": "SmartThings",
    "presentationId": "SmartThings-smartthings-Zooz_Power_Strip",
    "locationId": "xxxx-xxxx-xxxx",
    "deviceTypeId": "xxxx-xxxx-xxxx",
    "deviceTypeName": "Zooz Power Strip",
...
}

The order of the components that presentation is:

main
ch1
ch3
ch4
ch5

It’s something similar to the picture below:

This way, you can have a better reference on which option to choose when creating an Automation.

krlaframboise · February 11, 2021, 6:21am

I know it’s possible to figure out which component they go with, but it’s not that straightforward for a device like a smart plug that has left and right outlets.

It also becomes a lot harder to line them up when you have to scroll through a long list of options, like the ones below for a 5 button scene controller.

Pressed
Held
Pressed 2 times
Pressed 3 times
Pressed 4 times
Pressed 5 times
Pressed
Held
Pressed 2 times
Pressed 3 times
Pressed 4 times
Pressed 5 times
Pressed
Held
Pressed 2 times
Pressed 3 times
Pressed 4 times
Pressed 5 times
Pressed
Held
Pressed 2 times
Pressed 3 times
Pressed 4 times
Pressed 5 times
Pressed
Held
Pressed 2 times
Pressed 3 times
Pressed 4 times
Pressed 5 times

I personally see this as a big problem for end users, but I haven’t seen a lot of other complaints about it so maybe I’m wrong…

orangebucket · February 11, 2021, 11:06am

I think it is so ridiculous that end users seeing it just assume it can’t possibly have been finished yet. However the finger will be pointed at you rather than SmartThings, simply because it doesn’t seem credible that there is nothing you can do about it.

There isn’t just an issue with the components either. I know I’ve mentioned it somewhere before, but what is displayed is a mish-mash of different things. For example for one of my devices which has three component buttons, I get:

* STHM Status
* Pressed
* Pressed
* Pressed

STHM Status is the name of a custom capability.
Pressed is a value of the button attribute of the Button capability.

Two different things, two levels in the hierarchy apart.

For consistency I should see either a list of values:

* Armed (Away)
* Armed (Stay)
* Disarmed
* Pressed
* Pressed
* Pressed

in which case there needs to be Component AND Attribute labelling, and possibly Capability as well though skipping that is probably fair enough, or I should see a list of attributes

* sthmStatus
* button
* button
* button

in which case I should see Component and possibly Capability labelling, or I should see a list of capabilities:

* STHM Status
* Button
* Button
* Button

in which case I need the Components to be labelled. You could even argue that what I should see is the components.

* Main
* Arm
* Stay
* Disarm

Obviously clicking on something should take me a level down the hierarchy. Which leads me to the following …

Clicking on STHM Status shows:

STHM Status

* Armed (Away)
* Armed (Stay)
* Disarmed

Not so bad in this particular case but only because all those values come from the same Attribute. What if I had more that one attribute?

[DTH Multi-Component devices] Components not showing correctly

Customers

Developers

Download the SmartThings App