reklama

UDP komunikace: Raspberry <-> Arduino

SB

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #15 kdy: 20. 06. 2018, 09:54:29 »
Už to zmínil pan Prýmek: Osobně se taky domnívám, že použít IP (i jen ethernet) na spojení s Arduinem je kanónem na vrabce, je to příliš komplikovaný a paměťově a energeticky vyžraný protokol. Je-li to možné použít, dvoubodové, sériové spojení je spolehlivou, minimalistickou, lehce debugovatelnou záležitostí, na cmrndání pár bajtů sem a tam to stačí.

reklama


Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #16 kdy: 20. 06. 2018, 09:55:03 »
Souhlas. Nevim, jak presne funguje ethernet shield u Arduina, ale z principu bych se drzel UDP. TCP je oproti tomu ukrutny monstrum.
Wiznet má TCP stack v hw, takže tohle neřešíš. ENC28J60 iirc hw IP nemá, proto je lepší ho nepoužívat.

uuuuu

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #17 kdy: 20. 06. 2018, 09:55:59 »
Čau, s domácími sensory si hraju už několik let a částečně mě to živí, takže už jsem si vyzkoušel všelijaké slepé i neslepé cesty :) Kvituju záměr si hrát právě s tímhle, protože je to fakt zábava a člověk si vyzkouší širokou paletu technologií (od hw a komunikace přes backend sw až k webu).

K tvýmu dotazu: na tyhle otázky nebývá jedna správná odpověď, protože záleží na tom, 1) o co ti vlastně jde (s čím si chceš primárně hrát a s čím spíš nechceš ztrácet čas) 2) jak máš ten systém rozmyšlený, co všechno má umět a jaké má mít parametry, např. spolehlivost.

Jenom takových pár podnětů, jak to vidím já. Nic z toho není dogma, všechno si zaslouží diskusi:

  • drátové připojení tě dřív nebo později začne limitovat a prudit - zvlášť pokud je to ethernet (zaváděj si doma strukturku pro dvacet sensorů po celým baráku... nechceš). Ethernet je nejkomplikovanější a nejdražší. Když už drát, tak existují lepší alternativy (RS485, onewire, ...)
  • možností bezdrátového spojení je hodně - od nejjednoduššího 433MHz/ASK až po wifi
  • různé způsoby komunikace mají různé limity, ale u žádného z nich (kromě wifi) nechceš používat IP. Bezdrát vždycky znamená nějak chytře zakódovat zprávu do několika málo bajtů
  • další obrovskou limitací je baterka (problematika low power je příběh sám o sobě)
  • nakonec teda pravděpodobně skončíš u nějaké gatewaye, která umí víc způsobů komunikace, nějak ji sjednocuje a jednotně zpracovává
  • pokud tě to v téhle fázi už nezajímá (chceš si hrát jenom s hw), tak je fakt dobrý použít existující věci, třeba ten Domoticz, Openenergymonitor, ... je jich docela hodně
  • pokud tě zajímá i tohle, tak na téhle úrovni bych hodně doporučoval stack mqtt+NodeRed+InfluxDB+{Chronograf|Grafana} - rozjede se to snadno, funguje to skvěle, dává ti to velkou volnost a je to uživatelsky velice příjemný řešení
  • velice dobře si rozmysli strukturu dat (atributy, číselníky, sémantiku) - to je naprosto klíčová věc, rozlezlá po celém systému a když ji navrhneš blbě, dá hodně (otravné) práce ji pak změnit. Na první pokus, bez zkušenosti, se to prakticky nedá navrhnout dobře. Pokud chceš, můžu krátce napsat nějaký zkušenosti.

clanek pro root?!
takovy rozcestnik co ano, co ne.
co je kdy lepsi, co je jindy lepsi, ruzne technologie.

