COLOR_MAP for multiple Commands

[markus]

As stated here:

Requiring Fields for commands

This was intended for documentation but slipped... The command definition in drivers allows now for an optional 3 map to be passed into commands Original code: command "testEnum", ["Enum"] resulted in this: [image] with 2.0 we added support for defining a few things: command "testEnum", [[name:"Testing Enum", type: "ENUM", description: "Pick an option", constraints: ["one","two","three"] ] ] will result in this: [image] What has happened is we have expanded the 2nd parameter to command…

COLOR_MAP can only be used in one command, and a quick test shows this to be true.

The color picker library used can support multiple instances on the same page, so with only "minor" changes we could have support for multiple instances.

I have a use-case for an addressable strip, where SetColor already is using Color Map, but it would be great to use it for color selection also for the individual pixel SetColor command, lets call it SetPixelColor. As it is now I use STRING and the color in RGB HEX for SetPixelColor. Not easy to use.

It would be great if we could get this feature, it would make color selection much easier and the command fields would be clearly color fields when used form other parts of HE.

[markus]

I guess it's only I who see the need for this then?

[adamkempenich]

Can you elaborate on this a bit more? I’m not sure I follow.

[markus]

For driver commands you can declare fields with input, such as a string, a number or even an enum, you can also use color_map, but only for one command per driver. Color_map is the field used by the SetColor command. Any other field type can of course be used any number of times, but color map is limited to one command due to how the javascript it is using is called. Not sure if this explains it better?

[adamkempenich]

I follow you, now.

I wonder if you could use JS to invoke the color picker for a second command. You can inject it (or even CSS) by using the command’s label (or description) field and adding a script. You’d just be able to use a map as your method’s parameter, and pass the generated map through.

Hacky, but it’d probably work. You could probably even inject a different color picker. I’ve played with this idea..

[markus]

Yes, I’ve done this and then removed it, it is hacky, but doable. Just would prefer a standard way to use a standard field type more than once

[markus]

@adamkempenich

You can inject it (or even CSS)

Speaking of CSS, I actually did build a little collection of methods to inject CSS to hide commands, state variables, Data fields as well as preferences and Current States. All dynamically and based on preferences and what is needed by the driver at the moment. This way I have a command to say basically hideCurrentState("switch") and it's gone...

[adamkempenich]

What driver are you building, exactly?

[markus]

Where I have found the most use of this is in a child driver for handling RGB + CT + Dimmers + Adressable LEDs and everything else light related while not needing multiple different child drivers. Also nice to have it for, is hiding the "Delete All Children" button in a parent driver so that it is not clicked too easily... To get it, a preference has to be first set. I use these CSS methods a bit here and there in my new Tasmota drivers to be able to run all types of devices using only one Parent driver and as few as possible of child drivers. I could probably have even fewer child drivers if I really wanted to, using this. All without having a crazily hard to navigate driver and still not having to sacrifice functionality.