hubAction - where's the content?

General Discussion
1

I’m trying to get back a response from a hubAction call. The docs imply this should come in the parameter to parse that is called after hubAction is returned from the device hander’s event.

But I’m getting just a bit of call data…
‘index:0F, mac:0073E023A13A, ip:C0A80114, port:040B, requestId:c1f09565-94e4-4b55-9f88-a99ecab297ee’

I can see on the sniffer that the correct data is being returned, and the code is correctly waiting for it. It’s just not seeming to give me access to the headers or content.

(Ideally I’d be using the httpGet() command, but that apparently can’t send to addresses on the LAN.)

What am I overlooking?

Thanks

2

is it a parseable format like html, json or xml? If not, you can’t do anything with the response.

3

It’s a standard HTTP response, part text, part binary. Works wonderfully in any browser, or with curl (which parses the headers and can redirect the content to a file.) Just doesn’t seem to be visible, in any form, to hubAction’s parse data.

From the link I provided above, they claim it would include:
When you make a request to your device using HubAction, any response will be passed to your device-handler’s parse method, just like other device messages.

def msg = parseLanMessage(description)
def headersAsString = msg.header // => headers as a string
def headerMap = msg.headers // => headers as a Map
def body = msg.body // => request body as a string
…

But as you can see, I’m not getting any of that, just the requestId. parseLanMessage() is merely parsing the string into a map. How do I resolve the requestID to the actual response, or retrieve the correct response in parse()?

4

But what is the response content type? Is it html, json, xml, txt? If it doesn’t have a response content type or not one of those it won’t parse.

5

Interesting. Are you telling me that the headers won’t come across if the content-type is, for example, image/jpeg instead of application/json? How do the LAN cameras do it?

In this case, it’s a file with proper HTTP headers, but the body is all binary content.

6

Yes. They use an undocumented putins3 option. Using AWS.

You can’t parse image jpeg locally and larger responses will be unparsable. Limits of local processing going back to hub v1

7

Thank you. So what do we know about the s3 option? A quick grep suggests
hubAction.options = [outputMsgToS3:true];

But there must be some more magic there, because trying that still gives me the same parse headers. Would that grab a referenced file?

8

https://github.com/pstuart/smartthings-ps/blob/master/devicetypes/generic_camera.groovy

Check my generic camera devicetype.

9

It’s not working here. Using your device type, configured up, I get:
1cd2ae5f-7a5e-442b-a292-afd9a7827cd4 6:16:54 AM: debug Parsing 'index:0F, mac:4C11BF298685, ip:C0A8010F, port:0050, requestId:d86e0efc-e83e-4167-a6c0-9be9c16071d6’
1cd2ae5f-7a5e-442b-a292-afd9a7827cd4 6:16:53 AM: debug GET cgi-bin/snapshot.cgi HTTP/1.1
Accept: /
User-Agent: Linux UPnP/1.0 SmartThings
HOST: 192.168.1.15:80
Authorization: Basic YWRtaW46UmVtVmlldw==

1cd2ae5f-7a5e-442b-a292-afd9a7827cd4 6:16:53 AM: debug The method is GET
1cd2ae5f-7a5e-442b-a292-afd9a7827cd4 6:16:53 AM: debug The Header is [HOST:192.168.1.15:80, Authorization:Basic YWRtaW46UmVtVmlldw==]
1cd2ae5f-7a5e-442b-a292-afd9a7827cd4 6:16:53 AM: debug Uses which method: GET
1cd2ae5f-7a5e-442b-a292-afd9a7827cd4 6:16:53 AM: debug Requires Auth: true
1cd2ae5f-7a5e-442b-a292-afd9a7827cd4 6:16:53 AM: debug path is: cgi-bin/snapshot.cgi
1cd2ae5f-7a5e-442b-a292-afd9a7827cd4 6:16:53 AM: debug The device id configured is: C0A8010F:0050
1cd2ae5f-7a5e-442b-a292-afd9a7827cd4 6:16:53 AM: debug 0050
1cd2ae5f-7a5e-442b-a292-afd9a7827cd4 6:16:53 AM: debug IP address entered is 192.168.1.15 and the converted hex code is c0a8010f

As you can see, same thing. No S3 key/bucket, just the request id.

Is there some configuration on the SmartThings hub I could have wrong?

10

How big is the response? What type of camera? St hub may truncate larger images and responses even with s3. Also s3 is flaky for some. Corrupt images or timeouts. Open a support ticket as I can’t do anything from my side.

11

Very interesting point. Is there any data on the size restrictions on messages/images?

12

Yes but like a lot of things. They are documented. @jim might be able to provide insight if his backlog isn’t too deep.

13

Thanks. The size seems to have been the problem. From experimentation, it seems like the practical limit is just under a 30KB payload (content beyond headers.)

I’ve got it working now. What a PITA that was!