Help troubleshooting hubAction

Hi.

I hope this is the right forum., Im trying to write a device type that sends a request out via hubAction. I actually had it working at somepoint but now the http request longer seems to go out. Im returning the instance of physicalgraph.device.HubAction from my command method and I’ve poured through forum posts and double checked that I am not making any of the common mistakes. Because of some weird browser problems i somehow lost the working version and trying to re-create the code ive been unsuccessful. I’ve seen some forum posts that hinted at changing the ip address and getting it to work - which I’ve even tried. Not sure what Im doing wrong and I have no clue how to troubleshoot this further. Any advice would be appreciated.

Thanks

// handle commands
def poll() {
	log.debug "Executing 'poll'"
	sendEvent(name: "switch", value: "off")
    def x = pingMachine();
    
    log.debug x;
    return x;
}

def pingMachine(evt)
{
	log.debug "pingMachine!!!";    
    return hubGet( "/ping" );
}

private hubGet(def apiCommand) {
	//Setting Network Device Id
    def iphex = convertIPtoHex(ip)
    def porthex = convertPortToHex(port)
    device.deviceNetworkId = "$iphex:$porthex"
    
    log.debug "The device id configured is: $device.deviceNetworkId"
    
	log.debug("Executing hubaction on " + getHostAddress() + apiCommand)    

    sendEvent(name: "hubactionMode", value: "local");
	
    def hubAction = new physicalgraph.device.HubAction(
    	method: "GET",
        path: apiCommand,
        headers: [HOST:getHostAddress()]
    )
    
    return hubAction;
}

def parse(String description) {

//code omitted for brevity since the request never goes out and its never called.

}

Are you subscribing to the location? Is the dni set correctly?

I don’t think device types subscribe… parse() gets called automatically for results, as far as I understand. As pstuart recommended - check that your network id is set correctly. I spent hours troubleshooting a similar issue and it eventually turned out the be that I used a uppercase HEX converter for the IP and lowercase for the port. As crazy as it sounds, it seemed both port and ip had to be the same case.

Thanks for the replies.

I am not subscribing to the location and if I do need to, please explain what exactly that means or how I do that. I’m kind of a noob at this still.

I’m pretty certain the dni is correct and both the hex ip and port are in lowercase. I’ve used this ip and port previously and I think that may be the reason this device type doesnt work. I think there is some uniqueness necessary for this across all devices and previous instances that have been deleted dont seem to “unregister” the device network id.

I’ve been experiment with the foscam sample and have seen the parse method get called and then later no longer get called when switching to an ip and port that was previously used. It’s not often I doubt the environment before doubting my code, but in this case I’m pretty sure it’s not my code.

I’ve had issues with devices not deleting properly, and then I end up with ghost devices. This stops the code working immediately because then the ghost device gobbles up the responses. I’ve had this happen twice now. You can check in Live Logging if this is an issue - you will see two instances of the device logging.

But yes, I would not be surprised if the platform doesn’t properly de-register deleted devices.

After support cleaned up my devices last time, I was able to re-use the IP.

I wound up figuring this out and I’m posting it here in case anyone else runs into the same trouble.
When adding a device of my device type to my device list I set the location to home, but never bothered setting the hub to my hub. Since the device would “show up” on my mobile device’s dashboard and respond to taps and such, I had no way of knowing the hub needed to be set too. HubActions do not seem to do anything unless you have hub set on your device type instance.

Was this obvious to anyone else?

1 Like

Thanks for posting this solution @herbcarroll it just helped me identify the same problem caused by a Device without a hub set (a LIFX bulb in my case).