ESP8266 Community Forum

Hey all, I'm conjuring up a project and need some suggestions. The scenerio is such:
I want to use an ultrasonic sensor to monitor levels in a heating oil tank
1. This tank will be remote thus should be battery powered. As such it should sleep as much as it can, to save battery power.
2. All of my sensors/controls so far are simply on ESP's in station mode, acting as servers, accessable via local network with a cell phone. I'd like to follow that concept.

I'm thinking that (obviously) the sleeping ESP will not be easily accessed via wifi so....
My thoughts at this point are to have the sensor driven ESP wake and send the calculated distance from "tank bottom" to a continuously powered unit (ESP, Rpie, whatever) which can be accessed by cell phone. I've fooled with MQTT only enough to know I can get data to a broker (on a Raspberry pi), but can I access the broker as a server to place the information on an accessing browser from my android phone.
In other words can the unit used as a broker be a web server to relay information to a browser as well?
Or am I overcomplicating the issue? Thanks for any advice.

my two cents:

communicating between devices:
depending on how "remote" the sensor is, you might want to over complicate a little more using ESP-now
that will reduce the period the sensor is active from seconds (in case you use standard wifi and MQTT) to milliseconds (ESP-now) thus making you battery last longer
the following is an example, but you will find many using google
https://gitlab.com/MrDIYca/ultra-low-power-trigger-sensor-using-esp8266/-/blob/master/README.md

MQTT
while your sensors will publish data to the broker
you will also need something that will subscribe to the same broker and topics, read the data and provide a view of them (and maybe store them to a database...)
that could be a different esp8266 providing a webserver
or an application (node.js, node-red or whatever) maybe running on the same broker device

quackmore wrote:my two cents:

communicating between devices:
depending on how "remote" the sensor is, you might want to over complicate a little more using ESP-now
that will reduce the period the sensor is active from seconds (in case you use standard wifi and MQTT) to milliseconds (ESP-now) thus making you battery last longer
the following is an example, but you will find many using google
https://gitlab.com/MrDIYca/ultra-low-power-trigger-sensor-using-esp8266/-/blob/master/README.md

MQTT
while your sensors will publish data to the broker
you will also need something that will subscribe to the same broker and topics, read the data and provide a view of them (and maybe store them to a database...)
that could be a different esp8266 providing a webserver
or an application (node.js, node-red or whatever) maybe running on the same broker device

Thanks @quackmore So right now, on the bench, I have 1 ESP 8266 monitoring an HC SR04 ultrasonic sensor simply outputing results to the serial monitor via usb. (In reality this reading would only have to be done once a day at most.) If it wern't for the fact that it's ultimate location would be remoted, it could easily adapt that to a server, but with the need for saving battery, invokes the need for sleep mode.
So then (in my mind) it wakes up, sends the sensor reading to a recipient, acting as a server to be accessed by my cell phone via my home network. If I understand you correctly another second esp (acting as the recipient of said data) can't function as both a broker AND webserver at the same time And since the data transmitted would be quite simple (an integer), is there a simpler way to send that to a "holding" recipient than using MQTT? Thanks again

If I understand you correctly another second esp (acting as the recipient of said data) can't function as both a broker AND webserver at the same time And since the data transmitted would be quite simple (an integer), is there a simpler way to send that to a "holding" recipient than using MQTT?

Nope.
What you are thinking to do with MQTT it totally fine.
A sensor (on battery) wakes up, publish to the MQTT broker and goes sleep again.
Another (continuously powered unit) esp, subscribe to the same MQTT broker and topics, and makes the info avaiable through a web server.
MQTT is also fine cause, once in place, it decouples the publisher and subscriber and you can easily add more clients, so for instance you can replace the second ESP with a web application, or add an application that log the data to a database...

referring to the ESP-now I was focusing on the sensor running on battery
leave it for later... if you will ever need it