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.
This change now in development release v18.4.10.
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.
Works like a champ Ak! I can now see my camera snapshots on the control panel and they update just like UI7 does. Thanks a bunch!
Good to know! Thanks again for asking in the first place. This was something that I’ve wanted to get right for quite a time.
Would it be possible for the request_image to have the luup.inet.wget replaced by code that will switch to digest authentication if it gets the 401/www-authenticate response? Essentially, this code: lua-http-digest/http-digest.lua at master · catwell/lua-http-digest · GitHub I believe UI7 supports this for the same request (http://forum.micasaverde.com/index.php/topic,38406.msg326659.html#msg326659).
Thanks
I’ll take a look!
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?
Good question, and there’s lots of ways.
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-md5so 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?
Edit: * it looks as though this might do the trick: https://docs.postman-echo.com/
[quote=“akbooer, post:40, topic:198812”]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?[/quote]I can provide access if you would like to try this with a real camera. Or I can be an alpha tester for you…
I am trying to move an amcrest camera from the vera to Openluup and have gotten to make it show livestream on ALTUI. However, I am unable to control it’s PTZ, not even the presets. I have run some test and found that somehow running
luup.inet.wget (“http://camera.ip/cgi-bin/ptz.cgi?action=start&channel=0&code=GotoPreset&arg1=0&arg2=2&arg3=0”,5, username, password) on the vera works while it doesn’t on openluup.
Is there a difference in how the luup.inet.wget function is handled? are the timeout and credentials handled?
Most of the Amcrest cameras require digest authentication. This was just discussed over here: http://forum.micasaverde.com/index.php/topic,63465.msg380840.html#msg380840 Vera seems to know how to try digest authentication if the basic authentication fails.
I’m not 100% sure how you can get the live stream to work, but maybe that uses something else to authorize (or doesn’t need it). Or my theory above is wrong.
I’ve just merged the previous two posts from a separate new thread into this topic.
Yes @rafale77, as @jswim788 has mentioned, this is the discussion to watch.
Yes both, I am being tardy in implementing this, although I see no real technical problem in doing so. I’ve made some steps forward with cameras recently, and it’s important to me to try and get this aspect of openLuup as functional as possible. The SMTP server and email camera triggers were part of that. That then prompted a POP3 server for more general email use, and an implementation of file retention policies to contain the burgeoning image files. There are going to be some limits as to what is possible, in particular video streams, for which I mostly rely on AltUI.
There are reasons for my slowness here, not least the other demands you have placed on me recently (but other more significant ones too!) I just need a bit of time to sort myself out.
Thanks.
[quote=“jswim788, post:44, topic:198812”]Most of the Amcrest cameras require digest authentication. This was just discussed over here: http://forum.micasaverde.com/index.php/topic,63465.msg380840.html#msg380840 Vera seems to know how to try digest authentication if the basic authentication fails.
I’m not 100% sure how you can get the live stream to work, but maybe that uses something else to authorize (or doesn’t need it). Or my theory above is wrong.[/quote]
Well I am sure now. I brute force it by using a Oscommand and curl from ALTUI and it works.
curl --digest -u "username:password" "http://ipaddress/cgi-bin/ptz.cgi?action=start&channel=0&code=GotoPreset&arg1=0&arg2=1&arg3=0"We could use an os.execute line in my xml instead of luup.inet.wget…
I really, really, really, don’t recommend this.
Just give me time to fix it.
PM me if you want a sob story about why I’m not as fast as fixing things as @amg0 at the moment (maybe I never was!)
ok I won’t do it and wait. But at least we know for sure that jswim788 is correct in his assumption.
Ok found another way to do this:
I went here:
took the http-digest.lua file and dropped it in
/usr/share/lua/5.1 amongst a few other lua modules. (Pretty sure I could have dropped it in the openLuup folder too)
Then used then tested my camera with
local http_digest = require "http-digest"
local url = "the camera API URL I needed"
local b, c, h = http_digest.request(url)
I could use this in my Amcrest Plugin. @akbooer, thoughts?
I attached the lua file.
Amcrest Dahua Camera Plugin available. Don’t want to publish as of yet as it uses a work around which should really be integrated into openLuup. I will revise it as openLuup evolves.
[url=https://github.com/rafale77/Amcrest-Dahua-Openluup]https://github.com/rafale77/Amcrest-Dahua-Openluup[/url]