An ESP32 clock


Lately I’ve been trying to design and produce a Wifi/Bluetooth connected clock. The ESP32 is a good candidate, since it has two cores and a low power co-processor, making multitasking quite achievable.

The build process

The microcontroller code uses the esp-idf build system. These are additional steps that:

  • Recompile protobufs if needed. These are used over MQTT
  • Generate SPIFFS image
  • Add SSL certificates to the binary post-build
  • Embed NVS data (e.g. an unique identifier per device)
  • Compress images using Heatshrink. A library with very low memory and run-time footprint. I’ve used in many projects and it’s proven itself reliable. I introduced its use in TomTom back when working on SmartWatches. The compression ratio is not as good as gzip, but it reduces the firmware file size by ~ 45% in my tests. The SPIFFS image compression ratio is much better, probably because for now only a small portion of is is used.

Multitasking

The chosen display is a basic 64x32 LED matrix, that needs to be constantly refreshed. One of the cores is dedicated exclusively to drawing the graphics and animations. Will experiment with adding low priority tasks to the core to see how it affects the display handling.

The second core of the ESP32 will need to handle

  • The main logic The operation is conceptually spit into applets. These are different classes each with separate responsibilities. E.g.
    • Fetch the weather forecast
    • Show the time from different timezones
    • Integrate with home alarm providers (e.g. YALE) and show the alarm status
    • Show countdown/stopwatch
    • Alexa and Google Home integration (TBD)
  • Long operating tasks (using my library HeavyTask)
    • Used by applets for long tasks, such as fetching the weather. This allows other applets to run and update information on the display concurrently
  • HTTP server (to be replaced by an MQTT client)

Server

The server is written in GO and is composed of:

  • MQTT broker
  • MQTT client, that handles all communication with microcontrollers
  • HTTP(S) to monitor and interact with the microcontrollers
  • Database to be yet defined and added

Updating the clients remotely

Clients will be told to update through MQTT. In order to ensure reliable updates in the field, two firmware partitions will be used:

  • A smaller partition has a trimmed down firmware, that only connects to the saved WiFi and flashes the main software partition.
  • On reboot, the new firmware is loaded and run. In case of severe bugs causing the firmware to be un-runnable, after a set times of retries the bootloader reverts to the stripped down firmware, that will send the error to the server and wait for a new firmware.
  • Crashlogs are dumped to flash and uploaded on next successful connection.
  • With this approach it’s much more difficult to brick a device.
  • The firmware is sent from the server as a compressed file. This also has extra headers that encode the compression method and parameters, MD5 of the uncompressed image and signature.

Enclosure

Currently 3D printed with a tempered glass to protect the screen. The design needs to be improved to allow moulding of the enclosure for mid-scale production.

Certifications

It uses an FCC and CE certified board. Potentially needs an unintentional radiator certification. The display is also FCC/CE certified.

Where it’s at

DONE:

  • 62x32 large RGB display
  • Can show multiple timezones
  • Stopwatch/Timer
  • Weather forecast
  • Shows one word a day if a foreign language of choice with translation (default off)
  • YALE alarm integration

TODO:

  • Alexa / Google Home / Siri integration
  • Calendar integration (Google/…)
  • Bluetooth phone notifications (basic Android app done)
  • Sign/Encrypt firmware and flash storage
  • Server dashboard to manage devices
  • Greater configurability of UI. Theming?