HubAction Strange behavior

@pstuart @NWTony - Hoping one of you can point me on the right direction based on your other posts.

I 've been watching and reading just about every thread there is on HubAction. Most if not all have been very informative. In fact, that has led me to creating my own based on the examples.

I’m trying to accomplish what I believe is an easy task but its turning into a nightmare.

I have a Hayward pool “device” that runs/acts a web server. You can interact with it pretty easy. I’d like to pull this and make my own device type. For now, i’d be content with just reading the data and showing the status of the pool on the buttons.

The web server appears to be basic. A htm page that has a few buttons on a table. Push the button and it turns on/off something. I’m not a developer/web guy but there isn’t any xml or json available and the page does not use any commands via the url. You basically push a button and on push it does something.

My main problem right now is the strange behavior I’ve had with parsing the response. I can’t tell if its a bug in ST or if something else is going that I’m not aware of.

I’ve used any examples and randomly they seem to work for a period of time before breaking.

I’ve used many variations of this method below. At times it works and at other times it doesn’t. What I mean is that the parse function doesn’t seem to be getting data. I’ve been deleting and creating new devices to see if that would help. Sometimes it does… sometimes it doesn’t.

My main problem though is consistency… I can’t seem to get a response all time in live logging with this code. Right now, no parsing/response from the device is taking place.

Anyone have an idea what is going on here? BTW - the webpage is working the entire time without any issues.

Also, I’m wondering (when I poll for index.htm) if the body of the site has somehow hung up things enough that it isn’t flushed or something?? The message response is so large that it does truncate the message. I’ve rebooted the hub many times… no success.

If I should be polling the web server a different way… please let me know. My goal is to pull the page into smartthings and interact via the app rather than the vendor provided webpage for my pool.

def refresh(){

log.debug "Refresh"

def host = CameraIP 
def hosthex = convertIPtoHex(host)
def porthex = convertPortToHex(CameraPort)
device.deviceNetworkId = "$hosthex:$porthex" 

log.debug "The device id configured is: $device.deviceNetworkId"
def headers = [:] 
headers.put("HOST", "$host:$CameraPort")

log.debug "The Header is $headers"

def hubAction = new physicalgraph.device.HubAction(
	method: "GET",
	path: "",
	headers: headers
log.debug hubAction
return hubAction


Below is the latest response based on the request above

dcfdbe48-d659-423e-b72a-24e464e817af 9:19:25 AM: debug GET HTTP/1.1
Accept: /
User-Agent: Linux UPnP/1.0 SmartThings

dcfdbe48-d659-423e-b72a-24e464e817af 9:19:25 AM: debug The Header is [HOST:]
dcfdbe48-d659-423e-b72a-24e464e817af 9:19:25 AM: debug The device id configured is: c0a80131:0050
dcfdbe48-d659-423e-b72a-24e464e817af 9:19:25 AM: debug 0050
dcfdbe48-d659-423e-b72a-24e464e817af 9:19:25 AM: debug IP address entered is and the converted hex code is c0a80131
dcfdbe48-d659-423e-b72a-24e464e817af 9:19:25 AM: debug Refresh

Unfortunately, I’ve had the same experience with inconsistency. I created servers (node and python), can curl against them and see that they work, can scope the action with WireShark/Fiddler, and yet ST will regularly not see the response at all.

One thing that does help though is to keep the response very short. My guess is that ST does terrible connection and memory management.

For better reliability, you may want to use a virtual device, and use the more robust web interfaces available to SmartApps to actually handle the device actions. Sort-of as I do with the SMS interface for LANdroid/LANnouncer.

So I’m glad to know I’m not crazy and having some noob problem…

I think you might be right on the device add/removing issue with the same networkID. I think mine was working 24 hours ago and broke as soon as I did a get request for the page this morning… Now I’m stuck.

On top of that, I deleted device “a” yesterday and created device “b” … “c” etc. I went back and deleted device “a”… hours later I started noticing the device “a” was responding it was executing code. Let me be perfectly clear - I deleted that device hours before.

To get rid of the problem - I deleted all the devices as well as all of my device types. So that wasn’t fun at all.

Hum… well. I’m not sure where to go from here. I put in 2 support tickets yesterday and noticed the instant chat was no longer available either. stays a lot of problems exist right now too.

@NWTony All I want to do is retrieve that button and the status and push the button. Is there a easy way to filter so that I’m not pulling everyhing (some examples I can look at)? I was wanting to get past the parse problem before I tackled the issue with filter down the page… guess I’m kinda there now.

I’m interested in the key_05 button. “Pool Light”


Sorry to resurrect this old thread but I’m wondering if you continued to work on that device handler?

I want to build this too, but would like to help you if you are still working on it!

Let me know!



1 Like

I am in the same situation as described above. I had 2 cases happening on an equivalent development as above HTML scrapping.
In the first case, I was seeing 2 devices in the live logs (different UUID). The reason was that I had a simulator session on so the device based on my DTH was sending a HubAction (HTTP GET) that the simulator instance was parsing.
I contacted ST support and they helped me to identify that, I then suppressed the session and it worked fine… Till I decided to verify once again my device installation before publishing on ST forum my development. And that’s where the second case happened.
I had this time again 2 UUIDs, the second one corresponding to the device I deleted based on the same DTH. So I asked support to help me again and the guy could not suppress this ghost UUID.
I rebooted the Hub and this is now even worse: I don’t see anymore the old UUID in the livelog but I know the request is answered (by a tcpdump running on the raspberry I am hosting the web page I query from the DTH).
So basically, the HubAction is replied but the answer is lost and the parse is not replied.

I deleted devices and DTH, renamed DTH differently and all kind of creative things to get rid of this “ghost” UUID but nothing works. I am continuing right now. Will update if I manage to get this solved.

On the other end, I don’t think I am doing my DTH right but I don’t know how to make it right. To create a Device, we have to put a Device Network Id that will match the URL we are querying. But this needs to be converted in HEX values so basically, it’s hard to compute it before running once the device. And putting a dumb Device Network Id that the DTH will update later once it knows its value leads to this “ghost” UUID issue.


Ok, got it fixed… In order to get rid of this “ghost” UUID as I couldn’t remove it, I just assigned a different IP address to my raspberry so that now the DTH is using a different Device Network ID which maps the raspberry IP. Holly…

Steve, not sure what you need but if you need a DTH that parse a webpage content made of list items, you can refer to my other project Succeeded to write a device handler parsing my arduino humidity and temperature webpage

Thanks this will be very helpful!

Hi !

I don’t know if you made any progress since then, but I now have a basic device handler calling the status page and parsing the information. Sadly it’s winter so hard to make any progress on it since my system is off, but I will continue to work on it when Spring comes !


I had the same issue.
Yesterday, I deleted all device, automaion, DTH and location.
I installed the ST hub again.
After that, it works but it was a pain to add the devices again.
The hub reset will help you for this issue.
But it may break out again.(I met the issue again today morning doing some simulations for hubaction)