At the recommendation and example of some smart individuals (thanks to Łukasz), I took a closer look at the ESP32. In short, it's a clever device that straddles the line between logic circuits and digital processors. Logic circuits need to be designed and then implemented, while processors are expensive but versatile. The ESP32 sits right on the border of these two worlds: - It costs 30 PLN (approximately) - relatively affordable for something that can do a lot and connect to Wi-Fi. - It can be programmed using development tools.
So, I bought myself an ESP32 for a few złoty and decided to make a thermometer. Why a thermometer, you ask? Well, it's a bit of an insider joke in the IT world. What does an experienced and educated IT person do in their free time? They program a Wi-Fi thermometer, of course!
My variation had a few twists: - It needed to work outdoors and be somewhat resistant to physical conditions. - It had to handle power supply reasonably well, meaning it should be able to operate with occasional breaks in readings (let's say, during winter).
And so, about a year ago, the saga began.
Because it turned out that none of this was as easy as it seemed.
I started with the hardware: - I took a battery from a damaged 20,000mAh power bank (Greencell). - Solar panel: WaveShare Solar Panel (6V 5W). - Waveshare Solar Power Management. - DS18B20 Temperature Sensor. - ESP32. - Plastic outdoor enclosure from a hardware store.
Without much philosophy, I managed to connect everything together on the hardware side. Maybe not elegantly, so I'll share a photo to show it ;-).
However, software was a different story.
I'll try to explain the versions that worked, their pros and cons, and unexpected problems.
On the server side, there's a Raspberry Pi running a very simple PHP script to save data to disk. Munin draws the graphs.
Connecting the ESP32 to the computer turned out to be a rather complicated procedure. Since I didn't fully understand what was going on initially, I spent some time on this. Later, it turned out to be as simple as connecting a USB drive.
Version 0 - Proof of Concept (POC)
In general, it was a copy-paste of two sketches (that's what we call programs on ESP32).
Source sketch 1 - Wi-Fi client + HTML. We enter Wi-Fi credentials (only 2.4 GHz). We enter a URL (I used the GET method) like this:
Source sketch 2 - Sensor. Here's a piece of code that initializes and retrieves values.
Voila - temperature saved!
As a POC and prototype, it was incredibly quick to make. A few hours for hardware and software.
Excited that the hardware and software worked, I left it running to draw temperature graphs in Munin. And it did.
Suddenly, it stopped.
Oh, the battery had run out. It actually did run out because the panel was in a room facing north! So, it was an expected violation of the initial self-sufficiency condition. What surprised me was the speed - it lasted about a week. Mental note: I need to research power consumption for Version 1.
Because who reads anything before doing anything, right? #RTFM.
In Version 0, another problem emerged, which I didn't understand, but I also downplayed it. Every now and then, despite having a charged battery, the ESP32 stopped sending data. I attributed it to the battery running out.
In Version 1, I decided to extend battery life.
In doing so, I added another layer of ignorance about programming and ignored some errors. But more on that in a moment.
First, the goals for Version 1. "We need to reduce power consumption."
Quick Googling showed that the ESP32 has several sleep modes. I liked one of them -
esp_deep_sleep. In this mode, a low co-processor with only a few wake-up modes (timer, current event) operates. I used the timer mode, setting it to sleep for 1 minute.
I assumed this would significantly extend battery life. I didn't calculate it rigorously, but it should last a week. Quietly, in my ignorance, I assumed it would be self-sufficient along with the tiny PV panel.
Oh, how wrong I was...
Version 1 indeed slept for a minute and sent the current temperature. It lasted longer when exposed to light.
Unfortunately, the problem from Version 0 became more pronounced. At unspecified times, despite a charged battery, temperature information stopped being sent.
As part of debugging, I added a
bootcount parameter (which survived deep sleep) to try to find any patterns or regularity. It didn't help.
In my next (blind) debugging attempt, I thought it might be a range issue. I had some obscure gateway, so I replaced it with a less obscure one. That didn't help either.
Unfortunately, my debugging skills (and willingness) didn't go very deep. Here's where the ESP32 has its downsides - it's not as easy to debug as a computer where you can set clever traps. The program is simple (because there's not much memory), and
Serial.println only works when connected to a computer via cable. I wasn't willing to leave it connected for weeks. This was supposed to be a simple thermometer, not a space station recording data in a black box (computer).
Lessons learned for Version 2: - It's not the gateway disconnecting me. - Ignorance and compounding errors could be my problem.
Blind Shot #1 (it turned out, not so blind) was deep sleep. It turns out that gateways sometimes don't wake up from deep sleep. Just like that :) Additionally, it turned out that in my ignorance, I didn't turn off Wi-Fi before sleeping.
Blind Shot #2 (also not so blind) was related to Wi-Fi. Firstly, I read that Wi-Fi consumes a lot of power, so I saved some power: - I stored the previous reading in a variable that survived deep sleep and compared it to the current reading upon waking up. If there was no change, I went back to sleep without sending data.
The second issue, which I blame on my internet service provider's defenses, was the lack of DHCP response. The internet hinted at this. It was probably a form of defense because something was constantly requesting an IP address in a loop every minute. No normal device behaves like this (there's a lease time for IP addresses). I didn't bother explaining this to my ISP or debugging it. I simply entered the parameters manually, bypassing DHCP.
This version, with these improvements, currently draws temperature nicely, and the battery lasts quite a while. It sits in the garden with the PV panel facing south.
We're in the middle of winter, but it's holding up well in terms of battery life and stability. The bootcount says: 3743, which multiplied by 10 minutes (the sleep interval) gives approximately 25 days without interruption.
Am I working on another version? Not actively.
I would like to monitor voltage (charging status and battery level). Maybe I'd gather other weather-related parameters.
But for now, I'll focus on testing stability.
- Ignorance and assumptions always lead to trouble.
- Experiments are good.
- Sometimes you have to take a blind or intuitive shot because it yields results.
- Small systems are cool.
- I'm open to exploring powered and Ethernet-based systems at reasonable prices.