ESP32 IoT project update 3


In the week since my last update, I have made several modifications and additions to my project.

Here’s what my ESP32 gadget contains:

  • A ESP32 WROOM-32 Dev Kit v4
  • A BME280 I2C sensor
  • A 2.8″ TFT SPI display, 240×320, with touch interface (ILI9341 controller)
  • Two LEDs and their resistors

Here’s what this gadget can do:

  • Environment sensing
    • Every 30 seconds:
      • it will take a reading from the sensors and transmit them to adafruit IO via MQTT
      • it will update the TFT with these readings
      • it will update a transmit counter in the EEPROM (so I can keep track of how many updates succeeded since the last restart)
    • This information is available as a custom Dashboard on io.adafruit.com (I’ve made this public, check it out!).
  • Clock
    • It will get the time/date from a time server
    • It will adjust the time/date for my time zone
    • It will update the time/date on the TFT display once per second
    • It will keep a reasonably accurate time even without connection to the Internet
  • Voice control with Google Assistant and IFTTT
    • I can say “Ok Google, turn on LED” or “Ok Google, turn off LED” to my Google Home Mini (this works with any Google Assistant device or app)
    • The instruction is picked up by Google Assistant, relayed to IFTTT.
    • An app on IFTTT will parse the instruction and update my feed on adafruit.io
    • Adafruit.io will push the update to my gadget and the state of the LED is changed accordingly.
  • TFT display
    • Print arbitrary text
    • Use existing fonts, or create your own
    • Display graphics
    • Create graphics
  • Touchscreen control
    • I can tap on a specific section of the screen to turn on the LED
    • Tapping anywhere else will turn off the LED
  • Other “features”
    • On first start, the gadget will present a touchscreen calibration routine.
    • Fonts and images are stored on the ESP32 integrated SPIFS (SPI file system). No need for an SD Card.
    • Wifi status is displayed on the TFT.
    • Available RAM (heap, in bytes) is displayed on the TFT.
    • A timer watchdog will reboot the gadget if it locks up for more than 30 seconds. A lockup is determined the loop() function is not visited for that amount of time.

In making this gadget, there is so much to learn. Apart from making all these features work, and the details of the hardware, the C/C++ program, and the various cloud platforms (namely, Adafruit IO, Google Assistant and IFTTT), it is a great project for learning how to work with larger microcontrollers.

The ESP32 is great for projects that combine multiple capabilities. It has more RAM, more flash, two processing cores, Wifi and Bluetooth (I only used Wifi in this project), and even a file system. This way way beyond what an Arduino Uno can even “dream” of.

I have only scratched the surface of what is possible with this device, but I have managed to do all this using the Arduino IDE platform, and by only slightly extending my Arduino skills.

I split the sketch to multiple files to make it easier to manage.

I ran into trouble when I tested the HTTP REST API of Adafruit IO. The gadget would freeze and restart at random intervals. I suspect that the Wifi subsystem is the culprit, but have not concluded. These random reboots caused me to investigate memory leaks, the ESP32’s Wifi stack, the timer watchdog, and applying more appropriate programming methods for this project. I realise that MQTT is a far more efficient protocol, and reverted to using that. I am still investigating the issue of encryption.

I will share the code and schematics once I’m happy with the structure and features.

In the meantime, please leave your comments and thoughts below. What else would you like me to try? Do you have a theory about what might me causing the Wifi/HTTP REST reboots?

  • The overhead of HTTPS with its roundtrip handshake and encryption is very expensive for IOT projects. I have found myself using a Pi Proxy for external https coms and keeping local to http. I wonder if this is your issue with the slow/failing REST calls.

    • Using a RPi as a proxy is a good idea.

      I believe that this overhead was causing the issue, each round REST call trip was a few seconds long, way too much.

      With MQTT, the call was completed within 100-200ms.

      What software do you use on your RPi to implement the proxy? I’d love to give it a try.