This looks awesome, I'd love to get one. Question, what's the advantage over something like the ESP32C3 and the like? Just even smaller?
8-bit AVR is an extremely clean, relatively simple instruction set that can be viably hand-coded. It's fairly straightforward to calculate the exact number of cycles your code will use, which is handy for applications requiring deterministic timing and for knowing worst-case execution time of interrupt handlers.
If the C3 instruction set is anything like the S3, I'm willing to bet it's not as straightforward.
Atmel also tends to do a better job of their documentation. I've lost count of how many confirmed errata I've reported to Espressif, and the time (and steam) I lost troubleshooting them in the first place.
I like the S3, and it's heaps powerful, but for small projects that don't need advanced peripherals like Wifi, DMA, etc. I can envision that AVR as being a fine choice.
Its not, not really anyway. The Xtensa LX7 in the S3 is very weird, though also quite fun to play with. The C3 is RISC-V
Doing asm on the AVR is beautiful, you can count clock cycles easily and then observe them on the scope.
I wrote a bit banging serial interface for an AVR once and had a mystery when I was testing it from a PC just with a basic echo. Every Nth character would be wrong. Was able to figure out a timing problem by counting clock cycles and found the bug in my code.
Was cool to see it align with what I was seeing on my oscilloscope.
With the right software, ESP32 can be incredibly low power. Like "months on 3xAA batteries" for watching a pin with the ultra low power subsystem and then occasionally waking up and making a HTTPS call over WiFi.
Bluetooth is lower energy than WiFi, but in your scenario the energy used for the radio is quite low anyway.
You can use a different resistor according to the power draw and how sensitive your volt meter is.
You'll probably need to power it up with the resistor shorted, and only remove the short once it's in sleep mode, to measure the current.
I never did a formal study to see how much of that power use was standby vs. power-on usage, how much of the standby usage was the ESP32 vs. the board/voltage regulators/pulldowns, how much of the power on usage was radio vs. e.g. all the crypto (we're doing asymmetric crypto for the TLS handshakes on batteries here, that isn't going to be cheap!) etc.
I just slapped it together and found it good enough to not care further.