sundayman pisze:

>> Kiedyś potrzebowałem podobnej rzeczy, też do urządzenia z RS232. Idealnie
>> pasowały mi komputerki z firmy acmesystems.it -- płyta komputera (65x65mm),
>> płyta modemu GPRS, wszystko razem w aluminiowej obudowe. Teraz tam mają
>> jescze fajniejsze diwajsy, nawet ta najmiejsza "Arietta" to pociągnie,
>> rzecz jasna po uzupełnieniu donglem. To takie małe, że łatwo wbudować
>> w co się chce. Można użyć routera z gniazdkiem USB na modem -- zwykle
>> mają port rs232 (choć w środku, trzeba się do niego dobrać), a soft dość
>> łatwo wymienić na własny.
>
> Tak mi przyszło, że właściwie najlepiej by było, żeby całość była mało
> zależna od konkretnego modemu. Czyli, żeby jak najbardziej uniwersalnie
> obsługiwać toto - znaczy jakimiś komendami AT, obciążając tym zadaniem
> moje urządzenie.

Modemy GSM podążają we wcześniej opisanym kierunku, te najłatwiej dostępne
i najtańsze stały się właściwie routerami. W przypadku portu RS232 można
przyjąć, że takich modemów nie ma i nie będzie. A nawet nie było -- jeśli
co do joty przyjąć postawione warunki.

> Bo i tak muszę program robić, a w razie konieczności wymiany modemu na
> inny, byłby mniejszy kłopot. Da się tak ?
> Znaczy - obsłużyć całe zestawienie połączenia itp ?

Jeśli dopiero robi się urządzenie, to zaprojektowanie gdziazda USB do
modemu nie jest ekscentrycznym pomysłem, tak się robi. Nie jest wielkim
wyzwaniem, by obsługiwane były wszystkie modemy (przynajmniej te z
dłuuugiej listy zalecanych przez producenta).

Port szeregowy w urządzeniu, to oldskulowe rozwiązanie, trzeba sobie
z tego zdawać sprawę. Jeśli chce się ten sentyment podtrzymać, warto
też uszanować oldskulowe konwencje. O tym za chwilę.

>> W sensie hard- czy software? To może być zwykły hostong serwera WWW.
>> Wcześniej pisałem o kilkudziesięciu linijkach perla, ale da się to
>> też tak zrobić, by urządzenia wpychały swoje raporty do serwera http,
>> i tak też były one później po obróbce udostępniane.
>
> Miałem na myśli soft. Znaczy - od strony jakiegoś hostingu gdzieś
> tam na serwerze.
> Moje doświadczenie na razie kończy się na postawieniu strony na
> Joomli, stąd pytanie.

Zabawne, ale nawet mając zerowe umiejętności webmasterskie, zdarzenia
raportowane przez stacje telemetryczne mogą być skutecznie zapisywane
na serwerze. Jeśli urządzenie próbuje wysłać swoje dane i robi to
odwołując się do adresu http://log.sundayman.com/raport?k=12,p=23,z=7
to w logach serwera znajdzie się zapis, że 404, że takiej strony nie
ma, a zaraz za nim wszystkie przekazane dane.

Nie namawiam nikogo, by system projektował właśnie w ten sposób, ale
porządne rozwiązania wcale nie są o wiele bardziej skomplikowane.

>> Jeszcze jedno mi przysło do głowy. Po policzeniu ilości przesyłanych
>> danych może się okazać, że wystarczą SMS-y z jakiejś telemetrycznej
>> taryfy. Do tego wystarczy modem OEM, który przeważnie ma RS232,
>> a słanie wiadomości komendami AT jest proste, łatwo tej sztuczki
>> nauczyć swoje urządzenie. Jeśli nie SMS, to są modemy ze stosem TCP/IP
>> (i z tym pythonem), z którymi też się przez port szeregowy pogada.
>> Ale to jednak sporo roboty by było z napisaniem całego systemu, nie
>> wiem czy warto.
>
> Na razie wolałbym gotowe, zewnętrzne urządzenie. I z uwagi na problemy
> prawno-formalne, i chyba tak łatwiej mi będzie.
>
> Jak już będę miał jakieś doświadczenie, wtedy pomyślę dalej.
> A co do ilości danych ; normalny nadzór nad urządzeniem, to przesłanie
> może kilkudziesięciu - kilkuset bajtów.
>
> Przesłanie pamięci zdarzeń - to chyba około 32 KB.
>
> Chyba wolałbym to robić nie SMS, a "normalną" transmisją. Bo wtedy
> tak samo będzie wyglądała komunikacja "on site", po podłączeniu się
> kabelkiem do laptopa.

Miałem wielokrotnie do czynienia z urządzeniami, które komunikowały się
ze światem przez port szeregowy. Takie ustrojstwo żyje własnym życiem,
a po podłączeniu czegoś do RS232 można sobie z nim pogadać o tym, jak mu
ostatnio szło. Zawsze było to tak, że podłącza się standardowy program
terminala, na którym pojawaia się wtedy zachęta w rodzaju "Sundayman
Advanced Devices, please type 'help'". Wtedy można prostymi żołnierskimi
poleceniami przeczytanymi w tym helpie pogadać z diwajsem, skonfigurować,
wydać mu polecenia, odpytać z raportów. Gdy ten sprzęt projektowano,
takie rozmowy zawsze odbywały się in situ, bo nikt nawet nie myślał
o komunikacji przez sieć.

Ja dostosowując się do zwyczaju pisałem skrypty, które zastępowały
człowieka przy rozmowie, a potem to czego się dowiedziały, słały gdzieś
przez sieć. Programy takie jak minicom (a wcześniej Telix pod DOS) są
znakomitym wsparciem do takich działań. Jeszcze raz chcę podkreślić
jaka tu konwencja -- o wszystkim decyduje zewnętrzny komputer. Pomysł,
by samo urządzenie decydowało *kiedy* chce gadać i jak, nie jest zbyt
szczęśliwy. W szczególności jest w konflikcie z działaniami in situ
przy udziale czynnika ludzkiego, który nie lubi oczekiwać na nic,
raczej nie będzie zachwycony, gdy trafi na sytuację kiedy urządzenie
nawet nie zamierza wysyłać w tym czasie żadnych "komend AT". Więc
zanim jeszcze nie zrobiło się zbyt dalekich kroków, gdy projetk nie
jest ukończony, warto obstalować sobie konsultacje z kimś, kto ma
doświadczenie i pojęcie o takich rzeczach.

--
Jarek