Limit camera refresh rate in emulation mode

Other Devices & Integrations Door Locks & Sensors
#1

Hi folk,

I have a bunch of Q-See (Dahua) cameras that are hooked to my Vera Plus.

Is there any way to limit the refresh rate on a D_DigitalSecurityCamera2.xml device?

I’m running these cameras in emulation mode so Vera is grabing JPEGs at a pretty high rate. A few of the cameras I have have some sort of flood control security and block the Vera after viewing the camera few a little while from Vera. I then have to power cycle the affected camera. If I can slow the rate at which Vera polls the device, I think I can resolve my issue. Any ideas?

Thanks!

#2

That’s a really good question.

I ran into a similar problem, but didn’t, alas, come up with a simple solution. The only idea I have to offer is to make a dummy device of the same variety and implement the request_image action with a built-in delay using luup.call_delay()

Not trivial to do, but not too difficult, perhaps. However, if you’re not a developer, this won’t help. Sorry!

#3

akbooer, Thanks! You’re always incredibly helpful! I’m new to Lua but can code. I’ll take a look and see if it’s worth my time.

#4

You’re welcome, although nothing has actually been achieved yet!

On further thoughts, just a new implementation file for the device in question would probably do it.

You’d have to duplicate any of the actions which you use. Is it steerable? Or is it just fixed, and all you need is the images?

An existing example would be the Foscam implementation, which is floating around somewhere.

#5

I was referring to your help many years ago with the Netatmo plugin :slight_smile: Correct, it’s fixed and all I need are the images.

#6

Oooh, four years ago, already!

Correct, it's fixed and all I need are the images.

That simplifies things, but the trick will be in delaying the response without blocking other device actions. What would you regard as a useful delay between image updates? Actually, what do you get at the moment, with no delay?

#7

Right now it seems to do about 3-4 FPS which is a bit too much for a few cameras. I was thinking 1 frame every 3 seconds. Should be enough for getting an idea what’s going on and I can always switch to a dedicated app for non-emulated video.

#8

Do you have another machine/server available other than Vera?

The problem is that if we involve Vera in the process, then we slow EVERYTHING down (and possibly make it restart more often) simply because we would route every image data snapshot through the machine. At the moment, request_image directly uses the camera URL for snapshots, and Vera isn’t in the loop at all.

If you were using AltUI, or openLuup, then there would be other options:

[ul][li]AltUI - we could try and request @amg0 to introduce an optional delay configuration parameter[/li]
[li]openLuup - already implements the &MinimumDelay=… parameter for ALL /data_request&id=… calls[/li][/ul]

It can still be done another way: if you do have a separate machine, you could set up a CGI, say, as a proxy for the camera URL, but with the side-effect that it adds a delay in responding.

Once again, a lot more effort than should be necessary to get around a minor Vera omission.

#9

Thanks for your insight!

Yes, I have a couple servers running all the time. I think I should rethink my configuration. Might be easier to switch my camera recording to one of my servers (vs an NVR) and serve images/video from that server, which would give me better control over how things are handled and would insulate the tiny linux instances in each camera from getting hammered with traffic.

#10

Yes, exactly!