Jak skonfigurować komunikację między ESP8266 a Raspberry Pi?

Witam
Mam do wykonania prostą automatykę domową opartą na ESP8266 i Raspberry. Zasada działania ma być taka, że poprzez np. interfejs webowy, który działa na Raspberry mam mieć możliwość zmiany stanu poszczególnych wyjść na ESP8266. Ma też to działać w drugą stronę, czyli np. podanie stanu wysokiego na wejście jednego modułu esp8266 powinno zmienić stan wyjścia innego ESP, ale przechodząc przez serwer na Raspberry.
Gdybym nie musiał używać serwera, to wykorzystałbym komunikację UDP między dwoma modułami ESP, a tak to nie mam za bardzo pojęcia jak to wykonać. Czy mógłbym prosić o podanie wskazówek jak wykonać taką komunikację i jakich protokołów użyć? Programować będzie w Arduino IDE

W pierwszej kolejności na układach ESP8266 musisz wgrać soft, który odczyta lub zapisze stan wejść/wyjść. Przyklad podany na http://blog.nettigo.pl/2015/esp8266/
Nastepnie na Raspberry piszesz aplikację, ktora cyklicznie lub po odświeżeniu przez użytkownika wysyla zapytania do ESP8266 o stan wejść lub zmienia stan wyjść. W podanym linku komunikacja odbywa się w protokole HTTP ale to jest kwestia wuboru i oprogramowania.
Głównym zadaniem jest napisanie na Raspberry serwera HTTP, który będzie pośredniczył między użytkownikami a modułami. Można użyć modułów CGI, lub samemu napisać własny serwer, który będzie analizował protokół HTTP. Wszystko jest kwestią czy masz do dysozycji jakiś OS czy sam piszesz bez OS.

Serwer HTTP nie jest potrzebny. Zaimplementuj w ESP Websocket. Strona HTML5 wczytana do przeglądarki może zachowywać się jak klasyczna aplikacja. Czyli asynchronicznie odbierać komunikaty o zmianie wejść i wysyłać rozkazy do zmiany wyjść.

TvWidget napisał:

Serwer HTTP nie jest potrzebny. Zaimplementuj w ESP Websocket. Strona HTML5 wczytana do przeglądarki może zachowywać się jak klasyczna aplikacja. Czyli asynchronicznie odbierać komunikaty o zmianie wejść i wysyłać rozkazy do zmiany wyjść.

Czyli zamiast raspberry w roli serwera HTTP wykorzystać jeden moduł ESP, który będzie "zarządzał" pozostałymi ?

Napisałeś, że ma wszytko przechodzić przez RPi. Wskazałem jak to zrobić bez serwera HTTP. Wystarczy, że przygotujesz stronę HTML5+kod w JS. Bedzie to aplikacja napisana w JS, której kod przeznaczony jest do wykonywania się w przeglądarce np. przeglądarce w RPi.

Obsługa bez serwera HTTP jest uciążliwa do wykonania z banalnego powodu wszystkie asynchroniczne zapytania, które będą wykonywane w tle przez JS będą blokowane przez przeglądarkę jeżeli będą wychodzić na adres inny niż została pobrana strona. W ramach testów mojego serwera HTTP wykonałem małą stronę z asynchroniczną komunikacją. Uruchomiłem tę stronę bezpośrednio z pliku na kompie i mimo obecności w sieci serwera z danymi, które były odpytywane przez stronę asynchronicznie informacje nie były pobierane z "zewnętrznego" serwera. W JS jest to sposób zabezpieczenia przed przeprowadzaniem ataków za pośrednictwem HTTP (kod strony z serwera A, a dane i może złośliwy kod z serwera B, o którym użytkownik strony nic nie wie).

Witam. Ja bym zrobił tak jak opisał to autor pierwszego postu. Może być UDP, albo TCP. Przecież zamiast wysłać komunikaty z ESP do ESP możesz wysłać do Raspberry. Jedyna różnica to adres IP. Dalej możesz przesłać informację dokąd Ci pasuje. HTML to nie było coś do opisu treści strony, przesłyanej później przez np. http?

