Witam.
Mam do wykonania projekt w oparciu o moduły GSM. Koncepcja jest taka: powiedzmy kilkaset modułów wysyła dane (zebrane przez jakieś sterowniki) w jedno miejsce np. na serwer. Wgląd w te dane musi odbywać się przez przeglądarkę. Działać ma to również w drugą stronę tzn, musi być możliwość wysyłania danych do sterowników (lub każdego z osobna) z poziomu przeglądarki.
Nie wiem jak ugryźć temat, zwłaszcza po stronie serwera, dlatego pomyślałem, że zwrócę się z tym na forum – być może jest ktoś w temacie. Oferta jest jaj najbardziej biznesowa, powiedziałbym bardzo intratna. Jeśli jest ktoś znający się na rzeczy, najlepiej ze Szczecina , kto chciałby podrążyć temat, to proszę o odzew.

_________________
Build:succeeded or up-to-date, 0 failed, 0 skipped

Weź przygotuj jakiś biznesplan z budżetem i zagadnieniami do zrealizowania do tego pod pachę jakiś sok jabłkowy i zadzwoń do Mirka http://www.atnel.pl/kontakt.html i idź się z nim spotkaj tym bardziej że masz nie daleko

No, ale to z kolei opóźniło by zapowiadanego od dawien dawna Yellowbooka. Apropos Yellow - gdyby już był, pewnie nie miałbym teraz problemu.

_________________
Build:succeeded or up-to-date, 0 failed, 0 skipped

Zakładasz, że komunikację zawsze inicjuje moduł, czy serwer będzie mógł sam inicjować komunikację z modułem.
Przy drugim musisz mieć na modułach publiczne IP lub mieć własny APN u operatora.

Przy dużym projekcie komunikacja z modułami powinna być całkowicie oddzielona od warstwy prezentacji. Wszystkie operacje między komunikacją a prezentacją powinny być przenoszone przez bazę danych:
- moduł wysyła / pobiera dane i informacje które są zapisywane / odczytywane do / z bazy danych
- GUI pobiera informacje do wyświetlenia z bazy danych a operacje na GUI zapisują rozkazy i zlecenia dla modułów w bazie

--
Pozdrawiam,
Robert

------------------------ [ Dodano po: 2 minutach ]

Jak masz wszystko w bazie danych to warunek prezentacji w przeglądarce robisz na zwykłym apachu i php. Bazę na początek stawiasz na mysql-u.

Odnośnie kosztów i komunikacji - mam około 25 modułów gsm i karty sim z play. W modułach wykonawczych Play na kartę rok ważności z jakąs promocją nielimitowanych sms do play a w module głównym, który wysyła również sms poza play mam formułe sms - nielimitowane sms za 7 zł na miesiąc. Wszystko odbywa się po sms. Mały serwerek jest w module głównym po wifi i dodatkowo szersza stronka, która jest aktualizowana przez moduł główny itd. Tam więc mogę wejść na moduł główny i coś zmienić i mogę wejść na stronę na serwerze zewnętrznym. Wszystko zależy ile danych i w jakim czasie.

Wydaje się rozsądniejszym rozwiązanie pierwsze, że to moduł nawiązuje komunikację z serwerem, przesyłając coś w rodzaju serialNumber w celu rozpoznania skąd dane nadchodzą.

Co do serwera. Też miałem koncepcję jakiegoś zbiornika (bazy danych) z którego korzystałby GUI i gdzie spływałyby dane, no ale tu wchodzą takie nazwy jak PHP, MySQL, a tu , jak na razie, cienko u mnie.

_________________
Build:succeeded or up-to-date, 0 failed, 0 skipped

Apache, PHP i MySQL to podstawowe elementy do robienia czegoś dostępnego poprzez przeglądarkę.
A ... jeszcze jest wersja ala microsoft - IIS i .NET i MSSQL ...

Nie wiem czy dobrze założyłem, bo mówimy tutaj o komunikacji GPRS (IP) a jeszcze istnieje możliwość wysyłania / odbierania danych przez SMSy. Ale tutaj masz limit informacji do przesłania w jednym SMSie oraz z reguły większe koszty przy SMSach przy większej ilości komunikacji.

Napisz też dokładnie do czego potrzebujesz pomocy i w jakim zakresie.

--
Pozdrawiam,
Robert

