[ST Edge] Custom device config

Hi,

I created an edge driver for Aqara dual channel switch.
The driver creates device with switch capability under the main component and additional 2 switch components.

The detail view is shown below:

In order to make sure the Switch1 and Switch2 are shown above the main component, I needed to create a custom device config, as was suggested by @iquix in [ST Edge] Does the order of declaring components has any meaning?.

However, device config did not help with the order of components in automation view.
Further, in automation view it is not possible to know to which component the switch capability is related.

Hence, I have 2 questions:

  1. How it is possible to specify the order of capabilities in automation view?
  2. How it is possible to provide a custom label to capabilities in automation view

Thanks

Yes, the engineering team is already working on this issue, it’s not related to Edge drivers only, it affects all multi-component devices.
About how to identify the components, they follow the order you defined in the Automation View. Remember you can check your presentation as follows:

// Using the ST CLI command:
smartthings presentation vid -j

//Sending a REST query to:
https://api.smartthings.com/v1/presentation?presentationId=vid&manufacturerName=SmartThingsCommunity
1 Like

Thank you @nayelyz ,

While it seems the order of components in detailed view follows one in device config, it is not so for automation view.
Here is my device config:

device-config
mnmn: yashik

version: 0.0.1

type: profile

dashboard:

  states:

    - component: main

      capability: switch

      version: 1

      idx: 0

      group: main

      values: []

  actions:

    - component: main

      capability: switch

      version: 1

      idx: 0

      group: main

detailView:

  - component: switch1

    label: Switch1 Test

    title: Title

    capability: switch

    version: 1

    values: []

    patch: []

  - component: switch2

    capability: switch

    version: 1

    values: []

    patch: []

  - component: main

    capability: switch

    version: 1

    values: []

    patch: []

  - component: main

    capability: temperatureMeasurement

    version: 1

    values: []

    patch: []

  - component: main

    capability: powerMeter

    version: 1

    values: []

    patch: []

  - component: main

    capability: energyMeter

    version: 1

    values: []

    patch: []

  - component: main

    capability: voltageMeasurement

    version: 1

    values: []

    patch: []

  - component: main

    capability: amberpiano10217.currentMeter

    version: 1

    values: []

    patch: []

  - component: main

    capability: signalStrength

    version: 1

    values: []

    patch: []

  - component: main

    capability: refresh

    version: 1

    values: []

    patch: []

  - component: main

    capability: configuration

    version: 1

    values: []

    patch: []

  - component: main

    capability: healthCheck

    version: 1

    values: []

    patch: []

automation:

  conditions:

    - component: switch1

      label: Switch1

      capability: switch

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: switch2

      capability: switch

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: switch

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: powerMeter

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: energyMeter

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: temperatureMeasurement

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: voltageMeasurement

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: amberpiano10217.currentMeter

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: healthCheck

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: signalStrength

      version: 1

      values: []

      patch: []

      exclusion: []

  actions:

    - component: switch1

      capability: switch

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: switch2

      capability: switch

      version: 1

      values: []

      patch: []

      exclusion: []      

    - component: main

      capability: switch

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: energyMeter

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: refresh

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: configuration

      version: 1

      values: []

      patch: []

      exclusion: []

    - component: main

      capability: healthCheck

      version: 1

      values: []

      patch: []

      exclusion: []

As you can see the order of components in automation view is

automation:
  conditions:
    - component: switch1
      capability: switch
   ...
   - component: switch2
     capability: switch
  ...
  - component: main
    capability: switch

However, it is not preserved, not for actions, not for conditions

Ok, it seems it affects those that use a number in the component name (eg. switch1, switch2). When I create a profile and presentation using names without numbers, the order is followed correctly.
I’ll create a report for the engineering team to look at it. Thank you for bringing this up! :smiley:

Also, did you set manually the value of mnmn: yashik? When we create a device presentation, the default value for mnmn is SmartThingsCommunity.

1 Like

Hi @nayelyz ,
Thank you for your response.

Yes, mnmn was changed manually.

The idea was to use it as a filter (for example, to use different mnmn for capabilities/presentations used for tests and for released drivers).

Is it a problem to modify this field?

I made some tests to check and there are no issues when we create the presentation and use it on a device. However, I asked the engineering team to know if there are any restrictions. I’ll let you know their feedback.

1 Like

Hi, @ygerlovin. The ability to set a custom mnmn value is considered a bug (thank you for letting us know!).
The reason is that if this is possible, devs could enter some keywords that would cause a conflict, eg. “SmartThings”. The engineering team is working on this fix and later on, this field will be set automatically.
Please, consider this for the presentations you already created.
I’ll let you know when the fix is released.

1 Like

Thank you @nayelyz .
So I guess the best way is just to remove it from yml/json files

yes, you can create a device-config without adding this field and it should assign “SmartThingsCommunity” automatically and you can use that presentation normally.

1 Like