Połączenie IoT z aplikacją webową

Odpowiedz Nowy wątek
2018-09-14 23:38
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?


ale ten IP zmienia się podczas działania, a nie np. podczas restartu i jest przypisywany przez DHCP? - WeiXiao 2018-09-14 23:41
@WeiXiao: Miałem na myśli restart. Usługi zapamiętują urządzenia i potrafią nawiązać połączenie z inicjatywy aplikacji webowej - Burdzi0 2018-09-14 23:52

Pozostało 580 znaków

2018-09-14 23:59
0

Nie chodzi Ci czasem o DDNS?


01010100 01110101 01110100 01100001 01101010 00100000 01101110 01101001 01100101 00100000 01101101 01100001 00100000 01101110 01101001 01100011 00100000 01100011 01101001 01100101 01101011 01100001 01110111 01100101 01100111 01101111 00101110 00100000 01001001 01100011 00100000 01110011 01110100 01101111 01101110 01110100 00101110
edytowany 2x, ostatnio: stivens, 2018-09-15 00:08

Pozostało 580 znaków

2018-09-15 00:42
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.

Pozostało 580 znaków

2018-09-15 09:19
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ć?


Pozostało 580 znaków

2018-09-15 10:05
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.

edytowany 1x, ostatnio: robertwadowski, 2018-09-15 10:07

Pozostało 580 znaków

2018-09-15 12:37
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?


Pozostało 580 znaków

2018-09-15 13:10
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ąć.

edytowany 2x, ostatnio: robertwadowski, 2018-09-15 13:53

Pozostało 580 znaków

2018-09-15 13:44
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.

Pozostało 580 znaków

2018-09-29 18:28
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.

edytowany 1x, ostatnio: Michal74, 2018-09-29 20:25

Pozostało 580 znaków

2018-09-29 19:50
1
Burdzi0 napisał(a):

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

Niekoniecznie. http://www.steves-internet-gu[...]tt-retained-messages-example/


Szacuje się, że w Polsce brakuje 50 tys. programistów

Pozostało 580 znaków

2018-10-02 20:05
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.


Przeważnie ignoruję niezarejestrowanych użytkowników.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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