Specifying an alternate Callback for a HubAction gives unexpected result

🚧 Developers Coding Questions
1

If I use the code snippet below the hub response goes to parse() and I can use parseLanMessage and everything works as expected.

image
image810×258 16.7 KB

If I uncomment those two lines the hub response goes to myfunction() but the response is different. It is something like "hubitat.device.HubResponse@94ee77"

image
image833×266 16.4 KB

and the code blows up on parseLanMessage() because its invalid for the returned data.

Documentation on this is scarce and I cannot find a format where the LanMessage is passed to the alternate callback function. Do I have to specify an option to force the LAN data to be returned to the specified callback function or am I supposed to use the "@94ee77" in some way to retrieve the data.

I could do it all within the parse function but being able to separate different response types into alternate callbacks sure makes the code more readable.

Any pointers appreciated.

2

Closest signature for HubAction I see for what you are trying is

HubAction(Map params, String dni, Map options)

which means you are sending a null for the dni

dni - The device network Id to use when sending the message.

3

Thanks for the quick response. Unfortunately that does not work. However, if I just pass the DNI as the second parameter, it does work

image
image820×290 20.2 KB

It doesn't solve my problem but it does suggest that the problem lies somewhere in the options map.

image
image906×375 29.4 KB

4

Probably a good reason, but why not use the httpGet or asynchttpGet methods?

5

I certainly would be willing to use httpGet if I had a good example of utilizing the callback method properly. But searching on "HubAction callback" produces a pretty thin list.

Is this something you have an example of that you would be willing to share?

6

LOL I have a whole lot of those:

void getPollData() {
...
        Map params = [
                uri    : "http://${location.hub.localIP}:8080",
                path   : "/hub/advanced/internalTempCelsius",
                headers: ["Cookie": cookie]
        ]
        if (debugEnable) log.debug params
        asynchttpGet("getTempHandler", params)

...
}

void getTempHandler(resp, data) {
    try {
        if(resp.getStatus() == 200 || resp.getStatus() == 207) {
            Double tempWork = new Double(resp.data.toString())
            if(tempWork > 0) {
                if(debugEnable) log.debug tempWork
                if (location.temperatureScale == "F")
                    updateAttr("temperature",celsiusToFahrenheit(tempWork),"°F")
                else
                    updateAttr("temperature",tempWork,"°C")

                updateAttr("temperatureF",celsiusToFahrenheit(tempWork)+ " °F")
                updateAttr("temperatureC",tempWork+ " °C")
            }
        }
    } catch(ignored) {
        def respStatus = resp.getStatus()
        if (!warnSuppress) log.warn "getTemp httpResp = $respStatus but returned invalid data, will retry next cycle"
    } 
}
7

After trying out your example I can see that the response I receive when I correctly specify an alternate callback is structured similarly to the response I receive when using your asynchttp method.

So it would seem to me that an alternate callback is forced into using a different type of response and thus parseLanMessage is no longer valid when you use an alternate callback.

For simplicity I will probably just stick with running everything through parse() and then branching off from there. Thanks again for your help.

8

There's an AsyncResponse object described here. Maybe it is relevant: Async HTTP calls