HubAction parse no longer being called?


(automaton82) #1

I have a very simple HubAction that worked until last week when it stopped. I can confirm the request goes out and is received, but parse just never gets called anymore (there was no changes in the code).

Code is just the regular (generic video cam code):

    def userpassascii = "${CameraUser}:${CameraPassword}"
	def userpass = "Basic " + userpassascii.encodeAsBase64().toString()
    def host = CameraIP 
    def hosthex = convertIPtoHex(host).toUpperCase() //thanks to @foxxyben for catching this
    def porthex = convertPortToHex(CameraPort).toUpperCase()
    device.deviceNetworkId = "$hosthex:$porthex" 
    
    log.debug "The device id configured is: $device.deviceNetworkId"
    
    def path = CameraPath 
    log.debug "path is: $path, Requires Auth: $CameraAuth, Uses which method: $CameraPostGet"
    
    def headers = [:] 
    headers.put("HOST", "$hosthex:$porthex")
   	if (CameraAuth) {
        headers.put("Authorization", userpass)
    }
    
    def method = "GET"
    try {
    	if (CameraPostGet.toUpperCase() == "POST") {
        	method = "POST"
        	}
        }
    catch (Exception e) { // HACK to get around default values not setting in devices
    	settings.CameraPostGet = "GET"
        log.debug e
        log.debug "You must not of set the perference for the CameraPOSTGET option"
    }
    
    try {
    def hubAction = new physicalgraph.device.HubAction(
    	method: method,
    	path: path,
    	headers: headers
        )
        	
    hubAction.options = [outputMsgToS3:true]
    hubAction
    
    log.debug hubAction
    }
    catch (Exception e) {
    	log.debug "Hit Exception $e on $hubAction"
    }    

Parse method (never hit):

def parse(String description) {
	log.debug "parse $description"
}

Originally this was not using hex username / password, when I changed that it started working again. However the next day it began to not work again. Anyone know what the heck is going on?

Other device handlers I have that also use HubActions (but don’t rely on parse) continue to work just fine.


Generic Camera Device using local connection (new version now available)
(automaton82) #2

If anyone else runs into this, I had to go back to the original example here:

http://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-types-developers-guide/working-with-images.html

In order to make this work, I had to manually set the DeviceID on the camera device to be the HEX_IP:HEX_PORT (you’ll notice that’s what getHostAddress expects.

Second I had to put the HOST header back to regular IP:Port (not hex). Third I had to modify the take method to return the action.

What a mess.


(Spinn360) #3

Can you share the whole code that works? And maybe clarify what you mean by setting the DeviceID to the HEX_IP:HEX_PORT… How did you get the hex versions? Thanks!

Update: the latest one posted automatically updates the Hex IP and Hex port for the device ID so I got that covered, but I cannot get it to take pictures… the path I have for my IP Webcam app (android phone turned IP cam) is /photo.jpg

Any help would be great. Thanks


(automaton82) #4

The code from ST’s site (https://docs.smartthings.com/en/latest/cloud-and-lan-connected-device-types-developers-guide/working-with-images.html) has the getHostAddress method which shows how to get it as hex.

However, no matter how I do it, it still only works randomly.

I can’t get it to work 100% of the time. I’m not sure what is going on, but it will work maybe 1-2 times a day if I connect to live logging, and then randomly no longer work again for 1-2 days.


#5

Still images appear to be not working again. ST fetches the image from the camera/webserver/etc, but then will never display it. instead showing a “(.) SmartThings” image.

Video streams work fine, of course, not requiring"cloud"

Not sure what to check/debug,

10.10.10.100 - - [23/Aug/2018:23:00:16 -0700] “GET /3.jpg HTTP/1.1” 200 327834 “-” “Linux UPnP/1.0 SmartThings”


(automaton82) #6

Thanks for the reply. Yes the issue appears to be size. Try it with an image of a few MB, and you will notice this behaviour.


#7

Ahh - didn’t realize that… thanks. I’ll try feeding smaller images, see if I can make it work.


#8

Did some testing, it’s a dimension/resolution problem, not a fileSIZE problem.

wasn’t successfully with anything TALLER than 480… IE 848x480 (16:9) works… 896x504 doesn’t.

Pain in the ()@#$, but workable.