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.
* Added iCamera patch option to fix intermittent network issues
This commit adds a ENABLE_ICAMERA_PATCH option to wz_mini.conf which
will patch the iCamera binary on the most recent firmware version so
that the device doesn't try bouncing the wireless interface when
iCamera is unable to reach the internet.
The iCamera program will be patched as part of the boot process when
`ENABLE_ICAMERA_PATCH=true` is set in wz_mini.conf. This patch can
be undone by setting `ENABLE_ICAMERA_PATCH=false` and then rebooting.
* Updated iCamera patch boot script to uninstall patch on failure
In case of an unsupported firmware update / downgrade, the iCamera
patch will uninstall itself and revert back to the stock executable.
* Set ENABLE_ICAMERA_PATCH default to false
The iCamera patch shouldn't be enabled unless network issues are
present. The user can toggle this option if they intend to run
the Wyze Cam on an isolated network.
* Fixed wait_for_icamera pgrep when running patched iCamera
The iCamera process may not be at /system/bin/iCamera if we run
the patched version of it.
This function is used to ensure that iCamera's running before
certain things happen. A search for just 'iCamera' should be
sufficient for this use case.
* Updated the iCamera patch feature as ENABLE_SELFHOSTED_MODE
This should make it clear this option should only be used in self-hosted
scenarios as it will break functionality with the Wyze App or other Cloud
services.
* Added iCamera patch support for v2 firmware 4.9.8.1002
This iCamera patch should handle the Wyze Cam v2 firmware 4.9.8.1002
and prevent the firmware from restarting the wireless network after
being unable to connect to the Wyze servers.
* Fixed iCamera build date check
Check was grepping for 'Build' which may include the build time
instead of build date.
* Updated readme for selfhosted iCamera patch feature
* Patched LED lights for v2 firmware
After connecting to WiFi, the blue LED status light will no longer blink.
* Changed the v2 status LED to remain on when connected
Looking at Wyze's documentation, the LED is supposed to be on when
it's connected and working. The off state from the last commit was
for the powered off state only.
