What concept of microcontroller communication with a public server

I have a question about how to implement communication between the physical layer (esp8266 microcontroller) and some public server.

I came up with a project like this (I won't be implementing it, I just want to get an idea of how best to do it)
1. the microcontroller is supposed to monitor the water level in the rain barrel. If the water level rises to some X value, it is supposed to open a valve to let some water escape.
2) The microcontroller will periodically (e.g. 10 seconds) send information about the water level to a public server.
3. it should be possible to change the settings, e.g. what water level to maintain, from anywhere in the world via a web panel.
4. the device should not consume a lot of power, it should work on some kind of battery

And now I could take these approaches:

A) the microcontroller measures the water level and sends the measurements every 30 seconds to a public server with the water level information. Also, the microcontroller is programmed to open a valve when the water level is above a given level. It also acts as a server and the public server can tell it (send a POST request) to change the value of a variable corresponding to the water level it is supposed to maintain.

B) The microcontroller is not involved in checking whether to open the valve. It sends the water level data to the server, and if the server determines that the valve should be opened, it tells the microcontroller (sends a POST request) to open the valve.

D) Similar to A, only instead of sending the microcontroller information about some action, such as a change in the water level it is supposed to maintain, have the microcontroller "ask" the server (send a GET request) if the settings need to be updated

C) Instead of using HTTP, we use mqtt. But here I don't know if there is a point. It seems to me that if you send once every 10 seconds or even a minute, then HTTP will work better, because with mqtt just setting up the connection is laborious and time-consuming.


In brief:
1. which communication protocol? HTTP, mqtt or something else?

2. where should the decision making about what to do take place?
...a) the microcontroller reads and takes action
...b) the microcontroller asks the server whether to do something after the results have been transmitted
...c) the server, after receiving the results, tells the microcontroller to do something

3) where should the settings be changed?
...a) the microcontroller asks the server if the settings have changed and, if so, updates them
...b) the server tells the microcontroller that the settings have changed and to update them
...c) all settings and decision making is in the cloud. The microcontroller sends measurements and the server determines if a valve should be opened and, if so, tells the microcontroller to do so.

Which approach seems best to you? Perhaps you can suggest something else?

1. HTTP will be easier, but MQTT is a more suitable protocol for such a purpose.
2. as far as possible - in the microcontroller: a) and it should be able to work if the connection is lost.
3. if it is to be energy efficient, the microcontroller should ask the server: a)

devtrack wrote:

The device is not supposed to draw a lot of current, it should run on some sort of battery

Power supply is key - the switched-on ESP is about 75mA of current. So a 2000mAh battery is enough for a little over 24 hours. I don't suppose that's what you expect? If you want battery power, the chip can't work as a server. It has to be put to sleep and woken up periodically. On top of that, the consumption is even higher during transmission, and it takes some time (and power) to exchange information with an external server. Instead of every 10s you have to think about a time of 15min or even every hour. You can wake up the processor every so often, take a measurement, take an action and immediately go to sleep (deep sleep mode). If an hour has elapsed or the values indicate a need for communication - send this data via GET or POST while taking the feedback for further action.