The following code results in response2 = null. The Get operates properly and the result is valid JSON.
Is asynchttpGet unique and it can’t return a value? I tested with a simple string and it wasn’t returned either.
def asyncHTTPHandler(response, data){
return response.json}
def f1{
def response2 = asynchttpGet("asyncHTTPHandler", params)
log.debug "response2: ${response2}"}
As you'll see in the documentation, the async HTTP methods do not return any values (i.e., they are void). When the actual HTTP call is done, your handler method will run, and that is where you should deal with the data that is actually fetched or sort of "returned" by the call. You'll find that in the reponse object, either response.data for the raw string or response.json or response.xml if it's parseable JSON or XML (might depend on the return type too?) and you want to skip right to a Groovy object for that.
You'll also likely want to provide a default value of null for the data parameter in that handler method signature (not to be confused with any of the above, just extra data you can provide when you call the async HTTP method but aren't in your example).
Thanks. I was attempting to write only one callback.
This is incorrect? Hub froze - #55 by csteele
No, they are both correct. What differences are you seeing? You can write as many callback methods as you want; each async call will specify exactly one callback method to run when the HTTP action is done.
Note that this (the async method) is different from the "synchronous" HTTP GET in the first example you linked to above. You do not need callback methods for those because they effectively hold your app or driver while they run. It is generally preferable to avoid these unless you have a specific reason to prefer them in a particular use case.
Referring to;
return parseJson(resp.data)
I have two requests going out. I can copy the callback code for each request and make the required changes. The most important issue is passing the result back to the calling function. I can have the callbacks perform processing, but eventually data will need to go the calling function.
As used in a driver:
@Field static def var1="abc"
def function() { var1="xyz")
The value of the variable var1 is the same for every device that uses the driver, correct? (var1 is initialized to abc but then set to xyz.)
Whereas:
@Field def var1="abc"
def function() { var1="xyz")
Each device will run a “fresh” copy of the driver, and thereof has its own set of variables every time it runs, correct? (var1 is initialized to abc, then set to xyz, then initialized to abc in the next iteration.)
Lastly, the value of var1 in either implementation above is xyz only during the execution of the function/method in which it was changed, and no other code until the driver is exited when the value will be either abc or xyz depending on whether static declared, correct?
I'm honestly not sure about non-static field variables. I don't use them, likely because I never found them useful (probably nothing a local variable couldn't do?). Also, if you just need basic persistence between executions, state is typically a better choice for a starting point (except in the unusual case where you want to share data between different devices using the same driver, generally something you have to work to avoid; or maybe are dealing with large data that isn't suitable for state and can easily be re-generated, like a cache). I suppose whatever behavior you found, if you tested, is probably what you can expect.
But it's a bit of an unusual thing to be doing, in any case.
I was asking if my assertions above are accurate, not about the implementation of @Field variables or their use versus state. From testing, my assertions are correct, but maybe I’m missing something.
Wasn't that part of the assertion?
In any case, the behavior of these is not documented and so is not something I would count on. But, again:
For static field variables, however, you are correct, which I guess I never explicitly confirmed above.
If you have a specific use case in mind, that would make for a better question that someone might be able to provide ideas for. Good luck!
Download the Hubitat app
