I have a Meross double outlet, I have 3 devices in Alexa and it works very well for me (1 general and 1 per outlet)
Agreed, in the UI, the device feature category alone may make sense (we are often contextualized to a room, therefore to a specific list of devices). Ex. « Temperature » to display « the » feature of a device located in a room. If there were 2, nothing prevents updating the label!
However, in a scene, you need to be able to choose the right feature and therefore add the device and the room is very useful⊠This was my initial request
PS: This does not call into question the need to have a split of a device or another way (device_feature.location?)
Got it, thanks @VonOx and @Romuald_Pochet, so thatâs indeed the solution: split these devices into multiple devices in Gladys 
This way, it actually allows:
- To properly differentiate these devices in Gladys
- To place each outlet in a different room (not possible if you donât split them)
- To manage compatibility with Google Home / Alexa, otherwise it wonât work for these devices
It may be possible to include Xiaomi in the loop as I am having issues with my double switches where I cannot separate the left one for the living room and the right one for the dining room, and the same goes for the kitchen.
Yes!
We also requested other devices such as these multi-socket power strips:
Example: Zigbee2mqtt: Add device HG06338 · Issue #1333 · GladysAssistant/Gladys · GitHub
Hello,
Iâm working on integrating a thermostatic valve at my place, and I have this:
Each « button » corresponds to a binary type feature on my valve.
Iâm not sure that the « split » youâre talking about corresponds to my problem.
How can I make the display change?
If I change the type, I will have to tinker with different types for each feature, which is not ideal. Moreover, I would have to modify the Box in the front end to authorize each device, which is tedious.
At my place, I have the same issue with a head from Moes.
The reason is simple: some types are not yet supported by Gladys. But it will come, we need to think about it in advance to manage the heating and then develop all that.
Actually, I would add the different types for my Enocean integration, but my valve has its own protocol, so I would have types that would probably only apply to this type of valve, knowing that in the end, it remains a Binary type.
Example:
So I find that keeping a basic binary type is sufficient, but itâs the display on the front end that is problematic for me.
For sensor type features, it works:
But not for non-sensor features (readOnly: false):
Indeed, the heating part is not yet managed in Gladys core.
This is a development that remains to be done
Donât hesitate to make a feature proposal, itâs the biggest job to be done, so that development can happen quickly afterwards.
A bit like thinking about the plans for your house before construction, when you know where youâre going, it all happens by itself.
I had made a first sketch that I need to update with my experience of my current connected devices, donât hesitate to make a new one or to complete it:
Another example of functional specification (by @pierre-gilles):
Iâm adding my two cents here, I donât know if this is related to the same issue.. I have a 4-channel Zigbee switch in my garden. And it displays like this despite the fact that I gave nice names to the features:
Actually, the idea for these devices, which are a bit like power strips, would be to make the integration split the device into several devices, and this for several interests:
- Be able to properly name each device
- Be able to place each device in a different room (since a relay can control devices in multiple rooms)
- That these devices are managed by voice assistants (Google Home, Alexa), which only manage one feature of the same type per device
This is how most other home automation systems work.
This is a development in the Zigbee2mqtt integration
I understand perfectly!
I will wait then as I am unfortunately not a developer.
Iâm reviving the topic a bit, it doesnât apply everywhere 
Just to add a token in the device, z2m the lixee tic, I donât see why weâd create multiple devices.
And to show how unusable it is
Who is who? Itâs a lottery
Edit: Editing the feature names is almost impossible, and using them in scenes is a nightmare
Workaround for the dashboard and the scenes: pick one at random and edit the selectors in the db
Indeed, the Lixee TIC is a bit extreme (lots of features).
In the case of the Lixee TIC, for me the solution is simply to better classify each feature, since I assume each feature has a purpose and shows a different value from its neighbor?
Unlike power strips, which really have 5 features that do exactly the same thing, Iâm sure that in the case of the Lixee itâs a matter of X truly different features, right?
Iâm bumping this thread to see if a kind soul has looked into this development?
It seems that quite a few recent posts on the forum are converging on this issue.