I also ask for help on this issue, honestly this problem is very disappointing.
Apologies for my ignorance but can someone explain the issue in greater detail? I am unsure what is being discussed though clearly a number of users are experiencing it.
Multi component devices like 2 gang switches:
Or dual relays:
Having a DTH with A parent/child construction allows the user to give each child a custom name and allows you to then voice control them from Alexa.
Multi component Edge drivers don’t at present allow the user to change the name. Even worse for many users is that only the equivalent of the parent is exposed to Alexa. You can’t control the child components by voice at all.
@nayelyz is aware of the issue, but no timeline has been given for fixing it, and it is limiting the usefulness of edge drivers for a number of people.
Existing discussion thread:
as you can see in the image when you add a device that has more than one channel (example of this one that has 3). There is no possibility to rename them (it only has these default names main, switch1, switch2, etc.) and only the most appears in alexa and google, the others do not. In my living room I use one of these and today I can only turn on a light by voice command because the others do not appear in alexa. Another problem is if using smart lighting in the device list all switches appear together and it is impossible to know which is which. So it would be very interesting to be able to rename each channel and for them to appear independently in alexa or google (the same thing happened with DHT). Did you understand?
@Mariano_Colmenarejo told me that this is not possible because the api doesn’t allow it.
To be honest, I gave up using drivers because of that. All my switches are 3 channel and I was only using voice to trigger the first one
I apologized in advance as this is well outside the scope of my day to day job responsibilities at SmartThings. Please understand that the Edge architecture is still in beta and that support offered by non developer-relations individuals such as myself is often on my own time. Your patience is appreciated.
Thank you. I was not aware of this limitation but this helps me understand the issue at least.
I understand. As most users have a device with more than 1 channel this is a huge problem. But I hope the team can look into this as soon as possible, as via the LAN api this already seems to be possible. The problem is occurring from what I was told in zigbee and zwave
Ok, in order to avoid more confusion, here’s more information:
The issue is that the label is ignored in the device UI, even if we assign one to that component (in the device profile), the ID is displayed in the app instead (detail View), which is already reported.
- It happens for all the integration types DTH, ST Schema, direct-connected, etc. So, it is not limited to Edge drivers
- The label appears correctly in the Routines tool.
But users being able to change the components’ label of those devices that use a stock DTH or driver through the ST app would be a feature request.
- This name cannot be changed through the API but devices that use a profile in “development” status can be edited to set a new label (profiles endpoint).
- In Edge drivers, when we install the device, its profile is published, so it cannot be modified through the
I will create the feature request for this change.
Sharing my experience with groovy vs edge on this context. In groovy one could have a multi component device (just like edge) and the same problem existed there also. Only the DTH could assign the name to the component and that’s how it would show up. However in groovy there an option where the multi component devices could be represented as wholly separate devices, so a 4 button device could be displayed as 4 separate devices when the DTH created the device and then the user could rename each device separately.
I’m still working through the EDGE drivers but I don’t think that option for creating new devices is available to zigbee and zwave devices (it’s available to LAN devices).
Exactly…this is fantastic
that’s exactly what @w35l3y old me
surely this is a big problem that many users are experiencing. We have a community here in Brazil and telegram groups that are all facing this problem
@RBoy described very well what it was like and what it is like with the drivers
Ok, I already found the report I previously made about that so, I’ll talk to the team to get their feedback.
We appreciate you around here!
You summed it up very well.
Separate ZIGBEE child devices would solve 3 problems in one… individual commands (we wouldn’t need to access detail page of main device), individual custom names and recognition by other integrations (Alexa and Home Assistant as well)
I developed a workaround as proof of concept using LAN child devices.
As is often the case, I take a slightly different view. I find components to be a far more elegant solution.
The problem isn’t the lack of child devices, it is the failure of the mobile apps to better expose components in the UI, and the failure of the Google and Alexa integrations to do anything at all with components.
I really like to have individual control over each child device.
All my switches have 3 buttons, sometimes I only need 1 for the room and I use the others to control curtain or air freshener, for example. And I just hide these buttons because I don’t intend to use them by the app ever.
just to illustrate the big problem with not being able to rename. See that it is impossible to use devices with edge driver in smart lighting. In my print I have several devices with 2 and 3 gang and they are listed like this in smart lighting and there is no way to know which one it is.
To be fair, since SmartLighting is part of the old architecture and will be going away when The transition to the new architecture is complete, I don’t really think there’s a requirement that edge Drivers (which are part of the new architecture) work with SmartLighting.
However, they do need to be able to work with third-party voice assistants and with routines in the new architecture.
Do you see the same issue if you try to create a routine in the app? or add the component to a scene?
this is the main problem
routine and scene works well.