SmartThings Community

[RELEASE] Foscam Camera Device Handler Universal DTH with Discovery, Live Video Streaming, Motion Sensor/Alarm Integration - SD (FI89xx), HD Ambarella FI98xx, FI99xx, Cx, Gx, Rx, Ex, Zx, Fosbaby

I am getting this sequence in the event log when trying to “Take” . Pulling the URl out and running it standalone I get the image back in a browser. Any ideas?

f2581f8e-e1f1-4f88-8ff2-bd32944096cd 1:26:13 PM: debug Falling back to hubAction and retrying command
f2581f8e-e1f1-4f88-8ff2-bd32944096cd 1:26:13 PM: warn Unable to connect to host, Error: groovy.lang.MissingMethodException: No signature of method: groovy.util.slurpersupport.NodeChild.getText() is applicable for argument types: () values: []
Possible solutions: text(), text(), getAt(groovy.lang.IntRange), getAt(int), getAt(int), getAt(java.lang.String)
f2581f8e-e1f1-4f88-8ff2-bd32944096cd 1:26:13 PM: trace Received response from camera to httpGet, headers=text/html, status=200
f2581f8e-e1f1-4f88-8ff2-bd32944096cd 1:26:13 PM: trace IPAddress is a public IP Address
f2581f8e-e1f1-4f88-8ff2-bd32944096cd 1:26:13 PM: trace Sending command ->
f2581f8e-e1f1-4f88-8ff2-bd32944096cd 1:26:13 PM: trace Request was successful, data=[[[, class:IN, ttl:12, type:A, ip:]]], status=200
f2581f8e-e1f1-4f88-8ff2-bd32944096cd 1:26:13 PM: debug Taking Photo

The ST cloud can’t reach your camera one possible issue is port forwarding, another could be a firewall.
When you do it yourself in a browser is loops back at the router so it is an incorrect result

What’s before this? This is the fallback mechanism, why did the primary one fail? Reason’s would be the same, port forward / firewall etc. The cloud can’t reach your camera. Use an Internal IP address instead.

I get this:
f2581f8e-e1f1-4f88-8ff2-bd32944096cd 4:58:04 PM: trace Received response from Camera to hubAction

but still no image visible in the App on iOS or Android.

I will test now with an internal IP address. I started there and it did not work. As an aside, all the other interactions with the device (polling, etc) appear to be working via the public address.

Here is the result with a private address

f2581f8e-e1f1-4f88-8ff2-bd32944096cd 4:59:39 PM: trace Received response from Camera to hubAction f2581f8e-e1f1-4f88-8ff2-bd32944096cd 4:59:38 PM: trace IPAddress is a private IP Address f2581f8e-e1f1-4f88-8ff2-bd32944096cd 4:59:38 PM: trace Sending command -> f2581f8e-e1f1-4f88-8ff2-bd32944096cd 4:59:38 PM: debug Taking Photo f2581f8e-e1f1-4f88-8ff2-bd32944096cd 4:59:38 PM: trace IPAddress is a private IP Address

Hey Ray,

Just bought a license but I can’t get the take picture to work. Clicking it just have a blue cricle and stay there forever. If I use a browser and use the link: it load right away.

Looking at the logs, I can see it’s receiving the response but that’s about it, the picture is not showing up:
e252dfda-2add-4daa-93e2-ae06a6de55e6 5:58:24 PM: trace Received response from Camera to hubAction
9965f885-ffa3-425c-9f7c-575a5a57c9f1 5:58:21 PM: trace IPAddress is a private IP Address
9965f885-ffa3-425c-9f7c-575a5a57c9f1 5:58:21 PM: trace Sending command ->
9965f885-ffa3-425c-9f7c-575a5a57c9f1 5:58:21 PM: debug Taking Photo

I have a Foscam FI9826P. You mention that a slow connection might be the issue here and to use the external url. However, this didn’t work either as you don’t seem to be supporting reverseProxy url. I can’t load my webcam through the ip directly, I need to use the name when trying to connect to the server. Seems like you should be using the url as it instead of the ip…

I’m looking for solution here…


Try entering your external/WAN IP address. I made the change from device IP to WAN IP and it loads much faster.

Also, make sure to setup port forwarding on the router.

Thanks for the suggestion, as I said in my earlier post, I’ve tried to use the WAN URL but it transform the url to my ip, which is a problem since the cam is behind a proxy.

Unfortunately the picture is very sensitive to time and a slow anything can disrupt it. Try rebooting your camera and hub and that helps speed things up.

