DTH Child Devices isComponent:False

Continuing the discussion from Custom Capability and CLI Developer Preview:

Hi, @KeithR. I opened this new thread to continue our conversation. Please, allow me some time to review your configuration and I’ll come back.

1 Like

Thank-you @nayelyz !

@orangebucket is right, the componentName and componentLabel properties shouldn’t be included. This is because when the child device is created, its component name is set to the defined value in addChildDevice(), like this:

    "components": {
        "ep1": {
            "configuration": {},
            "refresh": {},
            "switch": {
                "switch": {
                    "value": "off",
                    "timestamp": "2021-02-04T02:00:54.186Z"

As the device presentation is configured with the componentName=main the device UI is not shown correctly because names don’t match.

Any chance you can make future changes backward compatibility (non-breaking) to existing codes? Or at least document breaking change?

For example, this componentName and componentLabel (breaking change) have been working for so long, until last year, when it broke suddenly.

It could be “discarded/ignored” by the ST platform than just letting it break.
It wasn’t documented as well. I’ve had to spend so much time debugging, and referring to ST’s github commit history!

1 Like

@nayelyz THANK-YOU!! You (and @orangebucket and @hongtat ) were exactly right. Once I removed the componentName and ComponentLabel, and recreated my child devices they all showed up as expected. I appreciated the help from all of you!

1 Like

What do you mean it broke, do you have issues with it?
Using these properties doesn’t cause an error, they are actually used, the problem, in this case, is the mismatch with the presentation’s componentName and device’s componentName.
If we set a presentation with the name defined in addChildDevice(), we can keep using isComponent:False with those properties.

What information is missing?

I’m referring to this. It used to work in the classic and new app. It broke in the new app last year; Google/Alexa cannot control them or discover new devices , if custom DTH has -

isComponent: false, componentName: “xxx”, componentLabel: “xxx”]

The doc is outdated and couldn’t find anything in the forum and I have to dig through the commits to find this (although it didn’t mention that it would break in 2020).

The document mentions that those properties are required only when the child device is a component, so they weren’t supposed to be used if it was a separate device.
If they have an impact now, it could be due to the usage of the device presentation (which has the components information) and that the integrations are more capability-oriented, this means they’re focused on the capability’s real properties and location (component).
I understand it can be challenging to find the root cause of the behavior changes. In case you have questions, you’ve found something out of the ordinary, etc. you can always post them and tag me (@nayelyz).