------------------------ [ Dodano po: 3 minutach ]

To co i tak będziesz Ty musiał zrobić, to przygotować dokładny opis koncepcji funkcjonalnej. Bo drobne niuanse powodują, że trzeba będzie coś całkiem inaczej zrobić, by potem nie mieć kłopotów. Daltego dobrze by od razu bazować na pełnej i jasnej informacji. Bez przygotowania tego to takich projektów nie robi się ... Chyba, że są to niekomercyjne zabawy.

Tak naprawdę, sterownik będzie miał potrzebę wysłania jednorazowo 1-5 bajtów, ale takich sytuacji może być ok 100 dziennie, do tego dochodzi możliwość podmiany oprogramowania, więc chyba GPRS.

Jakieś podstawy obsługi modemów posiadam, tzn wysyłka smsów itp. Ale w TCP/UDP jeszcze nie działałem, więc od tego miejsca "ciemność widzę" no i po stronie serwera też. Ot cały zakres pomocy.

_________________
Build:succeeded or up-to-date, 0 failed, 0 skipped

Jak będziesz korzystał z modułów ze wbudowanym stosem TCP/IP a pewnie tak, bo po co się męczyć jak już producenci to za Ciebie zrobili , to masz konieczność opanowania tylko sterowania połączeniem GPRS oraz poznania zasady wysyłania odbierania ramki IP poprzez komendę AT. A na to na początek potrzeba max. kilka godzin.

Spisana koncepcja jest potrzebna by np. wybrać czy będziesz potrzebował połączenia TCP czy UDP. Bo to zależy od założeń komunikacyjnych jakie są stawiane przez systemem. Oczywiście to będzie można potem zmienić, ale jak chcesz robić od razu porządnie a sam nie masz na tyle wiedzy by zdecydować, to musisz dla innych przygotować taki szczegółowy opis. Im bardziej dokładny, tym lepiej zostanie zaplanowana dalsza praca i tym szybciej i taniej (bo nie trzeba będzie poprawiać / zmieniać) zostanie zrobiona.
W warunkach biznesowych taki opis jest zawsze robiony i służy do oszacowania kosztów oraz czasochłonności projektu.

--
Pozdrawiam,
Robert

Tak, docelowe moduły GSM posiadają stos TCP/IP, i raczej transmisja była by po TCP, bo paczka danych musi dotrzeć w takiej postaci, jakiej została wysłana, czego UDP nie gwarantuje.

To co będzie podlegać zmianom, to oprogramowanie sterownika, tego sprzężonego z modułem GSM. Ale ta zmiana oprogramowania może pociągnąć dodanie nowych rekordów w bazie danych (np dodanie jakiegoś czujnika), dlatego aplikację na serwerze najlepiej było by zaprojektować, aby takie rekordy można było dodać. Oczywiście, takie majsterkowanie i dodawanie w późniejszym czasie, to jakby osobne zlecenie.

_________________
Build:succeeded or up-to-date, 0 failed, 0 skipped

UDP daje Ci taką samą gwarancję wykrycia przekłamania danych jak TCP. W ramce UDP występuje pole suma kontrolna do zabezpieczenia ramki (ale w przeciwieństwie do TCP jego użycie jest opcjonalne).
Wadą UDP jest bezpołączeniowość, co daje możliwość szybszego przekazania ramki z danymi, ale nie daje informacji o jej dostarczeniu (automatycznego potwierdzenia na warstwie IP). Ale i tak wszystkie współczesne systemy telemetryczne używają potwierdzeń na warstwie aplikacji, więc nie jest to większym problemem.
Innym problem związany z UDP są obostrzenia związane z komunikacją gdy mamy na drodze NATowanie.
TCP także ma wady, szczególnie jak korzystamy ze stosu TCP całkowicie niezarządzalnego a dane wrzucamy na zasadzie wyłania do modemu komendą AT z rozkazem wyślij mi to na taki a taki adres i port. I dostajemy tylko informację czy "poszło" i czy są jakieś dane zwrotne.


Zawsze jakieś zmiany w "późniejszym czasie" się pojawiają. Mnie chodziło bardziej o to byś przygotował opis koncepcji funkcjonalnej na stan obecny, ale tak być nie miał sytuacji jak na poniższych przykładach , bo najgorsze w biznesowych projektach są niedomówienia.


--
Pozdrawiam,
Robert