To reduce the chance that a bad firmware image is created and used, the
following functionality has been implemented:
1. Check md5 sums of local files in addition to downloaded files
2. Copy a backup of the original firmware, instead of removing it
3. Do not make an image unless all parts are present
4. Only output success message if the image file exists
The above fixes an issue where if a provided firmware zipfile is unable to
be read, the script continues on, generates a bad demo.bin file, and suggests
the file is good for loading into the camera. The above updates help prevent
this from occurring
Makes this page compliant with HTTP/1.1 RFC2616 and RFC7230
"HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body"
This only had LF, and when used with nodejs and axios that page would fail to be retrieved and throw a HPE_INVALID_HEADER_TOKEN error. (other pages likely need that fix, but retrieving the image was most important and most useful, I personally use it with Scrypted, which then uses this as the camera snapshot in Apple Home app)
Added -n to echo to make it clearer for myself, which removes the otherwise automatically added LF
* add ability to restrict www access / css changes
-can now use WEB_SERVER_OPTIONS to decide what parts of the web system are accessible. Set it to `WEB_SERVER_OPTIONS="cam config car jpeg"` to access everything. Remove things you don't want accessible.
-make the top part of the pages cleaner - now the image in config/cam defaults to smaller but is clickable to see it bigger.
- separate feed.js from config.js and cam.js
-add warning about RTSP fimrware to diagnostics
* add info on WEB_SERVER_OPTIONS
* Update multicam.html
track and display refresh speed.
The cron directory was being copied into the existing cron directory
during the upgrade, resulting in a doubly nested cron directory for
every upgrade.
This script was calling hi/lo updates without honoring the loop
interval. This was also calling itself recursively which could lead
to memory issues for long running cameras.
* Added auto bind feature for offline / cloud-less setup
Automatically sets bindOk=1 when WiFi settings are detected without
needing the camera to interact with the Wyze cloud. This feature
can be enabled when ENABLE_AUTO_BIND=true is set in wz_mini.conf
* Added 'WiFi Connected' audio message when QR code is valid
* Fixed the auto bind script improperly checking WiFi status
/configs isn't mounted during the init phase from the SD card and
as a result, the checks for whether bindOk=0 done by the init
script was ineffective. The script now mounts it if necessary before
checking.
* Updated autobind feature to use ENABLE_SELFHOSTED_MODE option
The feature to update the bindOk value will now use the same
`ENABLE_SELFHOSTED_MODE` option as the self-hosted iCamera patch.
This feature should only be used by advanced users in isolated
networks or when the user does not intend to use the Wyze App or
cloud services.
* Updated ENABLE_SELFHOSTED_MODE to false by default
The default should be to rely on Wyze servers. Ooops.
The return code for `false||return` is non-zero, which causes the
script to fail when the v2 checks fail.
Tested on my v3 and it seems to apply the patch properly now.
* Fixed configbackup init script not backing up files
The /configs directory isn't mounted at this point in the boot process,
as a result this backup doesn't actually work and just copies an empty
directory every time.
* Tested on T20 and added missing /configs mount in backup script
* Added NTP service to startup
A NTP service script will run a NTP client on a custom NTP server
in order to synchronize the camera's clock. This may be useful in
cases where the camera has to use a local NTP server rather than
the one hard coded in iCamera.
To use this, simply set your desired NTP server in the `NTP_SERVER`
option in `wz_mini.conf`.
* Kill timesync if a custom NTP server is used
When using a custom NTP server, the timesync service with its
hard-coded NTP servers should not be running.
