multiple: true on enum Renders as Single Dropdown in Driver Preferences
Summary
While building a learning driver in Hubitat, I noticed that using multiple: true on an enum input doesn't work as expected — it renders as a single-select dropdown, not a multi-select checkbox list. I'm trying to figure out if this is:
- A bug in Hubitat's firmware,
- An unsupported use of
multiple: truein drivers (even though it's documented for apps), - A common gotcha for beginners,
- Or if there’s a known workaround or best practice to achieve multi-select behavior.
Test Scenario
I created a minimal driver using enum with multiple: true. I expected a set of checkboxes, but only got a single dropdown. Even if I choose multiple default values (like ["A", "B"]), only one value is saved and displayed in logs.
Expected Behavior
According to Hubitat’s documentation:
"multiple" – Only available when the type is enum. Specifies that multiple values can be selected from the dropdown.
Source: Driver Capabilities → Preferences
And from the App documentation:
For capability and enum inputs, an optional parameter of
multiple: trueis allowed, such that a List is returned instead of a single element.
Source: App Overview
So I expected checkboxes for multiple selection (e.g., [✓] A, [✓] B), with values returned as a List like ["A", "B"].
Observed Behavior
-
The
enuminput displays as a single-select dropdown. -
Only one option can be chosen.
-
The returned value is a String, not a List.
-
Logs confirm that only a single value is passed:
dev:7332025-07-19 04:52:42.909 PMinfo Test Multi-Select preferences updated: C
This breaks logic that expects a List (e.g., using .contains() or iteration).
Environment
- Hardware Version: C-7
- Hubitat Firmware: 2.4.2.125 (likely July 2025 release)
- Tested Browsers: Firefox and Chrome (behavior is the same)
- Driver Context: Simple learning driver
Test Driver Code
/**
* Test Multi-Select Driver
* Version 0.1.0
*/
metadata {
definition (name: "Test Multi-Select", namespace: "test", author: "xAI") {
capability "Actuator"
}
preferences {
input name: "testMulti", type: "enum", title: "Test Multi-Select",
multiple: true, options: ["A", "B", "C"], defaultValue: ["A", "B"],
description: "Expected to allow selecting multiple options. Currently renders as a single dropdown."
}
}
def installed() {
log.info "Test Multi-Select driver installed"
}
def updated() {
log.info "Test Multi-Select preferences updated: ${settings.testMulti}"
}
def uninstalled() {
log.info "Test Multi-Select driver uninstalled"
}
Steps to Reproduce
- Add the above code as a new driver in Drivers Code.
- Create a device using this driver (Devices > + Add Device).
- Go to the device’s Preferences section.
- Try selecting multiple options from the Test Multi-Select input.
- Save and check the Logs.
Screenshot
Questions for the Community
- Has anyone else seen this behavior when using
multiple: truein drivers? - Is this officially unsupported, or a firmware bug?
- Is this only meant to work in Apps, not Drivers?
- Is there a workaround that won’t clutter the UI (e.g., replacing with a dozen
boolinputs)? - Should I open a support ticket, and if so, what should I include?
Additional Context
I’m still learning Groovy and experimenting with driver development. I’d like to avoid cluttering the Preferences page with lots of bool switches, especially when I need the user to select from a list of 10+ options.
Any advice or clarification would be much appreciated as I learn the ropes.
Thanks in advance!
Edit: AI-Assisted Syntax Improvements
I should also mention that I’ve been iterating on this Groovy driver with the help of a few AI tools. I shared my earlier code attempts with them, and they helped me refine the general syntax, identify structural improvements, and enhance readability. The final version included in this post reflects those AI-assisted improvements and is the one I’ve been testing. If something looks different from typical examples, that’s why — but I’ve done my best to keep it consistent with Hubitat driver development practices.
) is the old docs that have not been updated in years. There was a problem in the current docs, too, but that has been corrected.
