Closed skilau closed 2 years ago
I've considered porting the entire atomcam_tools... the installation and configuration tends to be more complicated, but in a way more efficient.
atomcam_tools uses an ext2 image to serve as the rootfs, and everything is stored there. So if you need to change something, you can not easily do it from the PC, you would have to mount the image first. Though we could still have the conf file reside on the root of the sd card for ease of use.
the next concern is memory usage, with wz_mini, we are almost bone stock, with the exceptions for the ssh server, rtsp server, etc... Does using the ext2 image increase memory usage significantly? It is mentioned that with atomcam_tools the rtsp server is laggy, but this may no longer be the case.
There are a few more things I would like to roll into wz_mini, and we can do a "1.0" release. After that, I would probably prioritize testing a more recent kernel, and then testing atomcam_tools.
stay tuned!
I've been pining for a web interface to change settings as well. I don't know much about atomcam_tools
, and if we'd be reinventing too much by trying to replicate some of the features, but I was imagining an (optional?) process in wz_mini_hacks that would run a basic web server with a single page that would read in the config file, present a form to the user with current values, and allow updating the file on POST of the form and restarting the camera. It would need some configuration for the available values for the config file, but other than that i think it would be pretty small/trivial.
@tensiondriven that's some what similar to how atomcam_tools does it. For whatever combination of reasons it uses https://vuejs.org/ to compose the page. It then passes everything via cgi:
https://github.com/mnakada/atomcam_tools/blob/main/web/source/vue/Setting.vue
This should be flagged as a "Help Wanted" as this requires a little HTML, CSS, CGI scripting and processing. Of course, can be mostly taken from atomcams and altered. Just have to ask if a webserver just to alter a config file once in a while is worth it. If so:
For those wanting to test, there is a basic web server built in:
httpd -p 8082 -h /tmp/www
Will listen on port 8082 with DOCROOT at /tmp/www
Most of the cams also have /usr/boa/boa with config and mimetype files also in that directory ready to play mp4 files.
Again, these would be for quick testing, with NO security (having the boa server running full time on all FW before Mar 17, 2022 actually got Wyze in trouble). Then for production, would enter lighttpd which has some basic security. These are all light weight httpd servers with lighttpd carrying the most weight, but with more security features yet still with security flaws.
Sr. React Engineer here and would love to help with this if you need it! 👋
@yerffejytnac Sweet, which is your specialty, HTML and CSS, CGI scripting, web server, or do you dabble in all?
This should be flagged as a "Help Wanted" as this requires a little HTML, CSS, CGI scripting and processing. Of course, can be mostly taken from atomcams and altered. Just have to ask if a webserver just to alter a config file once in a while is worth it. If so:
I've got 5 Wyze V3s (T31) and 1 atomcam V2 (T31) running wz_mini and atomcam_tools respectively. There's a lot to like about both tools, but right now they're setup pretty differently. I think it'd be rather hard to just port what atomcam_tools has. The current setup there is:
Of that, I guess we can copy the lighttpd config and the hack_ini.cgi concepts. Making a webpage part is pretty trivial.
I will probably try to put something together on the weekend, but my initial thoughts for a completely unsecure dangerous version are:
After that improvements for
can probably get a draft version out this weekend depending on other responsibilities that might appear.
rudimentary display on ini via httpd is now functional: https://github.com/virmaior/wz_mini_hacks/tree/master/SD_ROOT/wz_mini/web/cgi-bin
httpd -p 80 -h /opt/wz_mini/web
will make a pull request once I've gotten the updating script built.
@virmaior Awesome! Thank you so much for starting this! I can't play around with it for a day or 2, (busy), but I totally want to check it out here soon! Thanks again!
more progress (https://github.com/virmaior/wz_mini_hacks/commit/9c065b078fde7645c6610202d238c80e03d8f420). It's basically midnight here so I'm done for the day but can now
Still need:
Rudimentary web server ready (or so I imagine) for integration: https://github.com/gtxaspec/wz_mini_hacks/pull/188
could still use:
and more I'm sure. But it at least works (per my simple testing)
I've updated what I've done so far in the following ways:
Looking at the title again, I've got no idea how to implement the "display the video feed part" which was one of the desiderata. That sort of code does exist in atomcam_tools . I'll have to look at how it's done there.
I won't have time to test it tonight but have static image support using cmd jpeg
(not in merged branch yet: https://github.com/virmaior/wz_mini_hacks/tree/master/SD_ROOT/wz_mini/www/cgi-bin )
put in a new pull request including the screenshot feature.
When I get around to it, I can copy the sort of thing atomcam_tools does -- it's not a live feed in the configuration page; it's a 1x/second refresh the image.
latest pull request shows an image that updates every second of the current camera view.
@skilau I think the latest pull request (https://github.com/gtxaspec/wz_mini_hacks/pull/205) should handle most of what you were hoping for on this item.
What I completely lack a deep understanding of is whether there are any settings we can tweak without requiring reboot to take effect. That would be pretty cool.
Also I don't think we can get in-browser rtsp like video.
@virmaior great job! I agree the only way to get browser like video will be an mjpeg server or maybe onvif?
@virmaior Absolutely! I just tried it out now, and it works great! Thank you so much for stepping up and doing this!
The new web server/pages work great!
This might be too much, cpu-wise and memory-wise for the Camera, but...
I noticed that AtomCam_Tools has a web server that has been created for the camera already.
https://github.com/mnakada/atomcam_tools WebUI (Port: 80) Set additional functions that cannot be set from the ATOM Cam app. You can set an account and password.
I was thinking it would be kind of cool, (but maybe not all that useful? in the real world) to have a web page that allows tweaking of some of the variables in "wz_user.conf", along with a live feed of the camera.
Of course, this might eat up too much cpu and/or memory... And of course, there are security implications as well...