How to catch HTTP GET timeout?

In my custom app, I do a GET to a device with a web interface (using a HubAction and sendHubCommand) but the device likes to change it's IP address occasionally (it's a PowerView hub on WIfi so there is no way to set a static IP even on my router because it doesn't request a DHCP address). How can I catch the timeout on the GET? I see the timeout in the log but I can't figure out how to catch the timeout in my app.

def params = [
uri: "https://${tccSite()}/portal/Device/SubmitControlScreenChanges",
headers: [
'Accept': 'application/json, text/javascript, /; q=0.01', // */ comment
'DNT': '1',
'Accept-Encoding': 'gzip,deflate,sdch',
'Cache-Control': 'max-age=0',
'Accept-Language': 'en-US,en,q=0.8',
'Connection': 'keep-alive',
'Host': "${tccSite()}",
'Referer': "https://${tccSite()}/portal/Device/Control/${settings.honeywelldevice}",
'X-Requested-With': 'XMLHttpRequest',
'User-Agent': 'Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36',
body: [
DeviceID: "${settings.honeywelldevice}",
DisplayUnits: location.temperatureScale
timeout: 10

if (debugOutput) log.debug "params = $params"
try {
	httpPost(params) {
	    resp ->
	        def setStatusResult =
	    if (debugOutput) log.debug "Request was successful, $resp.status" = 1
catch (e) {
	log.error "Something went wrong: $e"

I like the use of the hubAction because it is asychronous and uses a callback (plus the syntax for a GET or POST is much simpler). Do I have to do my own httpPost() to get the timeout?

You can use an asynchronous http post call as well.

Can you explain this a little more? All WiFi devices need to have an IP a address in order to function. While some devices can use static IP addresses assigned on the device itself, most will use DHCP to obtain an IP address. So I am confused as to how your PowerView Hub could be randomly changing its IP address?

Thanks for your reply. I believe that it would be the same as if the PowerView had a fixed IP address. I am guessing the way it works is when you initially set it up on your Wifi, it gets a DHCP address and then after that it randomly picks an IP on the same subnet and submits the request to the router, which grants the address if there is not a conflict. I am surmising this by looking at the log on my router when the PowerView is connecting. I had the MAC of the PowerView fixed to a static IP on my router but the PowerView didn't request a DHCP address after the initial setup, so the router never gave the static address to it. I think this all has something to do with the PowerView remote access though the internet. The only way to have a static address is through the ethernet port on the PowerView but I use Wifi.

That is the strangest WiFi device I have ever heard of. That is 100% non-standards compliant behavior.


Iā€™d be tempted to put it on a subnet with only 1 IP address available just for spite...


I don't know much about the DHCP request protocol but I guess there is a way to make a request with an address to join the network just like as if the device had a static IP and if there is no conflict, the request is granted. I am guessing if the PowerView picks an conflicting IP, it just tries the request with another IP. The only time the router will assign the IP that is bound to the MAC in the router is when the device requests an address from the router. This is what I see in the router log (the :2C MAC is the PowerView):

126 Jan 7 11:48:36 DHCP INFO DHCPS:Send NAK
125 Jan 7 11:48:36 DHCP INFO DHCPS:9401a8c0 6501a8c0
124 Jan 7 11:48:36 DHCP INFO DHCPS:Server id and requested ip not found
123 Jan 7 11:48:36 DHCP INFO DHCPS:Recv REQUEST from xx:xx:xx:xx:xx:2C

I was able to fix this problem by switching to DD-WRT on my router. It will enforce the static IP address even if the PowerView tries to change it's address. The factory TP-Link firmware for DHCP must do things differently when a client requests a particular IP address even if that client's MAC is in the static table.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.