Dotaz: Jak synchronizovat údaje mezi aplikacemi (daemon a ovládací app)

[jbb]

Dobrý den,
plánuji postavit regulaci kotelny na vhodném PLC (asi Foxboard G20). Je to malá mašinka s debianem a vhodnými vstupy/výstupy.
Kromě teploty (která se jistě nemění skokově a chvíli to počká) budu sledovat i mačkání tlačítek uživatelem. Musím si tedy napsat nějakého démonka, který bude trvale sledovat vstupy a nějak reagovat.
Na druhou stranu potřebuji systém monitorovat, respektive ho i ovlivnit z příkazové řádky (k PLC se budu připojovat ssháčkem) či z webového prohlížeče (PLC má sice vlastní pseudoapache, ale asi bych ho chtěl spíše řídit ze stránek zobrazených na serveru).
Vychází mi z toho, že tedy musím kromě démonka splichtit ještě nějaký ovládací program, který spustím z příkazovky když budu chtít juknout na stav systému či něco změnit. Nemám však jasno v tom, jak mám předávat údaje mezi těmito dvěma systémy - napadlo mne jednak přes nějaké soubory (což je takové fakt rustikální) či přes sql databázi (což se mi zdá jako s kanónem na vrabce a kdo se to má učit...).
Máte nějaký lepší nápad? Nebo byste celou věc řešili ještě nějak jinak?

Odpovědi

[Sten]

Pro váš případ by asi byly nejlepší unixové sockety (pokud to chcete fakt obecně), případně telnet (démon bude poskytovat telnetovou službu, tedy vlastně samotnou příkazovou řádku).

[Pavel Stárek]

Však nic nebrání tomu, aby prográmek (démonek), co sleduje vstupy/výstupy a dělá nějaké akce na základě jejich stavu, rovněž například otevřel UDP port (ve druhém threadu) a na něm naslouchal tvým příkazům. Tedy jde jen o to, si navrhnout vlastní protokol, který pak bude proudit těmi UDP pakety. Nevím jak to bude složité, ale napsal bych si to třeba v Pythonu, ovšem jde o to, jak se ovládají ty vstupy/výstupy (nějaké zařízení v /dev nejspíš).

[tuxmartin]

Ja prave stavim neco podobnyho na regulaci topeni. Pouzivam ATmega8, na 1-wire sbernici mam DS18B20 teplomery a do ostatnich I/O mam zapojeny ventily k radiatorum. Cely to komunikuje pres RS-232 s RouterStation.

Prijde mi to jako nejjednodussi reseni. RouterStation koupis za 1200Kc, lepsi verzi (s vyvedenym USB a 1Gbps sitovkou) za 1700Kc. Ma to 680MHz CPU, 64MB RAM, 16 MB flash. Mam tam OpenWrt linux a ridici aplikaci vlastni vyroby. Uzivatelske rozhrani jde udelat v php (stejne to bude ovladat najednou jen jeden clovek). Do USB mam pripojenou 2GB flashku na ukladani teplot, grafu a ruznych podobnych blbosti.

Je to levne a funkcni.

[tuxmartin]

Treba wifi.aspa to ma za necelych 1300Kc.

[Josef Kufner]

Stránky na serveru můžou být jen takovou proxy ke stránkám toho PLC, které budou lehce parsovatelné a jinak děsně ošklivé.

Prostě při zobrazení stránky na serveru se dotážeš PLC, jak na tom je. HTTP je dostatečně rozumný protokol na takové véci. Z příkazové řádky ti pak bude stačit prosté curl zabalené do skriptu, aby to hezky bralo parametry.

Na rootu vychází seriál o Couchy DB, myslím že by to mohla být dobrá inspirace (jen místo DB bude PLC).

[Sten]

HTTP je poměrně složité pro správnou implementaci, má spousty různých způsobů komunikace a podmíněných hlaviček. Doporučoval bych spíš velmi jednoduchý protokol SCGI a před to „položit“ nějakou proxy, která se postará o překlad do plného HTTP (nginx, Apache, lighttpd).

[Josef Kufner]

Však ono ničemu nevadí, že ta implementace bude neúplná. Stačí pár základních věcí a to ostatní buď ignorovat nebo vrátit vhodnou chybu. Podstatné je, že na otestování stačí obyčejný www prohlížeč, na odeslání i přijetí dat jsou nástroje hotové (např. curl, wget) a protokol samotný je velmi jednoduchý a nenáročný.

Pokud data samotná nebudou nějak moc složitá, což u kotelny moc nehrozí, tak jako CLI nástroj postačí párřádkový skript okolo curl nebo wgetu a základ webového rozhraní na serveru bude zhruba stejný.

A pokud by to PLC vracelo data v JSON (což je na generování velmi nenáročné na jakémkoliv HW), tak by se samotné GUI dalo napsat v Javascriptu a uložit do PLC jako prostý blob, který by se na začátku poslal klientovi (těch blobů by tam bylo několik – trocha statického HTML, nějaké to CSS a pár obrázků). Výsledkem by bylo velmi pěkné rozhraní při minimálním zatížení hardware a samotná implementace by zůstala víceméně triviální – většinu HTTP getu lze beztrestně zahodit (vlastně stačí načíst jen první řádek) a odpověď stačí uvést trochou víceméně statického textu. Webserver by potřeboval umět jen vrátit jako odpověď buď statický blob nebo vyexportovat trochy dat do JSONu. Neříkám, že taková implementace bude kdoví jak okouzlující, ale při minimu úsilí z toho lze vytřískat opravdu hodně.

[dustin]

Dobrá otázka. V knize Linux Appliance Design http://nostarch.com/appliance.htm řeší praxe znalí autoři tento požadavek pomocí knihovny Run-Time Access http://www.runtimeaccess.com/projects/rta/index.html. Démon se s touto knihovnou tváří jako instance postgresu, takže s ním mohou komunikovat jakékoliv nástroje podporující klient-server protokol postgresu, do kterých se posílají normální SQL příkazy. V konfiguraci démona se nadefinují sloupce tabulek a jejich handlery volají rovnou přiřazené funkce v c/c++. Přišlo mi to velice zajímavé a neotřelé. Ta knihovna stále žije, bohužel je pouze v C/C++, což ale nemusí vadit.

[dustin]

Obrázek http://www.runtimeaccess.com/projects/rta/GoodrtaModel.png

[dustin]

http://books.google.com/books?id=uVu0ax6C3uIC&pg=PA16&lpg=PA16&dq=library+run+time+access+rta&source=bl&ots=syNdxIrTKr&sig=CgnnuJkiC9GFROL5aOuBL7pgh0g&hl=cs&ei=3SfITcnsE8zDswazzIyXDw&sa=X&oi=book_result&ct=result&resnum=10&ved=0CGkQ6AEwCQ#v=onepage&q=library%20run%20time%20access%20rta&f=false