przemwach napisał:

Obsługa bez serwera HTTP jest uciążliwa do wykonania z banalnego powodu wszystkie asynchroniczne zapytania

W przypadku Websocket nie ma zapytań. Jest tylko połączenie.

przemwach napisał:

będą blokowane przez przeglądarkę jeżeli będą wychodzić na adres inny niż została pobrana strona.

Tak robi przeglądarka Egde. Ta w RPi chyba pozwoli pobrać dane z innej domeny.

Kolega "mpier" uprościł moje rozumowanie odnośnie komunikacji między modułami. Rozwiązanie dobre i proste peryferyjne moduły to ESP wysyłają cyklicznie stan wejść do Raspberry a Raspberry w odpowiedzi może wysyłać stan wyjść do modułów i wówczas odpowiedź jest potwierdzeniem otrzymania komunikatu. To wyczystko na UDP aby było prosto. Co nie zwalnia cię od napisania programów do wysyłania i odbierania danych po UDP.
Teraz na Raspberry musisz jakoś zaprezentować te dane albo ekran i kolejna aplikacja, albo mały serwer np. HTTP z prostą stroną do wizualizacji danych.
Tak HTTP to język opisu strony, dziś używany również do przesyłu danych (dane z bazy danych są umieszczane wewnątrz HTTP i prezentowane na stronie www) tak to dziś działa.

Sprawa wygląda tak. Mogę wykorzystać jakiś serwer na licencji open source.
Dostałem również wskazówki, że do projektu mogę wykorzystać serwer openhub, który będzie działać na Raspberry i zrobić komunikację po MQTT. Jaki byłby schemat działania takiego rozwiązania?

Można tak:
- ESP wysyła cyklicznie stan wejść do Raspberry , gdzie jest on zapisywany do pliku,
- gdy Raspberry dostanie żądanie o stronę www wysyła ją z aktualnymi stanami wejść odczytanymi z pliku,
- jeżeli Raspberry dostanie informację o zmianie stanie wyjść zapisuje tę informację do pliku,
- Raspberry po otrzymaniu stanu wejść od ESP odpowiada w ramach potwierdzenia stanem wyjść odczytanymi z pliku.

P.S.
Do odczytu zmiennych, danych zewnętrznych w HTTP stosuje się skrypty PHP lub CGI, w zależności czym dysponuje serwer.

przemwach napisał:

P.S.
Do odczytu zmiennych, danych zewnętrznych w HTTP stosuje się skrypty PHP lub CGI, w zależności czym dysponuje serwer.

Ani PHP nie wyklucza CGI, ani PHP z CGI nie wyczerpują całości możliwości. Na ile obserwuję rynek, to CGI jest martwe doooobre kilka lat.

Np bardzo fajnie się to robi w Pythonie, który mam mocną pozycję na Raspberry. W odróżnieniu o PHP jest dobrym językiem ogólnego zastosowania.

przemwach napisał:

Tak HTTP to język opisu strony, dziś używany również do przesyłu danych (dane z bazy danych są umieszczane wewnątrz HTTP i prezentowane na stronie www) tak to dziś działa.

HTTP to nie jest, i nigdy nie był językiem opisu strony. Pomyliłeś z HTML.

Cos tam Ci dzwoni, ale nie wiesz gdzie .... przyjmijmy roboczo, że masz zły dzień.

JacekCz napisał: Ani PHP nie wyklucza CGI, ani PHP z CGI nie wyczerpują całości możliwości. Na ile obserwuję rynek, to CGI jest martwe doooobre kilka lat.

Podałem tylko możliwe przykłady. Dróg do celu jest wiele, wybór należy do Ciebie.

JacekCz napisał: HTTP to nie jest, i nigdy nie był językiem opisu strony. Pomyliłeś z HTML.

Mój błąd, masz rację. Pewnie z rozpędu. HTTP to protokół przesyłania dokumentów hipertekstowych.
Dzięki za uwagi. [/syntax]