Jaka koncepcja komunikacji mikrokontrolera z publicznym serwerem

Mam pytanie o to jak zrealizować komunikację między warstwą fizyczną (mikrokontrolerem esp8266), a jakimś publicznym serwerem.

Wymyśliłem sobie taki projekt (nie będę go realizował, chcę tylko poznać koncepcję jak najlepiej to zrobić)

1. Mikrokontroler ma monitorować poziom wody w beczce z deszczówką. Jeśli poziom wody się podniesie do jakiejś wartości X, to ma otworzyć zawór, by trochę wody uleciało.
2. Mikrokontroler ma co jakiś czas (np. 10 sekund) wysyłać na publiczny serwer informację o poziomie wody.
3. Z dowolnego miejsca na świecie w panelu internetowym mam mieć możliwość zmiany ustawień, np. tego jaki poziom wody utrzymywać
4. Urządzenie ma nie pobierać dużo prądu, powinno działać na jakiejś baterii

No i teraz mógłbym obrać takie podejścia:

A) mikrokontroler mierzy poziom wody i co 30 sekund wysyła pomiary na publiczny serwer z informacjami o poziomie wody. Poza tym, mikrokontroler jest zaprogramowany tak, by po przekroczeniu danego poziomu wody otworzyć zawór. Pełni on też rolę serwera i publiczny serwer może kazać mu (wysłać żądanie POST) zmienić wartość zmiennej odpowiadającej poziomowi wody, który ma utrzymywać.

B) Mikrokontroler nie zajmuje się sprawdzaniem, czy należy otworzyć zawór. Wysyła on dane o poziomie wody na serwer, a jeśli serwer stwierdzi, że należy otworzyć zawór, to każe mikrokontrolerowi (wysyła żądanie POST) otworzyć zawór.

D) Podobnie do A, tylko, że zamiast wysyłać do mikrokontrolera informację o jakiejś akcji, np. zmianie poziomu wody który ma utrzymywać, to niech mikrokontroler "pyta" się serwera (wysyła żądanie GET), czy trzeba zaktualizować ustawienia

C) Zamiast korzystać z HTTP, to korzystamy z mqtt. Ale tu nie wiem, czy jest sens. Wydaje mi się, że przy wysyłaniu raz na 10 sekund, czy nawet minutę to HTTP bardziej się sprawdzi, bo w mqtt samo ustawnowienie połączenia jest prądążerne i czasochłonne.

W skrócie:

1. jaki protokół komunikacyjny? HTTP, mqtt, czy może coś innego?

2. Gdzie ma odbywać się podejmowanie decyzji o tym co zrobić?
   ...a) mikrokontroler odczytuje i podejmuje akcje
   ...b) mikrokontroler pyta się serwera, czy po przesłanych wynikach coś zrobić
   ...c) serwer, po otrzymaniu wyników informuje mikrokontroler, że należy coś zrobić

3. Gdzie ma być możliwość zmiany ustawień?
   ...a) mikrokontroler pyta się serwera, czy ustawienia się zmieniły i jeśli tak, to je aktualizuje
   ...b) serwer mówi mikrokontrolerowi, że ustawienia się zmieniły i ma je zaktualizować
   ...c) całe ustawienia i podejmowanie decyzji jest w chmurze. Mikrokontroler wysyła pomiary, a serwer stwierdza, czy należy otworzyć zawór i jeśli tak, to każe mikrokontrolerowi to zrobić.

Które podejście wydaje wam się najlepsze? Może zaproponujecie coś innego?

B jest IMHO błędne o tyle, że dobrze byłoby uniezależnić się od warstwy prezentacyjnej, ponadto urządzenie po odcięciu łączności nie będzie spełniać swojego założenia. Beczka z deszczówką to nic krytycznego, ale widziałem już urządzenia zbudowane wg tej koncepcji, które potrafiły wytruć całe kurze fermy. IMHO jeśli już się na model w stylu B upierasz, aplikacja webowa powinna alarmować (np. via SMS) o utracie łączności.
A i D (chyba miało być C, ale niech tam ;) ) brzmią dobrze. Opcja trzecia jest IMHO o tyle lepsza, że mikropiocek nie musi w takiej sytuacji mieć znanego serwerowi adresu IP.

Ad.1 Jakkolwiek to wymyślisz. Pamiętaj jednak, że dochodzi temat przechwycenia pomiarów, oszukania serwera/urządzenia przez połączenia z zewnątrz itd. Nie czuję się tu ekspertem, ale ogólnie - pomyśl jak to od strony security dobrze ugryźć, żeby Ci byle Ziutek z curlem urządzenia nie popsuł.

ad. 2. Jestem tu oldskulowy, ale imho opcja a z możliwością zdalnej zmiany ustawień po stronie serwera będzie najsensowniejsza. Opcja c jest imho najmniej bezpieczna.

ad. 3. IMHO a i b - obojętne dla działania, ale a wydaje się być wygodniejsze z punktu widzenia infrastruktury. C - moim zdaniem to jest mało bezpieczne, z powodów w/w.

Jest jeszcze jedna opcja: całe urządzenie ma zabudowany serwer WWW i jest ono dostępne wprost. No ale to niekonieczne jest dobre i rozumiem, że poza konkursem ;)

Komunikację mozesz zrobic opc ua. To raczej mikrontroler powinien decydować o upuszczaniu wody -jak ci padnie siec to sie przeleje.

ja bym spytała o zdanie jakiegoś hydraulika (poważnie)