Outdoor Smartcam SNH-E6440BN

[mrginogit]

Hi,

Trying to use this device handler with my outdoor Smartcam SNH-E6440BN. I'm able to add the device and configure the IP/port, but see the following when I press "Done" to save the settings:

5:55:13 PM: debug parse() received message likely meant for other device handler (requestIds don't match): [index:15, mac:<<mac in hex>>, ip:<<local IP in hex>>, port:0050, requestId:a2fc0bfd-7507-4620-b0e7-687e4193c74a, callback:true, headers:[http/1.1 200 ok:null, x-powered-by:PHP/5.2.17, transfer-encoding:chunked, content-type:application/json, server:SmartCamWebService, date:Sat, 16 Dec 2017 01:55:12 GMT], body:{"Channel.0.DetectionType":"Off","Channel.0.DetectionResultOverlay":false,"Channel.0.Sensitivity":"VeryLow","Channel.0.MinimumObjectSize":"0,0","Channel.0.MaximumObjectSize":"0,0","Channel.0.ROIMode":"Outside","Channel.0.ROI.2.Coordinate=":"872415234,16777220,0,67108864","Channel.0.ROI.3.Coordinate=":"872415235,33554436,0,0"}, header:HTTP/1.1 200 OK 
X-Powered-By: PHP/5.2.17 
Content-type: application/json 
Transfer-Encoding: chunked 
Date: Sat, 16 Dec 2017 01:55:12 GMT 
Server: SmartCamWebService, status:200, data:[Channel.0.ROI.2.Coordinate=:872415234,16777220,0,67108864, Channel.0.DetectionResultOverlay:false, Channel.0.ROIMode:Outside, Channel.0.MinimumObjectSize:0,0, Channel.0.ROI.3.Coordinate=:872415235,33554436,0,0, Channel.0.DetectionType:Off, Channel.0.Sensitivity:VeryLow, Channel.0.MaximumObjectSize:0,0], json:[Channel.0.ROI.2.Coordinate=:872415234,16777220,0,67108864, Channel.0.DetectionResultOverlay:false, Channel.0.ROIMode:Outside, Channel.0.MinimumObjectSize:0,0, Channel.0.ROI.3.Coordinate=:872415235,33554436,0,0, Channel.0.DetectionType:Off, Channel.0.Sensitivity:VeryLow, Channel.0.MaximumObjectSize:0,0]]
  5:55:13 PM: debug parse()

These settings don't seem to match the current settings on the camera (i.e. detection is currently on not off).

Then, here's the error message when I try to turn motion on via the SmartThings device:

5:56:00 PM: debug parse() received failure message: [index:15, mac:<<mac in hex>, ip:<<local IP in hex>>, port:0050, requestId:34652b89-11cf-43ab-bc4e-429c15f32aaa, callback:true, headers:[content-length:0, http/1.1 500 internal server error:null, x-powered-by:PHP/5.2.17, content-type:text/html, server:SmartCamWebService, date:Sat, 16 Dec 2017 01:55:59 GMT], body:null, header:HTTP/1.1 500 Internal Server Error 
X-Powered-By: PHP/5.2.17 
Content-type: text/html 
Content-Length: 0 
Date: Sat, 16 Dec 2017 01:55:59 GMT 
Server: SmartCamWebService, status:500]
  5:56:00 PM: debug parse()
  5:56:00 PM: debug parseResponse()
  5:55:57 PM: debug Creating camera request with method: PUT, uri: /stw-cgi-rest/eventsources/videoanalysis, payload: [DetectionType:MotionDetection], isRetry: false
  5:55:57 PM: debug on()

[airdrummingfool]

Hmm, unfortunately the logs aren't super helpful. Let's try some command-line HTTP requests and see what the result is. I'm using (and recommend) httpie. Please post the responses you get from the following queries (replace [user], [pass], and [camera ip] as appropriate):

First, let's check firmware version (feel free to redact serial number, MAC, etc):

http --auth-type digest --auth [user]:[pass] GET [camera ip]/stw-cgi-rest/system/deviceinfo

Then we'll check the videoanalysis endpoint.

http --auth-type digest --auth [user]:[pass] GET [camera ip]/stw-cgi-rest/eventsources/videoanalysis

Then we can try a simple POST to turn on detection:

http --auth-type digest --auth [user]:[pass] PUT [camera ip]/stw-cgi-rest/eventsources/videoanalysis "DetectionType"="MotionDetection"

[mrginogit]

Thanks for the action plan! Sorry for the delay, holiday travel. Here's what I got back.

