Device Preferences - various issues

🚧 Developers Broken-code
1

Trying to port over the driver for the Fibaro Dimmer 2, but struggling a bit with the preferences.

  1. default values don’t populate for type: “number”

input type: “number”,
name: “configNightmodeLevel”,
title: “Nightmode Level: The dimmer will always switch on at this level when nightmode is enabled. (Default=10”,
range: “1…100”,
defaultValue: “10”,
required: true

  1. for type: “enum” I can’t use options: [value:description]

Example:

input (
name: “configLoggingLevelDevice”,
title: “Device Logging Level: Messages with this level and higher will be logged to the logMessage attribute.”,
type: “enum”,
options: [
“0” : “None”,
“1” : “Error”,
“2” : “Warning”
],
defaultValue: “2”,
required: true
)

Instead I have to loose the descriptions and only enter values:

input (
name: “configLoggingLevelDevice”,
title: “Device Logging Level: Messages with this level and higher will be logged to the logMessage attribute.”,
type: “enum”,
options: [
“0”,
“1”,
“2”
],
defaultValue: “2”,
required: true
)

I know I could use descriptions instead of values, and convert the descriptions into values when using the preference elsewhere in the driver, but that’s a lot of work for 20 odd enum preferences… there must be a better way?

  1. I’d like to break the preferences into sections, the traditional ST DTH way is as follows:

section { // GENERAL:
input (
type: “paragraph”,
element: “paragraph”,
title: “GENERAL:”,
description: “General device handler settings.”
)
…
}

Type: “paragraph” doesent seem to exist and if I change it to anything else it forces an input box rather than just giving the section a title… an I missing something here?

Thanks in advance!

(P.s. sorry for poorly formatted code snippets, I’m on mobile)

2

Sorry… missed number 4

Number ranges are not respected, I can use range: "1..100", in the driver but can select any value when viewing the device, even negative values.

3

Enums need to be a list of maps currently, we have an issue logged for this already, same for default numeric values and ranges.
Do the enums like this [[0:text],[1:text]]
We don’t support a paragraph input element, first I’ve seen that.

2 Likes
4

Perfect... I’ll give that a go!

Here’s a working ST example:

I’ll overcome this by making it an enum with only one default option, stating, “ignore me” lol :joy:

5

Thanks, given I’ve never seen a paragraph input element in a driver before, not sure that will percolate to the top of my to Do list!

1 Like
6

A clean way of dividing preferences into sections, with a heading for each, would be neat… but I agree it’s definitely not going to be a priority for a long time, if ever.

Thanks.

1 Like
7

@mike.maxwell

Is there a way to force a new line in a preference title?

\n does not work as expected. Neither does \r or \n\r

    input name: "param30", type: "number", range: "0..3", defaultValue: "3", required: true,
        title: "Parameter No. 30 - General Alarm, set for relay no. 1.  " +
              "Available settings:\n" +
               "0 - DEACTIVATION - the device does not respond to alarm data frames\n" +
               "1 - ALARM RELAY ON - the device turns on after detecting an alarm,\n" +
               "2- ALARM RELAY OFF - the device turns off after detecting an alarm,\n" +
               "3 - ALARM FLASHING - the device periodically changes its status to the opposite, when it detects an alarm within 10 min.\n" +
               "Default value: 3."

returns:

image

8

Not currently, I might think about dumping the instructions for the parameter settings to live logging, that way they don’t clutter up your driver ui.
Additionally I would make the input an enum, easier for the user to use, and less chance of them entering an invalid value.

1 Like
9

Could you make them part of the selection instead? Create it as a drop-down menu and have setting + description there?

10

Input elements can’t store that much data.

11

Simplified details then?

input “param30”, “enum”, defaultValue “3” title: “Param 30 General Alarm”,
options:[[0:“Deactivated - no alarm”],
[1:“Alarm Relay On - active on alarm”],
[2:“Alarm Relay Off - disabled on alarm”],
[3:“Alarm Flashing - cycles on and off”]]

Something like that? It probably needs syntax checking, but just an idea.

12

Wouldn’t that require switching back and forth between tabs to change settings / read instructions?

Fully intend to do that for the basic values, I’m fixing up most of the preferences that way.... but the text is currently too long for enum dropdown so I still need the description above.

13

I intend to simplify into enums yes, but I would still want the full description above and some other param descriptions are much longer than the example I posted above.

14

I just open live logs in another browser instance.

15

Juat makes no sense to me… different tab or different browser instance, what’s the difference?

You’d sill be fragmenting the title from the setting?

And live logs is for logs? The device names don’t even show up until after an event so how would I view preference titles before an event, during initial setup?

16

Its your driver, you can do whatever you want with it, you asked, I gave you suggestions....

18

Actually, I misunderstood Mikes reccomendation… though he was talking about an architectural change where preferences are somehow shown in live logging tab (outside of the logs themselves), not a driver change where I just send info to the logs.

19

Issue with using logs is they give you the info after the change, not when deciding what to change.

I was just looking for a method to force a new line on the preference title, to present things better… can live without but would have been nice.

Think I’ll be saying ‘can live without’ a lot with this system lol

20

:smile: Yes indeed sir. With the benefits come the drawbacks. For me so far the benefits are winning. We can always add these to the feature request list. Just wish there was a voting mechanism so the Hubitat team knew what the community views as priority.

2 Likes
21

Personally, I’d rather hear the suggestions and pass them on to our UI team. The goal isn’t to make you live without anything, the goal is to prioritize what everyone needs and roll out fixes, improvements and additions as fast as we can.

Remember, Rome wasn’t built in a day.

1 Like