@kevin First the disclaimer - I am very much a groovy newbie!
I think you are saying there is a method to get a return value from parse()? Is there any documentation on how I call this method?
Sorry I should explain better…
Within the parse method you get the value returned via Telnet. . Then you insert within parse a method call to another method say dataReturned (value) passing the value as a parameter. Now you create your method dataReturned(value) and within that method you will have access to the value to do with as you wish. It isn’t going via a state variable.
You could also handle this entirely within the parse method, and in my MQTT app I do some validation within parse before deciding to call a subsequent method.
parse (String value) {
If (value *is as expected*) {
dataReturned(value)
else
……
}
}
dataReturned (String value) {
Your code here .. can use variable `value` as you wish
}
This creates a method call to dataReturned (your created method) in which value is available to handle further as you wish.
Ah, I get it! Will try that later and report back.
@kevin Not sure how I implement this let me explain. The thermostat capability dictates I must have a method "setCoolingSetpoint(temperature)" where temperature is a number. This method sends the command via telenet to the thermostat and I want it to wait for the reply from parse() before deciding whether to resend the command or terminate.
If I call this method from parse() won't it be a new instance of setCoolingSetpoint rather than the instance that is waiting for a reply? Similarly if I create a dummy method (as per your code snippet) won't that run in the same thread as parse() and so I still need to work out how to get the return value back to the setCoolingSetpoint that is waiting for a reply?
Sorry I missed the intention that setCoolingSetpoint was being implemented synchronously and would therefore await, and require a response. tomw clearly identified that a few posts back.
I assume that one such response could be a timeout and another failure. You imply that timeout would be handled by an automatic retry mechanism. Would people know to expect such returned values when calling setCoolingSetpoint(temperature) and I assume similarly some additional methods you might implement?
I’m my usage everything is asynchronous and I have opted to throw returned data as events using sendEvent so I have no synchronous wait for response type issues.
First I should say I already have a driver running for this device on another system (not in groovy though!) and the majority of failures can be remedied with a commend resend. If after, three retries, I still get a failed response I'll write to the log or see if I can trigger the Notifications app.
I have been thinking about using attributes/events - that will be my task for tomorrow!
Hopefully my last question on this topic!
I will try using an attribute to pass the thermostat response status from the callback (at the moment that is parse) to the command sending method. It looks like I should use sendEvent() from the Driver Object to write the attribute value and currentValue() from the Device Object (with the skipCache option true) to read the attribute value.
Correct?
Problem solved!
Using attributes to carry messages across processes works well.
@tomw: I did try specific callbacks for each command. It would have made the code cleaner but the telnet protocol will pass everything back to parse, custom calbacks are ignored. See hubAction callback not working .
1 Like
