Coding coding... I've got Dwalin now able to update itself over-the-air. To get to this point, I needed to have two different inputs from the rotary encoder switch, so I changed from triggering action on the down press to triggering on the release, and distinguishing 'short' from 'long' button press. 

At this point, I've got the following pages of display info:

1. Info (primarily timing info on drawing the display since I was working on OLED i2c refresh speed)
2. Temperature (this is the default that it will go back to if no input for 20s)
3. WiFi status
4. Bluetooth status (blank at the moment)
5. Nightlight (both light sensor and NeoPixel status)
6. Firmware

On the Firmware page, a long press initiates OTA update.

For my own reference in the future, here is the memory usage as reported by ESP IDF at this point:

Total sizes:
 DRAM .data size:   11648 bytes
 DRAM .bss  size:   27648 bytes
Used static DRAM:   39296 bytes ( 141440 available, 21.7% used)
Used static IRAM:   75372 bytes (  55700 available, 57.5% used)
      Flash code:  602426 bytes
    Flash rodata:  154216 bytes
Total image size:~ 843662 bytes (.bin may be padded larger)

 I have a lingering issue that I need to dig into, which is that turning the rotary encoder encoder at a pace that's anything faster than 'pretty slow' simply drops all events. 

I think this has to do with the interplay between way I'm debouncing and with the fact that I'm leaving a delay at the end of the main loop of 10ms. I wonder if I should scale the delay based on if I'm in 'idle' or not (long delay in idle, short delay out of idle). Perhaps combine that with an interrupt on any event from the rotary encoder - so take it out of idle on the first interrupt, then leave that interrupt disabled until going back into idle.