Połączenie IoT z aplikacją webową

2

Hej,

Zastanawiam się ostatnio jak działają różne usługi umożliwiające sterowanie SBC typu Raspberry Pi poprzez internet bez użycia stałego IP czy forwardowania portów. Jak wygląda takie połączenie? Skąd aplikacja webowa wie dokąd przesłać dane? Przykładem może być RealVNC przy połączeniu przez internet.

Jedyny pomysł na jaki wpadłem to jakaś inicjalizacja połączenia ze strony RPI do strony internetowej (czyli że facto aplikacji webowej) - tylko jak na taki request odpowiedzieć? Jak utrzymać takie połączenie przez dłuższy czas przy zmiennym IP?

0

Nie chodzi Ci czasem o DDNS?

0

Jest serwis pośredni, publiczny, do którego zgłaszają się 2 urządzenia i on je łączy albo wręcz pośredniczy w komunikacji.

0

Może pokażę na przykładzie: na RPI instaluję program. Dzięki niemu jestem w stanie połączyć się z aplikacją webową. Za pomocą programu loguję się do aplikacji webowej, dzięki czemu wchodząc w przeglądarce moje urządzenie zaczyna być widoczne.

Korzystając z przeglądarki jestem w stanie zainicjować np. połączenie zdalnego pulpitu.

Co chciałbym osiągnąć? Chciałbym postawić aplikację webową, która bez korzystania z zewnętrznego API (często płatnego) może wysłać pewne rozkazy do RPI. RPI ma je wykonać i powiadomić o rezultacie aplikację. Jak coś takiego stworzyć?

0

Co chciałbym osiągnąć? Chciałbym postawić aplikację webową, która bez korzystania z zewnętrznego API (często płatnego) może wysłać pewne rozkazy do RPI. RPI ma je wykonać i powiadomić o rezultacie aplikację. Jak coś takiego stworzyć?

Może warto zainteresować się czymś takim jak mqtt. Wtedy masz aplikację webową która łączy się do brokera MQTT który wysyła rozkaz na topic danego urządzenia. Urządzenie wykonuje rozkaz i wysyła komunikat na jakiś topic.

0

@robertwadowski: Czy broker MQTT może być wbudowany w aplikację webową? Jak miało by to wyglądać? (Przeczytałem na wikipedii o MQTT). Chodzi mi konkretnie o to -> skąd aplikacja webowa będzie wiedziała gdzie (pod jakim adresem/w jakiej sieci) wysłać dane? Najpierw RPI musi się zgłosić, prawda?

0
Burdzi0 napisał(a):

@robertwadowski: Czy broker MQTT może być wbudowany w aplikację webową? Jak miało by to wyglądać? (Przeczytałem na wikipedii o MQTT). Chodzi mi konkretnie o to -> skąd aplikacja webowa będzie wiedziała gdzie (pod jakim adresem/w jakiej sieci) wysłać dane? Najpierw RPI musi się zgłosić, prawda?

Generalnie broker jest osobną aplikacją / serwerem do którego podłączą się Twoja aplikacja webowa i RPI jako klienci. Dzięki temu zarówno aplikacja webowa jak i RPI muszą wiedzieć tylko gdzie jest broker. Topicami możesz zrealizować flow komunikacji jaki sobie zażyczysz. Nie słyszałem o wbudowanym brokerze w apkę ale myślę, że może być coś takiego (choć nie widzę sensu we wbudowaniu brokera w apkę webową). Czy RPI musi się zgłosić - zapewne tak, ale to już bardziej zależy co i jak chcesz to osiągnąć.

1
Burdzi0 napisał(a):

@robertwadowski: Czy broker MQTT może być wbudowany w aplikację webową? Jak miało by to wyglądać? (Przeczytałem na wikipedii o MQTT). Chodzi mi konkretnie o to -> skąd aplikacja webowa będzie wiedziała gdzie (pod jakim adresem/w jakiej sieci) wysłać dane? Najpierw RPI musi się zgłosić, prawda?

Generalnie tego typu połączenia działają w ten sposób, że RPI łączy się do publicznie dostępnego serwera i utrzymuje połączenie za pomocą pakietów keepalive i z tego serwera pobiera komendy/wysyła dane.

1

Na Raspberry mozesz zainstalować sobie aplikację mosquito. Tam masz i brokera i klienta MQTT.
Żeby przekazywać komunikaty do RPI możesz napisać sktypt w Pythonie który subskrybuje jakieś topic z brokera. Na tym samym Raspberry możes sobie odpalić brokera MQTT, możesz też używać zewnętrznego brokera.

Oczywiście są inne sposoby na taką komunikację. Możesz napisać aplikację w Java i komunikować się po HTTP.

1
Burdzi0 napisał(a):

Najpierw RPI musi się zgłosić, prawda?

Niekoniecznie. http://www.steves-internet-guide.com/mqtt-retained-messages-example/

0

Ja próbowałem tak: piszesz oprogramowanie typu serwer http, które trzyma klienta nie zwracając mu danych. Dostanie je dopiero, jak serwer będzie miał dla niego polecenie. Tak więc klient działa w pętli, ciągle próbując uzyskać polecenie. Albo mu się to udaje, albo dostaje timeout. To jest implementacja long polling.

Został mi z tego taki projekt: eventServer. Słabością tego projektu jest to, że można stracić polecenie. Jeżeli serwer wyda jedno po drugim, Akurat nie było to dla mnie istotne. W sumie wystarczyłoby rozszerzyć o funkcjonalność getFirstAfter(eventId). Może rzeczywiście gotowe rozwiązanie w stylu kolejki byłoby lepsze. Swoje ma z kolei taką zaletę, że można sobie to zahostować na darmowym heroku i rozszerzać endpointy w miarę potrzeb.

1 użytkowników online, w tym zalogowanych: 0, gości: 1