Firmware version:

HTTP/1.1 200 OK
Content-type: application/json
Date: Sat, 23 Dec 2017 04:32:54 GMT
Server: SmartCamWebService
Transfer-Encoding: chunked
X-Powered-By: PHP/5.2.17

{
    "BuildDate": "2016.09.22",
    "ConnectedMACAddress": "<<mac>>",
    "DeviceType": "NWC",
    "FirmwareVersion": "1.03_160922",
    "Model": "SNH-E6440BN",
    "SerialNumber": "<<serial>>"
}

videoanalysis endpoint:

HTTP/1.1 200 OK
Content-type: application/json
Date: Sat, 23 Dec 2017 04:34:04 GMT
Server: SmartCamWebService
Transfer-Encoding: chunked
X-Powered-By: PHP/5.2.17

{
    "Channel.0.DetectionResultOverlay": false,
    "Channel.0.DetectionType": "Off",
    "Channel.0.MaximumObjectSize": "0,0",
    "Channel.0.MinimumObjectSize": "0,0",
    "Channel.0.ROIMode": null,
    "Channel.0.Sensitivity": "VeryLow"
}

PUT attempt: not much here unfortunately.

HTTP/1.1 500 Internal Server Error
Content-Length: 0
Content-type: text/html
Date: Sat, 23 Dec 2017 04:34:35 GMT
Server: SmartCamWebService
X-Powered-By: PHP/5.2.17

[airdrummingfool]

The http method for the last request should be a PUT, not a POST. I'm guessing that's just a typo in your reply, since actually performing a POST should yield a 405 error - can you confirm this?

If the result of a PUT is a 500 error, that tells me there may be an issue in the firmware itself (if the request is just bad or malformed, the server should return a 4xx error). Is there newer firmware available for the device? I can't simply recommend you upgrade (given that people can be very particular about their firmware versions), but if there's a newer version, it's possible this issue is fixed.

You may also want to try changing a different setting, to see if other routes are affected. Perhaps try turning the status LED off:

http --auth-type digest --auth [user]:[pass] PUT [camera ip]/stw-cgi-rest/io/otheroutputs "StatusLED.State"="Off"

[mrginogit]

Sorry, yes, that last one I ran as a PUT but typed POST by accident. I just updated the comment above to correctly say PUT.

I just ran the Status LED PUT command and that worked fine!

HTTP/1.1 200 OK
Content-Length: 0
Content-type: text/html
Date: Tue, 06 Feb 2018 23:31:32 GMT
Server: SmartCamWebService
X-Powered-By: PHP/5.2.17

Unfortunately there's no firmware update available =\ I'm on version 1.03_160922.

Is it possible that the path is just different for this model? Is there something we can run against it to list all the available routes?

[airdrummingfool]

I don't think the path is different - if the route you're testing with was incorrect, you'd receive a 404 error instead of 500. I don't have any tools to check all of the available routes in any given firmware, but all signs point to this being the correct route (unfortunately).

I am curious if turning detection "Off" works; however testing this won't help us get any closer to enabling detection.

http --auth-type digest --auth [user]:[pass] PUT [camera ip]/stw-cgi-rest/eventsources/videoanalysis "DetectionType"="Off"

[mrginogit]

No luck there either, 500 again.

HTTP/1.1 500 Internal Server Error
Content-Length: 0
Content-type: text/html
Date: Tue, 27 Feb 2018 01:42:09 GMT
Server: SmartCamWebService
X-Powered-By: PHP/5.2.17

What if I wired this thing through my PC and fired up wireshark, is there anything you can think of that would be useful there to help reverse-engineer this? Or does it really just boil down to them not having the route configured properly in the firmware?

[airdrummingfool]

We're seeing everything useful. Unfortunately, it really does appear that the route is broken in the firmware.

There is always the (very slight!) chance that the request parameters are different for this particular firmware, but that would be bad API design on their part, and it wouldn't line up with what has been reported for other devices so far. Plus, using the wrong parameters should result in a 405, not a 500 (confirmed using bad request params on my camera). There's also really no easy way to know what those parameters would be - I determined the parameters that I use through trial and error.

I'm sorry I don't have any better news for you - I'm out of ideas. You could try to contact Samsung (Techwin, really) and file a bug report, but I can't imagine that would have any appreciable effect.

[mrginogit]

No worries!! I appreciate all the help you've given!

I did try to contact Samsung about a year ago, and they told me the API is not supported. So that went nowhere, as expected.

I'll try this all again and report back if they ever release a new firmware version.

Thanks again!