I’ve built a small Hubitat application to help me integrate Inovelli Red switches into my home automation.
There is a bit of functionality I am building where I need to get a parameter value for a specific Inovelli switch in my application.
Based on reading the driver code for my switch I call setParameter() with one argument/parameter, and it will return what I understand is essentially a reference to an async task.
I think I need to wrap the return in a closure to pull out the value, but I’m simply not seeing it work.
Here is a small sample
def loadInovelliConfigurationParameters() {
log.info "Loading Inovelli Switch Configuration Parameters"
if(inovelliSwitch) {
log.info "Switch was set"
inovelliSwitch.setParameter(52) { result ->
log.info "The result is ${result} or ${result?.value}"
state.parameter052 = result.value
}
} else {
log.info "Switch was NOT set"
}
}
When this executes the “Switch was set” log message is written, but the log message for the result never shows up.
I suspect I have misunderstood something important about getting parameters. I’m not new to software development, but am new to the execution model within Hubitat and Groovy.
Have you tried
state.parameter052 = inovelliSwitch.getParameter(52)
Edit: oh, looks like they declare setCommand as a command but not getCommand. Does state.parameter052 = inovelliSwitch.setParameter(52) not work without the closure? I’m not sure you really need the closure….
I have tried direct assignment, such as
def result
result = inovelliSwitch.setParameter(52)
That returns a number (java.lang.Long type) that increments by one and grows larger with each refresh of the page. I assume that number represents a reference to something that I figure is a handle to an async task or some other internal object that supports async execution. The setParameter function/method within the driver returns a collection of commands, based on my reading of it.
You are correct that “getParameter()” is not exposed. Runtime failures happen when trying to call it. But that’s not the hangup as it also returns a collection of commands. So same problem.
I am not sure I need the closure either. But having it is consistent with the Hubitat documentation that guides developers to never create synchronous code, especially when dealing with z-wave/zigbee/thread communication. The Hubitat documentation states doing so could lock up the main thread of the Hubitat and recommended capturing values in a closure, storing them in the state variable for the app and then using them later from state.
I am not in love with the timing / race conditions that creates for driving the pages in my app, but at this point I’d be happy to just be able to pull out the correct parameter values!