Device Preferences - various issues

OR:
create a custom command "prefHelp"
then:

def prefHelp(){
        log.info "--this is what setting two is all about..."
        log.trace "-setting 2:"
        log.info "--this is what setting one is all about..."
        log.trace "-setting 1:"
        log.warn "Preference help"
}

which would result in:

1 Like

That's certainly a possible solution....

I've actually managed to squeeze a lot more into the enum options than I though't would fit, looks ok now:

On the topic of custom commands though, any idea what is creating these:

I'm assuming it's one of my capabilities, but without documentation I have no idea what capabilities are available on Hubitat, and which ones I should remove / tweak when porting from ST??

capability "Switch"
capability "Relay Switch"
capability "Polling"
capability "Configuration"
capability "Refresh"
capability "Zw Multichannel"

My guess is the zwave? I have custom drivers with all the other capability and don’t recognize those commands.

1 Like

yeah, commenting out Zw Multichannel indeed removed the two unknown command buttons, and the driver continues working just fine.

But Zw Multichannel is obviously being recognised as a capability, and gives unknown data entry options, so what is it’s purpose?

In ST this driver does not work without the Zw Multichannel capability quoted.

I checked the documentation in smartthings. That’s the go-to for commands and capabilities, until something more thorough is created locally, but there’s nothing listed. ^.^ So I have no idea.

You did a great job fitting all those settings into enum fields, btw. :slight_smile:

1 Like

haha... you should see the Dimmer 2 driver I'm working on lol:



As long as you’re having fun. I’m hoping to figure out how to parse hex strings to enable local control of my thermostats at some point… I’m currently using a web login for control because that’s the driver that they supplied and I just ported the base code and added a few features.

1 Like

Whoa. I’ve struggled a bit with ST adapting device handler preferences, but this is on a scale I can’t imagine wanting to deal with.

Is there any way to split off the preferences for a device handler into an App so that it could be presented in a… more “digestible” format?

1 Like

Nice… built in manual :slight_smile:

1 Like

It's certainly possible, but I'd rather the driver was able to stand-alone, without needing a separate app.

I am however including the following custom command in all my drivers:

def updateSingleparam(paramNum, paramValue) {
	log.debug "Updating single Parameter (paramNum: $paramNum, paramValue: $paramValue)"
    	zwave.configurationV1.configurationSet(parameterNumber: paramNum, ConfigurationValue: paramValue)
}

This can be called by apps like Rule Machine / webCoRE to enable remote alteration of specific parameter values.

I haven't found a way to make values sent appear as new values displayed in the driver preference section though... it only sends to the device itself. So if I remotely change a value using an app, it's not reflected on the device page. (this is not possible on ST either btw).

Can you force a device refresh that will pull a configuration report that will update the parameter values? I'm speaking completely in theory here because I don't really know what's possible with most devices.

You can query the device for current parameter values, and pass those values to the logs… but I have no idea how to pass the values so they display in the correct preference ‘tile’… I’d be very surprised if it were possible but also very happy if proven wrong!

If you are storing the value in current state it you should be able to do a sendEvent to update the value…unless I’m completely misunderstanding what you are trying to do…which is likely :slight_smile:

I just re-read your previous posts and realized you are trying to update the values that show in the preference input boxes and not the state value. Ignore my previous bumblings.

1 Like

Correct… but to be honest I’m not trying… Was never possible with ST and I doubt it’s possible with HE.

Not something that really bothers me either… I just put it out there in case someone throws a solution at me lol

Well I threw something at you. Lucky for you it missed. :wink:

1 Like

Manually updating values of ST device handler preference settings is extremely limited. Only device.updateSetting("settingName", value) works in ST, and only with certain value types, and only if in the same execution of code after a user has just saved settings.

I think that call might have worked in HE in my early testing when I was porting the Xiaomi Zigbee device drivers… Would have to play with it again to be sure.

1 Like

device.updateSetting("prefName",[type:"enum", value:"newValue"])

I thought st had these, or was going to implement these...

1 Like

Send event actually creates an event that is submitted to the event handler as well as written and saved in the events db, state is a much better choice for this type of thing.

Perfect... I'll give that a try... Thank You!! :smile:

AFIK ST never implemented this, or if they did they never told us / didn't update the docs