Additional support for components

[dwradcliffe]

Description:

Small changes to assist in supporting components in the home assisstant integration.

It's nicer to be able to loop through all the components instead of having to treat main as different. I don't think this will break anyone else's existing use since it's just adding something.

Also added a convenience method to get the list of disabled components, if available.

This PR is required for home-assistant/core#99924

Related issues:
#44
home-assistant/core#91892

Checklist:

• The code change is tested and works locally.
• Local tests pass.
• There is no commented out code in this PR.
• Tests have been added/updated and code coverage percentage does not drop. No exclusions in .coveragerc allowed
• README.MD updated (if necessary)

[dwradcliffe]

@andrewsayre I believe this is ready for review, thanks!

[andrewsayre]

This is from the custom namespace, which means this capability has no formal definition and can be changed by any device implementing it. Meaning, it's not guaranteed to be a dictionary of strings (like you're expecting) and will result in runtime errors if assumed to be so. Given the nature of custom capabilities, they don't below as first class members in this library.

[alrassia]

I just noticed your comment on the pr for home assistant, if I understood well the idea is that such functionality is implemented on the ha side and not the library correct?

[dwradcliffe]

That's my question too; would you accept this moved to ha/core, assuming we check the data type first? Or alternatively check the data type here which would be simpler, IMO.

[yardee]

All methods updating status (like switch_off) needs to take to account component_id in the parameter, because it updates always state of the "main" component, not a correct one. For example if you swith off some component (not the main), it switchs off also main component in device state (it is not really switched off in the smart things device).

[wawyed]

I was wondering if there's any update on this. I was hoping to control my heat pump via home assistant and this seems to be required for it to work. Thanks a bunch!

[alrassia]

I was wondering if there's any update on this. I was hoping to control my heat pump via home assistant and this seems to be required for it to work. Thanks a bunch!

andrew has not been active to give insights on the open question. Same goes for the open smartthings pull requests in the HA repository. Seems smartthings is kind of in need of a new maintainer.

[contemplator1998]

Just in case, here is a fixed (at least for me) SmartThings you can install via HACS: https://github.com/contemplator1998/smartthings

(Pulled home-assistant/core#99924 and wrapped into a HACS repo)

It makes everything accessible, even sensors/controls that are always unavailable (just disable them in the HA).

[elad-bar]

with that approach it might introduce unwanted capabilities, to support all components with all commands the code should be bit more flexible, i have no issue to implement it but the question is whether @andrewsayre will approve it.

just to explain what I thought:
instead of having hard coded capabilities, attribute and command mapping - change it to relay on capabilities endpoints, including validation details,
once it's there, we can change the mapping just to component types, meaning binary sensor, switch, sensor, select, light, etc...
each of them will be fully agnostic to the capability schema and will just follow it up, unless there is specific implementation like for 3 axis or power consumption report.

the pros/cons of the generic approach is that in HA all components will be supported also for newly added devices and capabilities, cons of it - bit less readable in terms of code (generic terms), samailir to any hub (zigbee2mqtt, xiaomi, etc...)

@andrewsayre , please let me know if it worth the investment

[andrewsayre]

@elad-bar can you elaborate further? How would mapping to more complex platforms (e.g. climate) work? For example, there is conditional logic to map groups of capabilities to platform features and maps of attribute values to states.

[elad-bar]

I'm working on a seperate python project (will share when it is ready) based on the api,
Eventually there should be mapping somewhere, what i envisioned is to restructure device status / device status based to expose all components the same,
Extract all capabilities relevant to devices in the account and based on the schema of them to perform the mapping (sensor, binary sensor, light and switch), more complex entities should be grouped but in HA, as this is functionality of HA,
For that there should be mapping of HA components with specific ST capabilities of specific ST component similiar to the integration but use more data that lacks right now (as mentioned above),
I will share with you once it's ready (hopefully by end of the week)

[elad-bar]

You can have a look into another integrations i contributed similar functionality:
https://github.com/radical-squared/aquatemp
https://github.com/sh00t2kill/dolphin-robot

Of course for that integration it would be "bit" more challenging as it has more complex entities, key is to extend the EntityDesceiption of HA to be able to deal with it

[elad-bar]

I found out the presentation api that supposed to make it easier, for each device it allows to get the relevant capabilities to construct complex ui components including actions and automation

[elad-bar]

investigated a bit the api,
for instance:
https://api.smartthings.com/v1/capabilities/thermostatHeatingSetpoint/1/presentation
provides the presentation of how that capability should be presented in dahsboard, details view (most relevant for HA) and automation.

below is the json of the response:

{
    "dashboard": {
        "states": [
            {
                "label": "{{heatingSetpoint.value}} {{heatingSetpoint.unit}}",
                "alternatives": [
                    {
                        "key": "C",
                        "value": "°C",
                        "type": "active"
                    },
                    {
                        "key": "K",
                        "value": "°K",
                        "type": "active"
                    },
                    {
                        "key": "F",
                        "value": "°F",
                        "type": "active"
                    }
                ]
            }
        ],
        "actions": []
    },
    "detailView": [
        {
            "label": "{{i18n.label}}",
            "displayType": "slider",
            "slider": {
                "range": [
                    0.0,
                    40.0
                ],
                "unit": "heatingSetpoint.unit",
                "supportedValues": "heatingSetpointRange.value",
                "command": "setHeatingSetpoint",
                "argumentType": "number",
                "value": "heatingSetpoint.value",
                "valueType": "number"
            }
        }
    ],
    "automation": {
        "conditions": [
            {
                "label": "{{i18n.label}}",
                "displayType": "numberField",
                "numberField": {
                    "value": "heatingSetpoint.value",
                    "valueType": "number",
                    "unit": "heatingSetpoint.unit",
                    "range": [
                        0.0,
                        40.0
                    ],
                    "supportedValues": "heatingSetpointRange.value"
                }
            }
        ],
        "actions": [
            {
                "label": "{{i18n.commands.setHeatingSetpoint.label}}",
                "displayType": "numberField",
                "numberField": {
                    "command": "setHeatingSetpoint",
                    "argumentType": "number",
                    "unit": "heatingSetpoint.unit",
                    "range": [
                        0.0,
                        40.0
                    ],
                    "supportedValues": "heatingSetpointRange.value"
                }
            }
        ]
    },
    "id": "thermostatHeatingSetpoint",
    "version": 1
}

it is possible also to define new presentation per app, for instance, for HA smart thing app (has its own app id), then, it will be easier to translate the displayType to specific HA component.

[elad-bar]

@andrewsayre pls review the repo i released my poc, didn't want to push it as PR here.
https://github.com/elad-bar/dynamic-smart-things

• Importing devices, components, capabilities and attributes
• Importing locations and rooms
• Importing capabilities and their details
• Performing commands including validation (all capabilities with commands are supported)
• Future support of additional capabilities and attributes
• Excluding components and capabilities marked as disabled
• Diagnostic details for debugging available over function (HA can use it for diagnostic of integration)
• Dynamically mapping simple entities to binary_sensor, sensor, number, switch, select
• Dynamically mapping complex entities to climate, fan, media_player, light, lock

[elad-bar]

@andrewsayre did you manage to review my repo with poc?

thanks

[moebis]

Is there a working plugin for SmartThings yet? I know the official one has been broken forever, there is a HACS version that finally shows the temperatures of Samsung Fridges, but loses the ability to show power consumption (the only thing that works with the official version). If anyone has a working plugin (HACS or not) please ping me. Thank you!