I am just waiting for the day that there is a Wemos D1 Mini (or equivalent) available to run off 1.5v batteries. You would think that in this day and age, especially by now, this would be achievable.
I know it can be done but at the moment (as far as I can see) it requires a lot of faff. If anyone knows different please let me know --please
If you're willing to do a little bit of soldering, one option is to use a "bare ESP8266" e.g. ESP-12E which can be run on batteries with a few extra components. There are quite a few projects on various sites showing a few different approaches, and I'm currently trying to design something which can be battery or solar powered myself.
Why do you need 1.5V? Do you want to have extended battery life? Then choose either (BLE) Bluetooth Low energy (recommended for short distance) or LoRa (recommended for long distance) based low power controllers (not ESP8266 or ESP32 with LoRa).
Both work well for battery powered wireless temperature measurement. They can last for years without replacing a battery.
ESP8266 and ESP32 use WiFi for wireless communication, their power consumption is way too high.
The ESP32 also provides BLE, so it would be an option. And you have to consider the overall system, not just the power consumption of the chosen comms method.
I'm using deep sleep and hibernate modes on my ESP8266/ESP32 modules, waking up either at timed intervals or on an external input. The current is just a few microamps apart from a very short time when connecting to the server, so ideal for battery or solar+LiPo operation. The overall simplicity of WiFi, MQTT and Node-RED makes it easier for me to develop the hardware and software, which is a big consideration.
Of course there are lots of other options out there, so it's a case of looking at the pros, cons and costs to choose what's best in each circumstance.
BLE and LoRa are expensive (not to mention that I cannot find anything that will connect to a sensor like the DS18B20).
It doesn't have to be 1.5v, just capable of running on a (small) battery for at least a year.
As Molesworth says there are ways of running wireless devices using batteries (the Cricket device has shown that even if it is a bit limited at the moment) and MQTT and WiFi are an easy and relatively cheap way to get devices to communicate.
ESP32's BLE is BLE 4.2, which has weak distance and speed. The org passed the BLE 5.0 certification since Dec 2019. I did not follow which new chip they offer has BLE 5.0 now. The controller itself consumes much higher current compared to dedicated BLE chips such as Nordic nrf52840, which is a much better choice for IOT or IIOT applications.
WiFi communication current usually goes to 80mA or much igher. BLE communication current is only a few mA or higher.
I agree that BLE is very difficult to implement. You can also use MQTT and Node-RED with BLE.
It is a shame that there are not much options right now.
I think Adafruit and Sparkfun have some good offers on BLE based break boards. They are not that expensive and the battery you save will cover the cost difference between devices. It feels great that you don't need to change or worry about the battery.
But it is complicated to implement BLE compared to WiFi 
The problem with BLE is that it is a NASTY protocol! 
And, in my experience, very unreliable. Also, it is very easy to put the ESP32 into a boot loop when using BLE, I hit that again in the last few days.
If you want true low-power sensors, Zigbee is likely to be the future direction. But even with WiFi, it is possible to get good, low-power use - but you will need to get deep into the API to get the best out of it. For example, WiFi connections take a lot of power, do you need to connect to WifI all the time? Maybe not. If you are sensing temperature ever 60s, you might only need to report over WiFi when there is a significant change. So put the device into deep sleep, wake and sense, check if something needs reporting and only then connect to WiFi, send the data and go back to sleep. With a LiPO battery, you should be able to easily get at least a year of operation I would think.
If you were really clever, you could probably also include a heat-to-power feature on your board as you are close to lots of heat 
Looking in detail at device specs, the nRF52840 and similar aren't really that much different in power consumption to ESP8266/ESP32, especially if they're in sleep mode most of the time and only sending data occasionaly.
I'm using rechargeable cells (hopefully with solar charging where possible) so battery costs aren't a factor. And looking at overall power use I would think you might get 25% - 30% longer between battery changes with the BLE devices, which isn't really enough to make the extra complications worth it.
We've strayed a lot off topic for this thread though. I'm planning to write something about my hardware and software eventually, and it'll be interesting to see how low power I can make my room sensors.
One board I have used is the TTGO T-Base Esp8266
eg LILYGOÂŽ TTGO T Base ESP8266 WiFi Wireless Module 4MB Flash I2C Port MicroPython NodeMCU Compatible|Circuits| - AliExpress
as that as well as the 8266 has built in Lipo charger and connector - and has links to enable battery monitoring via A0, and to enable deep sleep mode and wake up. Must admit I've never done a long long test to see how far you can push it - but may be a good base if you wanted to solar charge it as well.
Yes BLE protocol is very nasty and hard to get it right. Good news is that it is similar to Javascript, which is event driven.
Actually, you can get super reliable connection with BLE.
We are using BLE 5.0 sensors for industrial applications. We are using Node-RED in the gateway and I may share some info in the forum if people are interested 
Here is a picture of our BLE vibration and temperature sensors running in a harsh environment.
)
Share away please 
Definitely interested in the hardware (both sensor end and node-red end) & any flows or applications you used to achieve these sensors.
TIA
On paper it may look similar. The advantages of BLE is that you can use broadcast mode, which offers the ability of sending out measurement with little power consumption.
You can send out temperature measurements constantly in an interval of a few seconds with very little power consumption.
Sorry to divert the topic. We should set up a new topic
If it is off topic, then maybe a new thread in "share your projects" category would be good.
Thanks Steve.
I will do this in two weeks.
Look forward to that
how about this for wemos d1 -
Providing battery power really isn't the hard part, Wemos themselves also make battery shields as do many other vendors. The hard part is that even with a decent LiPO, the battery consumption of an ESP8266 using WiFi is fairly high. As previously mentioned, the trick is to use the deep features of the platform to stay in low power modes as much as possible. But even so, connecting to and using WiFi requires a comparatively a lot of power.
Just seen this interesting announcement from expressif...
In particular...
One more important feature of the 802.11ax standard is the Target Wake Time (TWT), which allows the devices to sleep for an extended time-period, with assistance from an 802.11ax-capable, Wi-Fi access point. This feature in ESP32-C6 will allow our customers to build battery-operated, connected devices that can last for years on battery, while staying connected throughout.
Interesting news! I wonder why they've changed over to a RISC-V core for these new devices though. Although I've worked with RISC-V based systems before and they are pretty decent, there are more powerful and flexible options out there.
No doubt it'll be a while before we see these available cheaply and in bulk, but they could be great for low power embedded wireless modules.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks⢠or registeredŽ trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
