Hi everyone,
I’m back after a long hiatus, still determined to see this idea through. I reworked some details, but didn’t change the overall approach.
After reading this blog article, I decided to charge my 3 AA NiMh batteries to the max, even if the combined 4.2V given by the pack is over the documented limit of 3.6V for the ESP8266 in the datasheet. I figure that someone else has been running their device at this voltage with no problem, at worst I destroy mine and lose $1. Doing away with figuring out voltage regulation saves me some headaches right now and also helps improve overall battery life.
I’m still trying to use ESPHome, because I like the convenience of it, but I might switch to programming it directly in C in the future if I’m not satisfied.
I have had some success with the following configuration which I am providing as a reference:
substitutions:
name: esphome-web-abcdef
friendly_name: test
esphome:
name: ${name}
friendly_name: ${friendly_name}
min_version: 2024.6.0
name_add_mac_suffix: false
project:
name: esphome.web
version: dev
esp8266:
board: esp01_1m
logger:
ota:
- platform: esphome
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
fast_connect: true
manual_ip:
static_ip: 192.168.1.51
gateway: 192.168.1.1
subnet: 255.255.255.0
output:
- platform: gpio
pin:
number: 2
mode: output
id: LED
deep_sleep:
id: deep_sleep_1
sleep_duration: 600s
run_duration: 10s
mqtt:
broker: 192.168.1.165
username: !secret mqtt_user
password: !secret mqtt_password
discover_ip: false
discovery: false
log_topic: null
# on_connect:
# then:
# - wait_until:
# mqtt.connected:
# - mqtt.publish:
# topic: "test-topic-publish"
# payload: !lambda |-
# return std::string("Msg: ") + std::to_string(os_random() % 10000);
# - output.turn_off: LED
# - delay: 200ms
# - deep_sleep.enter: deep_sleep_1
on_message:
- topic: test-topic-consume
qos: 0
then:
- logger.log:
format: "Received payload: %s"
args: [ 'x.c_str()' ]
- output.turn_off: LED
- delay: 50ms
- output.turn_on: LED
- delay: 50ms
- output.turn_off: LED
- delay: 50ms
- output.turn_on: LED
- delay: 50ms
- output.turn_off: LED
- delay: 50ms
- output.turn_on: LED
- delay: 50ms
- output.turn_off: LED
- delay: 50ms
- output.turn_on: LED
- delay: 50ms
- output.turn_off: LED
- deep_sleep.enter: deep_sleep_1
I am planning to further strip down the config to remove unnecessary modules such as ota: and logger:, before running another endurance test.
I also took some measurements with my Zoyi ZT219 multimeter and I have been surprised by the results. Indeed, when the device is on, it seems to be drawing on average 70mA at ~4V (I can’t see the spikes, transient currents might be much higher), but when it’s in deep sleep, it seems to be drawing 150uA. That last figure really surprised me, as the datasheet indicates 20uA, which is 7 times lower. I do have a few resistors and a capacitor on the board to allow to program the ESP8266 using serial, but I don’t know if they can explain this discrepancy. And anyway, I think most of those are required in a real circuit to avoid floating GPIOs.
Oh, and one other thing. Now, instead of waiting 20 seconds in awake mode as my test back in 2024 was doing, I am now going to deep sleep as soon as I have checked the MQTT topic. Of course, that’s a best case scenario, where the smart switch is expected to stay off, but that should give me an upper-bound for the autonomy. From measuring the time it stays awake (from the time the LED turns on), it seems to be able to boot up, connect to WiFi and read from MQTT in just over 3 seconds. That should also be a big boost to autonomy, as it is at least 6 times faster than my initial test.
I will run the endurance test next, and I’ll report back my results. I hope to make it at least to 2 weeks, using the 2500mAh Duracell AAs.
), but the idea of using a central command&control device plugged on wall-power to serve as relay for commands to the battery operated devices and use a more efficient communication method. I will definitely give it some thoughts. I’m also planning to give ZigBee a try later with a different device, but at the moment I’m focusing on the ESP-8266.
