gtxaspec / wz_mini_hacks

wz camera mods... make your camera better.
1.31k stars 112 forks source link

Wishlist Item: Web Server that allows tweaking settings and displays the Video feed. #119

Closed skilau closed 2 years ago

skilau commented 2 years ago

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...

gtxaspec commented 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!

tensiondriven commented 2 years ago

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.

virmaior commented 2 years ago

@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

endertable commented 2 years ago

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.

yerffejytnac commented 2 years ago

Sr. React Engineer here and would love to help with this if you need it! 👋

endertable commented 2 years ago

@yerffejytnac Sweet, which is your specialty, HTML and CSS, CGI scripting, web server, or do you dabble in all?

virmaior commented 2 years ago

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:

  1. lighttpd configured like this.
  2. pages written in vue.js (https://vuejs.org/) which does some pretty interesting templating but it also compiles almost everything at build time (meaning that there's no simple easy to edit HTML pages). I've whipped together English translations at https://github.com/virmaior/atomcam_tools/blob/main/web/source/vue/Setting.vue
  3. Sending commands to webcmd.sh as cgi also hack_ini.cgi which modifies modifies parameters for hack.ini which is the equivalent of wz_mini.conf

Of that, I guess we can copy the lighttpd config and the hack_ini.cgi concepts. Making a webpage part is pretty trivial.

virmaior commented 2 years ago

I will probably try to put something together on the weekend, but my initial thoughts for a completely unsecure dangerous version are:

  1. write a bash script that turns each line of wz_mini.conf VAR=val into a .
  2. encapsulate that with a html / form / body over it.
  3. another bash script that would use that to pump a revised version of wz_mini.conf and then reboot the camera.

After that improvements for

  1. types (booleans, mac addresses)
  2. descriptions etc (culled from readme.md)
  3. versioning (move the old wz_mini.conf rather than clobber it)
  4. singling out rows - only take changed items
  5. split updating the file and rebooting the camera

can probably get a draft version out this weekend depending on other responsibilities that might appear.

virmaior commented 2 years ago

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.

skilau commented 2 years ago

@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!

virmaior commented 2 years ago

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

  1. display options with minimal typing support (true/false or text)
  2. POST data to the server from that form
  3. produce a new wz_mini.conf from it
  4. rotate out old versions of the conf file (not presently targeting the real location)

Still need:

  1. reboot on update (this is pretty trivial -- just add "reboot" into the ash script)
  2. descriptions from readme.md
  3. singling out of rows (this would require some JS -- which I could do either in vanilla JS or in jquery)
  4. testing. several cameras are not in locations where I want to have to pull them out after I clobber the wz_mini file.
virmaior commented 2 years ago

Rudimentary web server ready (or so I imagine) for integration: https://github.com/gtxaspec/wz_mini_hacks/pull/188

could still use:

  1. more precise updating (right now it replaces everything)
  2. pull in descriptions
  3. some knowledge of parameters that can be changed without reboot
  4. atomcam_tools style still image
  5. better protection. You can almost certainly break it by using non [A-Za-z0-9] and colons.

and more I'm sure. But it at least works (per my simple testing)

virmaior commented 2 years ago

I've updated what I've done so far in the following ways:

  1. by renaming wz_mini_web.sh to index.cgi , it will automatically be the default page at the IP address: 192.168.9.101
  2. added support for showing the hack version correctly with hackver=$(cat /opt/wz_mini/usr/bin/app.ver)
  3. added support for explanatory text on the right. match the name of the file to key.md and it will load it at that row.

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.

virmaior commented 2 years ago

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 )

virmaior commented 2 years ago

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.

virmaior commented 2 years ago

latest pull request shows an image that updates every second of the current camera view.

virmaior commented 2 years ago

@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.

endertable commented 2 years ago

@virmaior great job! I agree the only way to get browser like video will be an mjpeg server or maybe onvif?

skilau commented 2 years ago

@virmaior Absolutely! I just tried it out now, and it works great! Thank you so much for stepping up and doing this!

skilau commented 2 years ago

The new web server/pages work great!