MarSik

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #18 kdy: 20. 06. 2018, 13:08:48 »
    • velice dobře si rozmysli strukturu dat (atributy, číselníky, sémantiku) - to je naprosto klíčová věc, rozlezlá po celém systému a když ji navrhneš blbě, dá hodně (otravné) práce ji pak změnit. Na první pokus, bez zkušenosti, se to prakticky nedá navrhnout dobře. Pokud chceš, můžu krátce napsat nějaký zkušenosti.

    Tohle by mě opravdu zajímalo. I slepé uličky :) Ten myšlenkový proces za návrhem protokolů je totiž strašně důležitou informací pro pochopení těch rozhodnutí a nikde se moc neučí ani nepopisuje.

    Re:UDP komunikace: Raspberry <-> Arduino
    « Odpověď #19 kdy: 20. 06. 2018, 13:33:17 »
    clanek pro root?!
    takovy rozcestnik co ano, co ne.
    co je kdy lepsi, co je jindy lepsi, ruzne technologie.
    Mno... Spíš než na článek by to bylo na pořádný seriál :) Ale minimálně co se týče hw nejsem profík ale nadšený amatér, takže moje zkušenosti jsou typu "X se mi nepodařilo uspokojivě rozjet, přesnou příčinu jsem nezjistil, ale když jsem přešel na Y, bylo to lusknutím prstu". Takže pokud bych se někdy dokopal k tomu, nějak ty zkušenosti shrnout, bylo by to spíš na blog než na seriál na Root, který by někdo nedejmatkopřírodo mohl brát vážně ;)

    Tohle by mě opravdu zajímalo. I slepé uličky :) Ten myšlenkový proces za návrhem protokolů je totiž strašně důležitou informací pro pochopení těch rozhodnutí a nikde se moc neučí ani nepopisuje.
    Ok, zkusím něco napsat, ale asi až odpoledne/večer.

    reklama


    Re:UDP komunikace: Raspberry <-> Arduino
    « Odpověď #20 kdy: 20. 06. 2018, 22:23:25 »
    Tohle by mě opravdu zajímalo. I slepé uličky :)
    Zkusím teda aspoň naťuknout, jak o tom uvažuju já. Pokud bude mít někdo jinou zkušenost, bude jedině super je porovnat a pokecat si o tom :) Možná vám to bude připadat triviální, jasně, však na nobelovku to není :) Budu psát ve zkratce, snad to bude srozumitelný.

    Celkem asi zjevný je, že člověk v tom modelu musí mít nějaká zařízení (konkrétní "krabička", uzel sítě) na která jsou napojeny nějaké sensory a nějaké aktuátory. Pokud zpracování dat má být nějak sjednocené, pak se dá předpokládat, že data chodí do nějakých oddělených topiků (kanálů, http endpointů, to je jedno). Pro jednoduchost budu předpokládat, že topiky jsou identifikované stringy (v MQTT to tak i je a v HTTP může být).

    Dejme tomu, že člověk má třeba krabičku měřící teplotu a vlhkost. První věc, co ho napadne, je pojmenovat si zařízení třeba "kuchyň" a data posílat na topiky "kuchyn/teplota" a "kuchyn/vlhkost" podle schematu ZARIZENI/MERENI. Na první jednoduché pokusy je to super, ale imho je to slepá ulička, protože člověk rychle narazí. Např. krabička je nějaká nestabilní a člověk si z ní chce začít posílat uptime. Ok, takže topic kuchyn/uptime. Fakt? Kuchyn ma uptime? :)

    Nebo ho napadne, ze by chtel krabicku prenaset. Jenze topic je v ni napevno. Takze s kazdym prenesenim preflashovat? Hm, dost opruz.

    Takže na základě tohodle foukání kouře do vody jsem dospěl k názoru, že nejlepší model je rozlišovat fyzické ID a logické ID a mapovat mezi nima na backendu, kde se mapování dá snadno měnit. Je to podobný jako MAC adresa <-> IP adresa.

    Takže krabička má nějaké nevýznamové ID (12345) a data posílá třeba na topiky "12345/teplota", "12345/vlhkost" a "12345/uptime" (což už dává lepší smysl). Na backendu pak chceme mapovat:

    1. meření, která se týkají krabičky, na nějaké ID krabičky (klidně to může být to samé co fyzické)
    2. ostatní měření mapovat pomocí mapy id_krabicky -> lokace

    Takže pak mám třeba mapu

    let physLocMap = {
     '12345': 'kuchyn',
    }

    a po mapování dostávám data do nových "logických" topiků takhle:

    kuchyn/temp <- 25
    kuchyn/vlhkost <- 75
    12345/uptime <- 24


    ...no a tohle je jenom taková jedna hloupost. Podobné kapitoly pak jsou ještě třeba:

    1. jak označovat vícenásobná měření (třeba krabička měří tři teploty a umí ovládat dva ventily) - buď můžu použít jenom indexy podle typu měření/aktuátoru: temp1, temp2, temp3, valve1, valve2. Anebo můžu mít nějaké "porty", které sdružují funkce - tj. port1/temp, port1/valve. To se může hodit, protože pak vím, že port1/valve zavírá tu trubku, jejíž teplota je port1/temp.

    2. Úplná věda je jak označovat význam měření. Podle mě na to žádná stříbrná kulka není. Ze začátku vám třeba přijde úplně jednoznačný označit měření jako "výkon" - dokud nezačnete měřit činný a jalový :) Pak zkusíte třeba OBIS kódy. Ale zas začnete chtít měřit něco, co nepokrývají (aktuální cena Bitcoinu ;) )

    3. chci, aby zařízení posílala s daty i nějaká metadata, nebo je budu mít autoritativně na backendu? Tj. zařízení může posílat jenom třeba "25.4,62,346" a na backendu mám záznam, že je to sensor veličin X,Y,Z. Nebo může krabička posílat něco ve stylu "{temp: 25.4,  hum: 62, uptime: 346}" Oboje má svoje pro a proti.

    4-n různé další zapeklitosti zajímavé intelektuální výzvy ;)

    Abych to moc nenatahoval, prozatím jsem dospěl k tomu, že když chce člověk model, který opravdu dobře pokrývá prakticky jakýkoli use case, chce to minimálně tyhle atributy (pro sensory, obdobně pro aktuátory):

    1. kdo - identifikace subjektu měření (jaké zařízení to naměřilo)
    2. koho - objekt měření ("koho měřím")
    3. co - veličina, kterou měřím
    4. naměřená hodnota
    5. jednotka

    ...přičemž minimálně 1 a 2 neškodí mít hierarchizovatelné (např. kdo="wifi_nody:esp_1", koho="mistnosti:kuchyn"). Když cokoli z 1-5 chybí, existuje use-case, kterej je pak opruz pokrývat.

    ---
    Takže tak no, jako taková malá ilustrace, že se fakt vyplatí nad tím datovým modelem trochu předem podumat, než to tam člověk nafláká :) Snad to někomu pro nějakou inspiraci poslouží...

    Ale zas na druhou stranu se s tím taky člověk nesmí úplně mořit, protože úplně stopro dobře to imho snad ani vymyslet nejde a vždycky člověk až v praxi narazí na use case, se kterým nepočítal. Takže nepřemýšlet zas moc dlouho, aby se člověk vůbec k tomu hraní si s tím dostal :)

    rpi_ard

    Re:UDP komunikace: Raspberry <-> Arduino
    « Odpověď #21 kdy: 20. 06. 2018, 22:45:45 »
    došel jsem něčemu podobnému:
    "krabička" má svoje ID, v mém případě to je přímo "IP" adresa (viz jak komunikovat, tento topic :) ), další atributy: UDP port in/out, název
    každá "krabička" má I/O porty, v mém případě to je "PIN", každý PIN může nabývat různé (i více zároveň) vlastností: "tlačítko", "časovač" .. u měření ještě nejsem  ... to vše mám v databázi a v oddělených tabulkách -> můžu do nekonečna rozšiřovat počet zařízení a portů ..

    když chci něco zapnout, tak UDP zpráva jde na konkrétní IP a port, ve zprávě je zakódováno, co se má provést, např.: že přílaz na je na PIN_1 a má se nastavit hodnota "zapnuto", "kranička" zprávu parsuje a dle toho provede akci, jako potvrzení komunikace odešle stejnou zprávu na centrální uzel -> zpráva je zpracována, do databáze se zapíše stav komunikace, v případě úspěšně doručené zprávy akce končí, pokud do nějakého času nepřijde zpráva z ARD, příkaz s odesláním se opakuje
     


    v

    Re:UDP komunikace: Raspberry <-> Arduino
    « Odpověď #22 kdy: 20. 06. 2018, 22:50:16 »
    doporučuju juknout na normu IEC61850 resp. komunikační protokoly, které definuje (hlavně ten na bázi MMS), modelování/pojmenovávání řeší dost do hloubky, pro účely normálních smrtelníků by to byl overkill, ale jako inspirace je může být zajímavé

    Re:UDP komunikace: Raspberry <-> Arduino
    « Odpověď #23 kdy: 20. 06. 2018, 23:27:34 »
    doporučuju juknout na normu IEC61850 resp. komunikační protokoly, které definuje (hlavně ten na bázi MMS), modelování/pojmenovávání řeší dost do hloubky, pro účely normálních smrtelníků by to byl overkill, ale jako inspirace je může být zajímavé
    Přiznám se, že od té doby, co jsem relativně detailně studoval EEBus jsem nad těmahle meganormama zlomil hůl. Člověk se týden vůbec snaží zorientovat v té záplavě dokumentů, druhej týden studuje ten dokument, kterej se jedinej týká toho, o co mu fakt jde, následně zjistí, že pro jeho účely je použitelná jenom jedna tabulka s dvaceti položkama a ta ještě stejně nepokrývá všechno, co by potřeboval, takže by si beztak musel zavést nějaké uživatelské atributy, což je složitý jak autobus :)

    Jo, kdybysme se bavili o něčem konkrétním, někdo řekl "nevím, jak popsat měření elektřiny" a někdo doporučil "hele, koukni se na tuhle tabulku na straně 24, to je hezkej výčet", tak to jo. Ale jinak do toho fakt nejdu, je to pro tohle naše domácí hraní si nesmyslný overkill...

    ehmmm

    Re:UDP komunikace: Raspberry <-> Arduino
    « Odpověď #24 kdy: 21. 06. 2018, 08:41:40 »
    když chci něco zapnout, tak UDP zpráva jde na konkrétní IP a port, ve zprávě je zakódováno, co se má provést, např.: že přílaz na je na PIN_1 a má se nastavit hodnota "zapnuto", "kranička" zprávu parsuje a dle toho provede akci, jako potvrzení komunikace odešle stejnou zprávu na centrální uzel -> zpráva je zpracována, do databáze se zapíše stav komunikace, v případě úspěšně doručené zprávy akce končí, pokud do nějakého času nepřijde zpráva z ARD, příkaz s odesláním se opakuje

    No vidis, zadna veda. Jenom drobnost k "jako potvrzení komunikace odešle stejnou zprávu na centrální uzel". Silne doporucuji mit v tom paketu alespon jeden bit na rozliseni, co je dotaz a co je odpoved. Obe strany samozrejme vedi, kdo je master a kdo slave. Ale kdyz to budes debugovat nebo odposlouchavat nejakym nastrojem, tak to zjednodusi zivot. Nebudes muset patrat, kdo mel v tu chvili jakou ip adresu, atd...

    dustin

    Re:UDP komunikace: Raspberry <-> Arduino
    « Odpověď #25 kdy: 21. 06. 2018, 10:42:24 »
    Pánové, moc díky za tyhle praktické zkušenosti

    MarSik

    Re:UDP komunikace: Raspberry <-> Arduino
    « Odpověď #26 kdy: 21. 06. 2018, 11:42:20 »
    Jo, kdybysme se bavili o něčem konkrétním, někdo řekl "nevím, jak popsat měření elektřiny" a někdo doporučil "hele, koukni se na tuhle tabulku na straně 24, to je hezkej výčet", tak to jo. Ale jinak do toho fakt nejdu, je to pro tohle naše domácí hraní si nesmyslný overkill...

    Tento způsob použití popisuje třeba aplikační část M-bus standardu (EN 13757-3) včetně rádiové části (EN 13757-4). Jenže na tom se mi nelíbí, že hodně plýtvají prostorem právě na jednotky a použité kódování zprávy. Posílají typ přístroje, typ dat (uint8, uint16, ...), jednotku, hodnotu - ale těch možných a rozumných kombinací zase tolik není. Na druhou stranu, umí až cca 250B dlouhé zprávy.

    Co se kódování topiců týče, předpokládám, že nepřenášíte celé stringy vzduchem (MQTT-SN třeba umí předdefinované). ISM má v některých pásmech omezení na duty-cycle (1%, 0,1%), takže zprávy musí být časově co nejkratší. wM-bus to třeba řeší rychlostí přenosu (100kbps), ale tím zase trpí (záměrně) dosah. Také tam není žádná oprava chyb.

    Je to hodně o potřebách v konkrétním nasazení, proto jsem rád za každý zdroj inspirace.

    Já třeba v tuto chvíli uvažuji nad protokolem se stavovým automatem (něco jako dělá třeba OpenGL). Tj typ a modifikátory se nastaví jednou a pak se už jen posílají data, případně změny. Ale musím vyzkoušet, jak se s tím bude pracovat. Cílem je úzkopásmový rádiový protokol s krátkými pakety, odolností proti chybám (CRC, FEC, interleaving, vyvážení 0/1) a tím i delším dosahem a menší spotřebou.

    Re:UDP komunikace: Raspberry <-> Arduino
    « Odpověď #27 kdy: 21. 06. 2018, 11:57:11 »
    Co se kódování topiců týče, předpokládám, že nepřenášíte celé stringy vzduchem (MQTT-SN třeba umí předdefinované).
    Přesně tak, na rádiu používám MQTT-SN a předdefinované topiky. Posílat topic jako string v každé zprávě by bylo zoufalé plýtvání a někdy by to ani moc nešlo (např. http://zkemble.github.io/nRF905/n_r_f905_8h.html#a8fb4745dd928b0021fd7ad49b558cfe2 )

    ISM má v některých pásmech omezení na duty-cycle (1%, 0,1%), takže zprávy musí být časově co nejkratší.
    I kvůli baterce se hodí být co nejúspornější...

    proto jsem rád za každý zdroj inspirace.
    Já taky. Je hezké zjistit, že někdo nezávisle přišel na stejné řešení a ještě lepší je vidět, že vymyslel něco lepčího :)

    Já třeba v tuto chvíli uvažuji nad protokolem se stavovým automatem (něco jako dělá třeba OpenGL). Tj typ a modifikátory se nastaví jednou a pak se už jen posílají data, případně změny. Ale musím vyzkoušet, jak se s tím bude pracovat. Cílem je úzkopásmový rádiový protokol s krátkými pakety, odolností proti chybám (CRC, FEC, interleaving, vyvážení 0/1) a tím i delším dosahem a menší spotřebou.
    To je rozhodně inspirativní nápad. Akorát to chce hodně dobře pohlídat, aby se ta informace neztratila, páč to by se to pak celý nepěkně rozbilo...

    Já používám něco podobného, ale v opačném směru - pro konfiguraci sensorů, tj. od gatewaye k sensoru. Používám retained mqtt zprávy, takže sensor má "zadarmo" persistentní storage konfigurace a pracuje se s tím nádherně.

    Např. teď jsem do jednoho sensoru implementoval možnost nastavení periody vysílání úplně jednoduše:
    Kód: [Vybrat]
    $ mosquitto_pub -t 'sensors/NODE_ID/cfg/meas_freq' -m 180 -r
    To samý používám i pro persistenci těch překládacích map phys->log pro NodeRed (existuje sice node-red-contrib-persist, ale proč nepoužít stejnej mechanismus a neusnadnit si život? :) )

    Re:UDP komunikace: Raspberry <-> Arduino
    « Odpověď #28 kdy: 21. 06. 2018, 12:11:13 »
    Přesně tak, na rádiu používám MQTT-SN a předdefinované topiky.
    Respektive teda ne předdefinvoané, ale registrované (zprávy REGISTER a REGACK). Předdefinované jsou trochu těžkopádné, protože musí být hardwired na obou koncích...

    BTW, když jsme u toho, jakou máte zkušenost s mqtt-sn brokery? Já ještě pořád používám RSMB (fork https://github.com/MichalFoksa/rsmb.git s podporou forwarder encapsulation, která je na gatewayi superpraktická) a funguje to, ale moc spokojenej s ním teda nejsem, občas má tendenci se dostat do stavů, ze kterých se neumí vymotat i když by mohl...

    v

    Re:UDP komunikace: Raspberry <-> Arduino
    « Odpověď #29 kdy: 21. 06. 2018, 12:38:48 »
    To je rozhodně inspirativní nápad. Akorát to chce hodně dobře pohlídat, aby se ta informace neztratila, páč to by se to pak celý nepěkně rozbilo...
    klasické řešení je v každé zprávě přenášet čítač a na straně přijímače kontrola jestli v každé následující zprávě roste o jedničku (modulo), minimum je jeden bit, použije se tolik bitů kolik si můžete dovolit

     

    reklama