Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Jaka koncepcja komunikacji mikrokontrolera z publicznym serwerem

30 Oct 2020 21:17 216 2
  • Level 3  
    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?
  • Moderator of Cars
    1. HTTP będzie łatwiejszy, ale MQTT jest bardziej odpowiednim protokołem do takiego celu.
    2. O ile to tylko możliwe - w mikrokontrolerze: a) i powinien móc działać w razie utraty połączenia.
    3. Jeśli ma to być energooszczędne, to mikronkontroler ma pytać serwer: a)
  • Level 20  
    devtrack wrote:
    Urządzenie ma nie pobierać dużo prądu, powinno działać na jakiejś baterii
    Zasilanie jest kluczowe - załączony ESP to ok. 75mA prądu. Zatem bateria 2000mAh wystarczy na trochę ponad dobę. Chyba nie tego oczekujesz? Jeśli chcesz bateryjnie, to układ nie może pracować jako serwer. Musi być uśpione i wybudzane okresowo. Do tego podczas transmisji pobór jest jeszcze większy, a wymiana informacji z zewnętrznym serwerem zajmuje trochę czasu (i prądu). Zamiast co 10s musisz myśleć o czasie 15min, a nawet co godzina. Można wybudzić procesor co pewien czas, dokonać pomiaru, podjąć działanie i natychmiast zasnąć (tryb deep sleep). Jeśli upłynęła godzina lub wartości wskazują na konieczność komunikacji - wysyłamy te dane przez GET lub POST przy okazji pobieramy zwrotnie informacje co do dalszego działania.