Yeah, Already did and didn’t have much luck. Where exactly is the timeout happening ? from where to where ? I don’t see any timeout error in the logs at all. Look like it has received the response from Camera to the hubAction and died after.

The timeout would then be from the hub to the cloud ? I’m trying to pin-point where is the problem and see if we can do anything about it. In my opinion, at least logging something in the logs would help identifiy where is the timeout happening ?

As far as the wan URL, would it be possible to use the provided name in the url to connect instead of the ip ?

Looks like Jonathan and I have very similar problems. What happens after the “hubAction” call? I also get pictures back immediately from a direct URL call via a public IP or via the local address. I have tried both ways within the Device with no luck. I also tested the App from on Lan and from outside just in case it was a problem with retrieving the picture to display but still no luck. Maybe this is an App problem - is there any other way to confirm the image is being captured and stored by the Hub into S3?

If it’s an app problem it won’t work for others but if you scroll up you’ll see that’s others were able to resolve it by fixing their setup.
The issue is between the camera and the ST platform. The app just connects them together. If either runs slow the picture isn’t uploaded to the Amazon S3 cloud (no errors are thrown). If it doesn’t upload it won’t show up on the device. It’s working fine for most folks with local and public IP. However you need to configure your router properly with port forwarding. Using local IP introduces another layer in between the camera and the cloud, IE the hub. This slows it down further. Especially with the v2 hub, it adds a lot of latency. Hence the recommendation to use public IP with port forwarding.
Spend some time and scroll through the last 6 months of posts and see how people have gotten their cameras to work and reduce latency issues with the network. It’s a latency issue, so I would suggest focus the efforts on finding out why your network has latency and how to reduce it.
Here are some reasons I’ve seen on this forum which folks have identified fixed and then got it to work eventually

  1. Reboot your router, hub and camera (50% of issues)
  2. Use public IP with port forwarding
  3. Get off WiFi and try it. Some folks have noted their wifi networks were congested and introduce latency. One disabled all devices on his network temporarily and found that it started working. Then one by one isolated the errant device causing network latency when connected to wifi.
  4. Move back to the v1 hub (if you have it)
  5. Your platform instance is running slow. If this is the cause then there is nothing you can do about it. This would cause the picture transfer from the camera to the cloud to slow down and then the cloud will drop the picture. As This is instance specific it doesn’t affect all users. Just wait for a while and hope your instance fixes itself through load balancing.

The app works fine when configured and use in the right environment.

1 Like

I had the no picture problem with one of mine and had to change the port number, fwd the new port and reboot it.

1 Like

Thanks for the extra info RBoy, much appreciated.

Rebooting everything might help but is not really a long term solution, I do have servers running and can’t afford rebooting every time I’m experiencing some issues.

As far as using a public ip with port fowarding, I’ve raised the issue earlier. I can only use the hostname in the url (not the ip), and my proxy will foward to the hub. I’m not sure if it’s you or the smartthing platform but when I enter a URL, it’s trying to connect through the ip instead and this is where the problem rely. Basically, if we enter a url, it should be using the url to make the request, not the ip. Note sure if you have any control within the app or it’s a smartthing platform bug ? Let me know and I’ll try to raise it against the platform if so.

I think we both agreed that there is some latency issue at some level, but it should not drop the request, it should just take a little more time, at worst. Not proving any feedback and hoping for the best is not ideal, from a platform perspective. I’m not sure where we could raise the concern ? It seems that it’s from the hubAction back to the cloud that is causing some issue because we clearly see the request to the camera coming back.

I think it’s up to us to raise these issues with the platform, when we don’t have control at the app level.

As you can see, I like to transform “there is nothing you can do about it” statement into solutions. I understand that there some limitation about what you have control but we should let them know what are these issues, I believe.

I get your frustration with the platform, trust me you aren’t alone :slightly_smiling:
But it’s beyond the scope of this thread, you can report it to ST support or start a new thread and invite the ST folks to comment on it. I’ve started a thread on the forum in the SmartLounge but am yet to get a response from ST on it.

Yup, that’s great, as long as we keep them aware of the situation it’s the only way the platform will improve right :slight_smile: If you could share the link of the thread in the SmartLaunge that would be great !

It’s by invitation to dev’s. If you have access

1 Like

Hi, I have some issues with setting up my foscam with your app. When i add the device according the instructions.i get the following error:

Any idea what it could be?

Try saving it again. Might be IDE issue.

nope did that like 20 times already :sweat: