Closed Blimpyway closed 3 years ago
Flask debug should be off. As for changing the web port, there is more to it than just the port number, though it is not because of issues from the state changes. I'd consider patches.
Hi if this is of any help,
With flask in debug mode cpu consumed only about 10% on a pi zero, which is less than I initially noticed. When I had higher numbers was because I started manually lighttpd and the comitup service was continuously attempting to restart while port 80 was busy.
Both debug mode and port number for flask are in comitupweb.py and changing them to debug=False and port 82 seems to work fine, at least from what I was able to notice.
Yes, that should be all you need to reconfigure the web server. But, note that Comitup will still shut down the web service while CONNECTED. You could probably work around this by setting web_service to "comitup-web".
Note that there is a link to the configuration web location in dns-hotspot.conf, which implements the DHCP captive portal behavior. You may want to change that as well.
Hi, I noticed in https://github.com/davesteele/comitup/blob/master/web/comitupweb.py the Flask app is started on a fixed port 80 and with debug mode enabled.
It would be nice to have these configurable in /etc/comitup.conf for following reasons:
debug mode is heavy on a Pi Zero(W) Every few seconds cpu idle drops to less than 30% . It might interfere with other cpu intensive tasks needed even when in AP mode, e.g. a camera motion detection application (with http frontpage) may be needed to work even when not connected to another AP (Pi itself is in AP mode). Starting Flask with debug=False frees a lot of CPU cycles and some memory too (camera itself needs 128MB reserved in gpu)
regarding port number - the default policy to stop the main httpd service while comitup web page is running also limits certain ways in which comitup could be useful. So the drawback of entering a port number to access comitup page and leaving main httpd uninterrupted by the state of the underlying network could be useful. Applications which could use this facility are battery powered remote devices which by default do not connect to a router. Like a wildlife camera - I can visit it and connect with comitup in AP state to check status from my phone, then if I need to send collected pictures/videos on a cloud server I just enable wifi hotspot on same phone - commitup connects to it and triggers a script which does the transfer.
I know it would be easier with a second, usb wifi dongle but that adds significant, unnecessary drain to battery.
Thanks, the debug off option is probably simpler. The dynamics of bringing interfaces up and down while services are running might be tricky.
Regards, Cezar