Does the Hubitat implementation accommodate device driver commands with data type "enum". It would allow the device page to have a drop down of the enumerated values. For example, I want to create a color select command that allows the selection of 15 colors and then sets the bulb to the selected color value. Would work well until we get a color wheel capability.
PS - It can be done in preferences, but that not the best way?
Thanks; however, the referenced code still uses the "myOptions" within the preferences section. I need a command that has an enumeration as an input. (it would look like the preference selection; however, it would be a command and would not require a "update".
That's a dynamic page construct, which we don't support in drivers.
However, you could do the following.
Your command writes the enum list to a state var in the driver.
Then set the enum input values to another method that reads these values from state. Enum inputs in drivers are not dynamic, but they are generated on page load and refresh.
Thanks, Mike. Thought about that; however, I want to use it for the user to select among 15 colors (vice trying to remember hue and saturation values for a color). For now, doing it as a preference.
When I implement pushable buttons in the Dashboard, then I will color-code the button and have the hue/saturation sent to the set color command.
I'm confused, are you trying to implement some sort of custom command setColor by name? You can write methods to accept whatever parameters you want. I'm totally lost on the requirement...
Normally one would build a color name to hsl lookup in the app, then send hsl to the device.
Where is this user selecting this color name in the driver?, or in the app...
The selectColor is targeted for the TP-Link Color Bulb drivers. In the bulbs themselves, color is set using the hue and saturation parameters. In a previous system, this came across as a part of a map outpur from a system-defined colorcolor wheel page. We do not have that on Hubitat (yet?) and it is probably not extremely important.
However, the device edit page has the set hue and set saturation command - totally useless unless the person is a color wheel genius with perfect memory. What I am trying to do is create an interface where the user can select the color by name (sort of like on Amazon Alexa smart house page). Then the system sets the color.
This will all lead into the dashboards. My plan is to link to the edit page to change parameters like color temperature and color (bulbs) rather than making the dashboards unnecessarily complex. Color is the only command for the (color) bulbs that I see a problem.
PS - currently, I have test code doing selected color as a preference (since it has drop-down menus). Has problems if people do an update and the color mode has been exited from regular commands.
Capabilities / custom commands in the color bulb are
capability switch
capability switch level
capability refresh
command toggleBulbMode (was setModeNormal and setModeCircadian)
capability color control (commands = setColor, setHue, setSaturation)
May add command selectColor
since custom commands are not supported on the dashboard ... the way i deal with this in my device driver for rooms is by mapping the custom commands to a set of buttons in the device. then creating a tile per button and each tile push can do whatever you like it to do.
the only usability challenge on this is when specifying buttons for tiles they just show as button 1 instead of the a custom name. @patrick had mentioned that they were going to support custom labels with buttons on the dashboard but i have not seen support for it yet. hoping that comes along soon
Use dashboard for basic on/off command and maybe capability "music player". For devices with additional (custom) commands, link to the Devices edit page (it will pop up as a separate window) and then select the function. When convenient, create a separate "button" page for the device. Each "button" page would have up to 20 buttons.
The answer to @djgutheinz's question seems to be: YES, it is possible to define a custom command in such a way that the command will be represented in the "Commands" section of the device page (not to be confused with the dashboard, or the "Preferences" section of the device page) as a dropdown list with pre-defined values. It seems that the elements of the second argument (which is a list) passed to command() can be not only strings, but also maps. The following command definition demonstrates this fact, and will produce the desired behavior:
command(
"setBulbColor",
[
[
"name":"bulb color*",
"description":"Choose one of several predefined colors (this text appears in the tooltip when you hover over the dropdown control on the device page.).",
"type":"ENUM",
"constraints":["red","blue","chartreuse","mauve","topaz", "emerald green"]
]
]
);
Here is the resulting control that appears on the device page:
I made this discovery by inspecting the "parameters" property of the elements of the list returned by device.getSupportedCommands(), on a device that had the "Thermostat" capability. The standard setThermostatMode() command shows up in the "Commands" section of the device page as a dropdown menu. The "parameters" property of the corresponding item in the list returned by device.getSupportedCommands() was a map of the form described above. I am not sure what the purpose of the trailing asterisk in the 'name' property is.
Only from the edit device page....not from the dashboard. I think this topic was covered pretty well when it was brought up over a year and a half ago.