Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Europejski lider sprzedaży techniki i elektroniki.
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Program na Androida do wysyłania i odbierania SMSów dla modułów IoT i nie tylko

perfi 27 Wrz 2016 19:36 5037 8
  • Cel projektu
    Umożliwienie odbierania i wysyłania wiadomości SMS modułom/projektom z dostępem do sieci komputerowej.

    Motywacja
    Czasami chcąc rozwiązać jeden problem napotykamy na inny. Ja chciałem załączać/wyłączać urządzenie za pomocą telefonu komórkowego oraz co jakiś czas być informowany o stanie tego urządzenie. Dodatkowo postanowiłem poznać czym jest i jak działa IoT na przykładzie układu ESP8266 (tu zainteresowała mnie możliwość programowania w Pythonie). Tu od razu pojawiło się pytanie: jak można wysyłać SMS za pomocą ESP8266? W grę wchodziła komunikacja z modemem poprzez UART (komendy AT) lub zlecenie wysyłki jakiemuś urządzeniu dostępnym w sieci komputerowej. Jako, że w szufladzie mam stary telefon z Androidem postanowiłem go użyć. Tak powstał program o nazwie REST SMS Gateway, który jest dostępny tutaj.

    Sposób użycia
    Po zainstalowaniu i uruchomieniu aplikacji należy nacisnąć przycisk "Start". Po chwili pojawi się adres IP na którym działa serwer. Pod tym adresem dostępna jest dokumentacja (opisująca dostępne funkcje REST). Aby wysłać lub przejrzeć dostępne wiadomości należy skorzystać z jednego z wielu wspieranych linków, które to postaram się wam przybliżyć. Dla ułatwienia posłużę się poleceniem curl oraz kodem w Pythonie (wersja 3). Zakładam, że telefon jest podłączony do wifi i ma adres http://192.168.1.103:8080 (przy braku połączeniu do wifi adres to http://127.0.0.1:8080,, portu na razie nie można zmienić).

    Proszę zwrócić, że każdy link kończy się znakiem /. W przypadku jego braku program zwróci błąd http 404.

    - wysyłanie smsa o treści test na numer 987654321

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Kod: python
    Zaloguj się, aby zobaczyć kod


    - przeglądanie listy wątków/konwersacji

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Kod: python
    Zaloguj się, aby zobaczyć kod


    - przeglądanie wiadomości w wybranym wątku

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Kod: python
    Zaloguj się, aby zobaczyć kod


    - przeglądanie wszystkich wiadomości

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Kod: python
    Zaloguj się, aby zobaczyć kod


    - przeglądanie treści wybranej wiadomości

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Kod: python
    Zaloguj się, aby zobaczyć kod


    W przypadku zwracania listy elementów (tzn. wątków i wiadomość) domyślnie prezentowane jest 10 najnowszych wpisów. Aby to zmienić można skorzystać z parametrów limit i offset, np.: curl -X "GET" "http://192.168.1.103:8080/v1/thread/?offset=4&limit=20"

    Podsumowanie
    Mimo, że jest to apka na telefon, a nie typowa konstrukcja w dziale DIY, mam nadzieję, że program pozwoli waszym projektom wysyłać i odbierać SMSy. Mi teraz pozostaje czekać na ESP8266 z Chin :) Wszelkie komentarze mile widziane!


    Fajne!
  • #2 28 Wrz 2016 11:29
    coolrob
    Poziom 14  

    10-15 lat temu to się robiło przez port szeregowy telefonu (w moim przypadku Ericsson T10s) i nie trzeba było żadnej aplikacji na telefon ;)

  • #3 28 Wrz 2016 17:49
    sp3uqw
    Poziom 11  

    A gdzie umieszczasz kody Pythona które pokazałeś? Na ESP8266? W jaki sposób?

  • #4 28 Wrz 2016 17:57
    JacekCz
    Poziom 33  

    W moim rozumieniu REST wysyłanie komunikatu to POST w nie PUT.
    Wysyłana jest zawsze nowa wiadomość (nie ma możliwości update już wysłanej), wg mnie POST.
    Mówiąc językiem baz danych, w PUT się wysyła klucz pierwotny danych (jak już są to zmień) a POST nie (są zawsze nowe). Nie wiem czy to jasno wyraziłem.

    (oczywiście przyjmując filozofię, że realizujemy standard REST a nie "bo tak się w naszym garażu napisało")
    EDIT: REST (ZTCW??? proszę o sprostowanie) nie jest twardym standardem RFC,OSI,ISO czy podobnej klasy, ale jest zgodnie rozumiany (common sense) i mało budzi wątpliwości.

    Jak już się doktoryzuję, lepiej widziane są argumenty mniej więcej tak:
    http://192.168.1.103:8080/v1/thread/offset/4/limit=20
    ale tu nie będę się kłócił, nie dotyka to istoty

    Co to tego GET z listą, teoria GET (w REST) jest taka, że może być cachowany / optymalizowany, bo i tak by przyszły tożsamościowe dane.
    Listowanie "od najnowszych" nie spełnia tego warunku.

    Nie mam gotowego pomysłu jak rozwikłąć zagadnienie, luźne przykłady z "dużych" komputerów:
    większość forów pozwala na wysłanie kumplowi URL bo nie zajdą jakies cuda z przemieszczeniem (przykład pozytywny)
    wysłanie kumplowi adresu portalu bo na głównej stronie jest coś ciekawego, nie ma sensu (przykład negatywny)


    PS. myślę że czasy idą, że aplikacje / komponenty wdrożeń mogą być w DIY

  • #5 28 Wrz 2016 22:08
    perfi
    Poziom 13  

    sp3uqw napisał:
    A gdzie umieszczasz kody Pythona które pokazałeś? Na ESP8266? W jaki sposób?


    Podany kod był używany do testów z kompa. Planowałem go zastosować jak przyjdzie ESP8266, niestety według dokumentacji HTTPConnection nie jest wpierane, tylko "czysty" socket.

    Dodano po 1 [godziny] 1 [minuty]:

    JacekCz napisał:
    W moim rozumieniu REST wysyłanie komunikatu to POST w nie PUT.


    Problem ten jest dobrze opisany tutaj. Jedni mówi tak, inny inaczej :/

    JacekCz napisał:
    REST (ZTCW??? proszę o sprostowanie) nie jest twardym standardem RFC,OSI,ISO czy podobnej klasy, ale jest zgodnie rozumiany (common sense) i mało budzi wątpliwości.

    Mi o standardach też nic nie wiadomo, choć może udział W3C byłby tu mile widziany.

    JacekCz napisał:
    Jak już się doktoryzuję, lepiej widziane są argumenty mniej więcej tak:
    http://192.168.1.103:8080/v1/thread/offset/4/limit=20
    ale tu nie będę się kłócił, nie dotyka to istoty

    Przyznam, że więcej czasu poświeciłem na to zagadnienie niż na POST vs PUT. Rozwiązań tu jest masa, np: /thread/<od>/<do>/ /thread/<od>/<limit>/, /thread/<page>, /thread/?all=true, itd... Użycie limit i offset po ? wydawało mi się najbardziej naturalne.. Niestety, jak słusznie zauważyłeś, powoduje to problem z przesunięciem, czyli ten sam link może zwracać (po wprowadzeniu zmian) różne wyniki. Bardzo chciałbym poznać jakieś zgrabne rozwiązanie.

    JacekCz napisał:
    Co to tego GET z listą, teoria GET (w REST) jest taka, że może być cachowany

    Tu zauważyłeś ciekawy problem. IMO dane odczytane z telefonów raczej nie powinny być przechowywane przez jakikolwiek cache, czy to proxy czy przeglądarki.

    JacekCz napisał:
    PS. myślę że czasy idą, że aplikacje / komponenty wdrożeń mogą być w DIY

    Podoba mi się :)

  • #6 29 Wrz 2016 17:25
    JacekCz
    Poziom 33  

    perfi napisał:


    JacekCz napisał:
    W moim rozumieniu REST wysyłanie komunikatu to POST w nie PUT.


    Problem ten jest dobrze opisany tutaj. Jedni mówi tak, inny inaczej :/


    No tak, długa dyskusja i sensowne argumenty z kilku stron, dobrze uzasadnione. Wobec braku twardego standardu to zrozumiałe ....

    perfi napisał:


    JacekCz napisał:
    Co to tego GET z listą, teoria GET (w REST) jest taka, że może być cachowany

    Tu zauważyłeś ciekawy problem. IMO dane odczytane z telefonów raczej nie powinny być przechowywane przez jakikolwiek cache, czy to proxy czy przeglądarki.


    A jak czujników (klientów) będzie pińcet, i tzreba będzie tłok w hhtp rozłądować? Kot wie ...
    Oczywiście temat cachowania wrzucam akademicko


    Inne pytanie: Jak tworzyłeś ten zdecydowanie integracyjny projekt na "małe" środowiska, trafiałeś może na biblioteki / protokoły / wdrożenia ZeroMQ, MQTT? Kibicuję temu, choć jak na razie "platonicznie".
    O tyle moja wiara (w wydajność*) ) jest uzasadniona, że wykonałem realne wdrożenie rozproszone, jak wielu programistów użyło by by http rest json, to użyłem binarnego protokołu Apache Thrift - mam rewelacyjne wrażenia. Tak leciutko to chodzi na Androidach, że aż miło. żadnego parsowania, sklejania stringów, brak nagłówków ...

    *) logika request-response (RPC) jest inna niż publish-subscribe

  • #7 29 Wrz 2016 22:01
    perfi
    Poziom 13  

    JacekCz napisał:
    A jak czujników (klientów) będzie pińcet, i tzreba będzie tłok w hhtp rozłądować?

    Jak czujników będzie dużo to ich stanu raczej nie będę wysyłał przez SMSy. Wydaje mi się że ograniczona liczba znaków i długi czas wysyłki średnio się do tego nadaje.

    JacekCz napisał:
    trafiałeś może na biblioteki / protokoły / wdrożenia ZeroMQ, MQTT? ... binarnego protokołu Apache Thrift

    Niestety nie miałem przyjemności używać ZeroMQ, MQTT czy Apache Thrift. Do tej pory używałem UART. Dzięki za nazwy projektów. Z chęcią zobaczą co one potrafią. Binarna transmisja danych może być "lecitka", choć nie wiem jak będzie wyglądała ich implementacja na ESP8266. Trudne to może być?

  • #8 30 Wrz 2016 04:12
    JacekCz
    Poziom 33  

    Thrift pokazuje co może gdy funkcja C przez sieć musi wykonać RPC w Javie (ma innym hoście). Schemat danych w specyficznym opinie jest generowany na deklaracje kas w językach jakie kto chce. Więc obie nie liczą numerków bajtów, tylko używają klas z dziedziny problemu,
    Z meta języka opisu klas generuję sobie klasy C#, Javy, C++, Pythona i w oparciu o te klasy i funkcje RPC sobie wywołujemy zdalne wywołania w zupełnie innych językach., Możemy mieć klasę dla błędu (funkcja zwraca jakiś szerszy opisany błąd) itd ...Dobry, aktywnie żyjąycy projekt, z liderem jest łączność.

    Konkurencyjny ProtoBuf ma podobne klasy, potrafi klasy z C# przełożyć na C++jakiejś architektury, czy klasę Javy, ale mało robi aby te klasy ruszyły w wędrówkę. (RPC jest półoficjalnym dodatkiem).

    MQTT i ZeroMQ w ogóle nie zajmują się treścią co do danych , ale efektywnie nimi ganiają w pomiędzy brokerów. Spotkałem że ProtoBufem sklejał pakiet logiczny a ZeroMQ to transmitowało
    ZeroMQ na konkretnym hoście nie ma swojego brokera (którego byś mógł przez setup wgrać) to tylko kawałek biblioteki, jak zlinkuijesz twój programik stanie się węzłem przekazywania.
    Podobno bardzo agresywnie optymalizowane (w C) : jak bufor odbioru jest, to po co zajmować bufor nadawania, więc nadajemy z miejsca odbioru itd... Wydaje się bardzo oszczędnie to zaplanowane właśnie na maluchy. Zdecydowanie ZeroMQ nie ma nic z ryby, ale wędkę chwalą.
    ZeroMQ jest biblioteką zdecydowanie niskiego poziomu, nie ma gotowców, ale te gotowce się dopiero robi.

  • #9 03 Paź 2016 23:29
    perfi
    Poziom 13  

    Hej

    Napisałem małą biblioteczkę w Pythonie ułatwiającą komunikację z programem na telefonie (rsgv1.txt). W pliku jest klasa RESTSMSGateway która opakowuje całą komunikację przez sieć i w prosty sposób pozwala na przeglądanie danych na telefonie (wątków i wiadomości) oraz wysyłanie SMSów.

    Dla ułatwienia zrozumienia zamieściłem też dwa przykładowe skrypty. Skrypt test-run_functions.txt pokazuje jak przeglądać dane na telefonie za pomocą następujących metod:
    getThreadAll() - pobierz listę wszystkich wątków
    getThreadById(thread_id) - pobierz listę SMSów w wątku o numerze thread_id
    getSMSAll() - pobierz listę najnowszych SMSów
    getSMSById(sms_id) - pobierz treść SMS o numerze sms_id

    Pierwsza i trzecia funkcja wspierają paginację. Oto przykłady:
    getThreadAll(20, 10) - pobierz listę 20 wątków od 10 wątku
    getSMSAll(100, 0) - pobierz 100 najnowszych smsów, niczego nie pomijaj

    Aby uruchomić skrypt należy (poza posiadaniem Pythona 3 :) ) uruchomić program z ip jako parametr:

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Kolejny przykład to test-send_messages.txt. Pozwala on wysłać SMS do osób podanych w pliku:
    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Plik z wiadomościami to plik tekstowy w którym każda linia zawiera nr telefonu oraz treść wiadomości. Jako separatora pól użyłem znak potoku/pałki, czyli |. A oto przykład:

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Mam nadzieję, że pozwoli to czytelnikom przetestować program. A może ktoś pokusi się o napisanie jakiegoś bota? :)

    PS
    Rozszerzenie py jest niedozwolone, dlatego zmieniłem je na txt. Przed testami należy przywrócić rozszerzenie py.

    rsgv1.txt Download (2.01 kB) test-run_f...ctions.txt Download (700 bajtów) test-send_...ssages.txt Download (566 bajtów)

TME logo Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
TME Logo