A highly-configurable ESP32-based Redis-watcher and TM1637-displayer, with OTA capability.

Currently driving stuff like this and this:

• ArduinoJson version 5
• avishorp's TM1637 driver
• Arduino-Redis version 2.1.1 or later

Units must be provisioned with critical datum, written to EEPROM, before they will behave correctly.

To do so, fill in the aforementioned fields appropriately, set ZERO_WATCH_PROVISIONING_MODE to 1 and upload to your ESP32 while monitoring serial (at this baud rate). There are wait-points that allow you to remove power for the unit before data is written.

Most critical of these values is hostname, which is limited to 32 characters in length and must be unique across your network. All references to HOSTNAME elsewhere in this document refer to this data.

None of the remaining fields must be longer than PSTRING_LENGTH_LIMIT bytes and ZWPROV_REDIS_PORT must always only be two bytes (sizeof(uint16_t)).

Once provisioned, the unit will halt forever, so to return it to normal behavior: unset ZERO_WATCH_PROVISIONING_MODE and all ZWPROV_* fields, rebuild and reflash. That's it!

Most of the behavior, save for the display specifications (which will one day be configurable as well), is configurable at runtime via the Redis instance the unit connects to.

Specifically, a number of fields are exposed as HOSTNAME:config:* keys for which any written (valid) value will be honored on the next refresh cycle.

There is also a control point key at HOSTNAME:config:controlPoint, a metadata getter at HOSTNAME:config:getValue and the OTA update configuration key at HOSTNAME:config:update.

Set ZWPROV_OTA_HOST when provisioning to an HTTP host visible to the unit and this will be combined with the update metadata's url component to produce the fully-qualified URL for acquisition of the update binary.

The aforementioned metadata must be written to HOSTNAME:config:update as as JSON object consisting of: url, md5, size, and otp (a "one-time password"), e.g.:

{
    "url":  "zero_watch_updates/zero_watch-v0.2.0.6.ino.bin",
    "md5":  "1a6f92066b6e3a63362c6b376fbc438d",
    "size": 924960,
    "otp": 123
}

On the next refresh cycle, this data will be picked up and acted upon. Monitor serial or Redis (depending on HOSTNAME:config:publishLogs) for logging. Upon successful update, the unit will delete HOSTNAME:config:update and reset to the new software (after a small, build-time configurable delay).

Pre-built images of recent versions are available here, but only via HTTPS so as to be unusable as ZWPROV_OTA_HOST. You should only be deploying this type of insecure OTA on a secure local or virtual private network, anyway! 😄