I have two specific use cases.
In both cases, it would be an action with a dropdown choice. (And for one, the best would be a dynamic choice based on what the device allows. (Here the color effect of an LED strip, not just the color))
For Zoneminder, this was what I was talking about, activating a specific mode of a camera, I can take a choice of type SWITCH, but it’s not intuitive to say 1 = normal, 2 = surveillance, 3 = recording…etc
Ok, in both cases I think we can create a custom control with the translations and so on
For the ZoneMinder switch, it will be highly custom (specific to ZoneMinder), for the LED strip effect, we’ll see how much similarity there is with other LED strip brands to factorize.
In any case, if we realize that factoring degrades the user experience, we’ll go custom 
For the LED strip, it’s mainly to manage Hyperion (GitHub - hyperion-project/hyperion.ng: The successor to Hyperion aka Hyperion Next Generation · GitHub)
Well, the link is the latest version that I haven’t tested.
On the old version, well you can pass it either a color or an effect, both via a string.. I’m not sure how to handle it.
For the custom box, would you have an example of how I declare that in my integration?
For the colors, you can manage them with the color control that already exists:
You just need to handle a small routine to convert the color format between Hyperion and Gladys (see how other services do it, we already have a few conversion functions).
It’s not in your integration, it’s in the « device-in-rooms » box in the frontend, you can code it here:
After that, before you start, if you could write a small spec here so we can discuss it, that would be better The idea is really to see if it’s not a behavior that we can factor with other integrations, and if it’s not factorizable, I think we can still discuss it so that you start in the right direction!
For color conversion, I will check, Hyperion, currently in its old version, for example, asks for red or blue.
For the feature, it’s the same, the current need, if I take zoneminder, is that I will pass this to the API:
Monitor[Function]=Modect
What interests me here is Modect
So it’s this string that I need. Previously, in V3, I did it differently because I was not using the API, I had a custom thing just for me that called a script.. But the end result was the same, on the Gladys side, I sent an Integer (1, 2, 3..) and I do the mapping.
But on the UI side, it’s bad, you have to know that 1=Modect, 2=Monitor..
So I would like to have either a dropdown menu with the String that fits, or something else.
I could also, if necessary, have N features for each possible mode, each being a Binary and when one is On, all the others are switched to Off.
This does not require development other than in the integration.
Don’t hesitate to check the logic on the home assistant side, there is an integration with auto detection
I think in this case, this is the best option With the correct translations it works in French and English
Well actually it’s great the color picker, I thought I would pass to my Hyperion instance a color type red or blue but not at all, I pass RGB like Hue, so it works directly.
I only have the Effects to manage.
So you suggest developing a front-end box that manages a dropdown menu with options from the integration that manages this device, is that the idea?
In this case, as the value remains an Integer, the returned option should be an object of the type:
{
name: <string: Value name>,
id: <int:value>
}
So I would have in mind an API on the integration that returns the list to be proposed on the front-end..
On the back-end, the integration would then manage the mapping between the value received at setValue and the name to send to the client behind.
Am I on the right track?
Not exactly a box, just a component of the « devices-in-room » box, but yes that’s the idea, it will just be a simple component with a select box that sends the correct integer values.
If you need help we can do it together, don’t hesitate
No need, it’s static, it’s just a front end component and translations in the front end trads.
Exactly!
Hello,
I’m picking up a bit on the topic of the box with a select.
I thought that an easy solution would be to create a device_feature for each possible option of the mode (here, the mode of the camera).
But in the case of the integration I’m writing to manage my Hyperion installation, I have about 15 modes for the strip behind my TV, which would result in about 15 device features, all in binary.. well, I don’t find that elegant.
So, the option to modify the devices-in-room component seems best to me. I was looking at the code, and in particular:
const ROW_TYPE_BY_FEATURE_TYPE = {
[DEVICE_FEATURE_TYPES.LIGHT.BINARY]: BinaryDeviceFeature,
[DEVICE_FEATURE_TYPES.LIGHT.COLOR]: ColorDeviceFeature,
[DEVICE_FEATURE_TYPES.SWITCH.DIMMER]: MultiLevelDeviceFeature,
[DEVICE_FEATURE_TYPES.LIGHT.BRIGHTNESS]: MultiLevelDeviceFeature,
[DEVICE_FEATURE_TYPES.LIGHT.TEMPERATURE]: LightTemperatureDeviceFeature
};
But where I don’t know how to handle it, is for the options of the SELECT that I want to create. You indicate to put static integer values, okay, but we agree that the values need to be differentiated according to the service? So, a detection of the service through the selector of the device_feature for example?
That seems cleaner to me too!
Well in your case I would recommend creating a specific category/type pair for this select, and differentiating based on that.