This is working fairly well for me now. Thanks, akbooer!
One note for anyone else trying this: pay attention to the last quoted sentence below. I mistakenly assumed the actions would be on the camera itself, but I reread the sentence and sure enough, they are on the openLuup plugin. So don’t get lost looking for them on the camera - they are not there!
I’ve taken a look at this and done some refactoring, including adding [tt]/data_request?id=lu_archive_video[/tt], which I had previously not implemented. However, the problem that I hit is that every camera has its own syntax for the URL parameters, including username and password. For example, my Foscam needs a line such as:
I can say that the Amcrest camera I have wants authorization in the HTTP headers (digest authorization). I use something like this with curl to get the image:
So I’m assuming that, at least for the camera you are using, the authorization is done in the HTTP request headers and not with URL parameters.
There’s not really any problem in implementing this, and I haven’t yet tried it with my own camera, but I thought I should check before proceeding.[/quote]
Assuming AltUI uses one of these requests for rendering a cameras control panel pages (all I can tell currently is that your wget function gets called with the IP/URL pattern eventually), and/or this is what?s used when I trigger a request to capture a snapshot, we should be good! Thanks again.
As mentioned in the earlier thread, AltUI uses the DirectStreamingURL for direct access to camera video, when available. However, if you know that wget is called for your setup, then this should do it.
and/or this is what?s used when I trigger a request to capture a snapshot, we should be good! Thanks again.
AFAIK, that’s the only way to get a snapshot. I’ll try and release this later today.
Indeed, with no VideoStreamingURL, AltUI uses [tt]/data_request?id=request_image&cam=xxx[/tt] to try and generate an image stream. This seems to have something of a detrimental effect on my browser, introducing some sort of (large) delay to the displayed image. This only happens when on the device’s control page. A thumbnail is not presented on the Devices page.
However, both [tt]request_image[/tt] and [tt]archive_video&format=1[/tt] (for a JPEG snapshot) work, with the image being written to the [tt]cmh-ludl/images/[/tt] folder.
With [tt]username[/tt] and [tt]password[/tt] as defined device attributes, the URL is suitably modified for these calls.
I was already thinking of including the MD5 hash algorithm for authentication in the POP3 server which is now part of openLuup.
If I can get the digest authentication coded correctly, then I think that the easiest thing would simply be to have an additional parameter to [tt]request_image[/tt] which specifies which authentication to use, rather than trying one and then another.
That sounds more efficient. But how does the user get the parameter into the request_image when AltUI is making the request? It would need to be in the camera device URL variable or some other variable that the GUI already accesses and passes on to the request_image? (As you can see I’m not very familiar with how the GUI’s such as AltUI do their work here.) Or is the idea to make this AltUI specific where it knows to look at an additional variable?
At the moment, there is a global openLuup system attribute “openLuup.Server.WgetAuthorization”, which is, by default, set to “URL”. It may be set to “Header” to allow the use of headers instead. It would be an easy matter to extend the options to Digest on a request-by-request basis. But I’ll play with it and see.
I’ve just been reviewing MD5 Lua modules, and my iMac has the “md5” one, which is also available to install under Debian systems (RPi, etc.)
apt-get install lua-md5
so we’re halfway there.
My main impediment in testing, ATM, is the lack of hardware which needs this. An alternative is an appropriate website. Any suggestions* for what I could try?