Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: rpi_ard 18. 06. 2018, 18:08:05
-
Ahoj,
pro radost realizuju projekt automatizace, mám raspberry (RPI) + Arduino (ARD).
- na RPI běží apache, postgress, web2py framwork + další vlastní skripty
- základní princip komunikace je, že ARD poslouchá na UDP portu, příchozí zprávu parsuje a nějak se zachová
- nějak tak tuším, že UDP není ideální, proto mám "mechanismus" potvrzování zpráv z ARD, případně neúspěchu se příkaz opakuje
- to znamená, že na RPI je také otevřen UDP port pro poslouchání zpráv z ARD
Problém-1: RPI má otevřený port, ten ale občas "spadne", cron se stará o otevření portu pokud není otevřen
Dotaz-1: proč nebo co způsobí, že se port na RPI uzavře?
Dotaz-2: jak byste koncepčně změnili logiku komunikace?
Za jakékoliv další tipy a nasměřování budu rád.
-
Opendds
-
Opendds
díky za tip, nedohledal jsem, zda Opendds lze nasadit na arduino (jednoduše)
- mně jde především o komunikaci RPI + ARD
- porovnání různých protokolů pro komunikace RPI - PC, kdyby někoho zajímalo
http://cgweb1.northumbria.ac.uk/SubjectAreaResources/KF7046/papers/review/iot/ck16.pdf
-
Jsou i lightweight dds knihovny.
-
Tak i pro Arduino existuje třeba MQTT.
-
Problém-1: RPI má otevřený port, ten ale občas "spadne", cron se stará o otevření portu pokud není otevřen
Dotaz-1: proč nebo co způsobí, že se port na RPI uzavře?
Co znamená "RPI má otevřený port", "ten spadne" a "cron se stará o otevření portu"???! Složí se aplikace otevídající si daný port k poslouchání a cron ji nahazuje? Pak zjišťujte, proč se ona aplikace skládá.
-
jak máš na tom arduinu řešeno připojení k sítí? Levné ethernet rozhraní s ENC28j60 a softwarový TCP IP stack, Wiznet w5100 (oficiální ethernet shield) nebo podobný s hardwarovou implementací TCP/IP stacku nebo wifi s ESP8266 nebo něčím podobným co má vlastní procesor a dost výkonu? jde o to kolik prostředků arduina musíš obětovat na komunikaci a tcp/ip.
Otázka taky je, jak moc realtime tu komunikaci potřebuješ, ale myslím že pro většinu případů by bylo TCP lepší volba. aspoň nemusíš řešit když se nějaký packet ztratí. třeba u ovládání světel je ti celkem jedno jestli světlo se rozsvítí za 50 nebo 100ms od stisku vypínače.
jako protokol vyšší vrstvy, jak navrhoval kolega mqtt je možná varianta, nebo máš vlastní protokol? případně by se dal použít http nebo modbus tcp. ale záleží na návrhu architektury komunikace, jestli je to spíše push dat (ze senzorů, vstupů) na server nebo server se periodicky dotazuje na stav a ovládá výstupy.
-
otevřený port = python skript + import socket, v logu mám jen znovu otevření portu, nevím jak zaznamenat ukončení skriptu
- koukám, že to mám asi zbytečně komplikovaně, protože:
1. skript-1 zjistí kolik je zařízení v databázi pro ovládání (nějaké ARD na LAN)
2. skript-1 spoustí přes subprocess nové skripty, co skript to specifický port pro naslouchání UDP
metoda: subprocess.Popen(cmd, shell=True, stdout=None, close_fds=True)
- jak tohle zjednodušit?
HW: jeden ethernet shield je Wiznet w5100, ten vykazuje nejstabilnější chování, ostatní teď nevím, ale dopíšu
- realtime odezvu opravdu nepotřebuju, 1000ms je v pohodě
- vlastní protokoly nemám: snažím se použít jednotlivé komponenty a poskládat je dohromady, ale zase nechci použít celý projekt
Logika komunikace
- přes web na RPI je zadán požadavek: třeba rozsviť, RPI pošle data do ARD, který čeká na zprávu, ARD zprávu parsuje, nastaví třeba high na pinu 6 a odpoví = potvrdí, že zprávu dostal ... a tak dokola
- data nyní žádná nesbírám
Z komentářů mi vychází
- použít ethernet shield s HW podporou TCP/IP
- použít TCP protokol
-
Tak až si to nebudete dělat pro radost, ale aby to fungovalo, zkuste naskočit na nějaký běžící proces, kde tohle všechno už mají vyřešené.
Ono mít všechna arduina domácí automatizace na ethernetu asi není to pravé řešení.
Většinou se použije jiný přenos a k tomu gateway do ethernetu nebo na seriový port.
Mrkněte třeba na Domoticz.com jako centrální server a s ním kompatibilní síť sensorů Mysesnsors.org či ESPeasy.
S touhle kombinaci jsem třeba zhruba za víkend udělal autonomní regulátory el. podlahového topení se vzdáleným nastavením regulované teploty, typu regulované veličiny ( podlaha, místnost ), případně časové schema průběhu těchto teplot.
Se zpětným reportem spotřeby jednotlivých místností a průběhem teplot.
-
Pokud tam máš wiznet tak TCP není nejmenší problém. Nejlíp mi z toho vychází použít na arduinu http server. jsou na to knihovny není potřeba nic složitého vymýšlet. Na straně rPi to bude triviální, wget pošleš request na arduino, které HTTP 200 potvrdí vykonání příkazu, případně může vrátit aktuální stav výstupů po provedení příkazů.
pokud tech arduin je víc a je mezi nimi složitější logika, pak bych možná zauvažoval nad nasazením MQTT.
-
i s enc28j60 a softwarovým TCP/IP stackem se dá udělat funkční http server, ale nezbude ti potom moc volné RAM paměti pro zbytek aplikace, tam už opravdu budeš počítat každých pár bytů. ukázka třeba tady http://www.tuxgraphics.org/electronics/200611/embedded-webserver.shtml
-
Z komentářů mi vychází
- použít ethernet shield s HW podporou TCP/IP
- použít TCP protokol
To je, obávám se, zcela chybný závěr. UDP má v embedded prostředí mnoho výhod oproti TCP, zvlášť při pravidelné výměně malého množství dat mezi subsystémy, které jsou nezávislé a mohou se např. často náhodně resetovat (napájení, SW chyba a vyvolání RST watchdogem, ...).
To, že ti to nefunguje, není problém UDP, ale tvého řešení.
-
Z komentářů mi vychází
- použít ethernet shield s HW podporou TCP/IP
- použít TCP protokol
To je, obávám se, zcela chybný závěr. UDP má v embedded prostředí mnoho výhod oproti TCP, zvlášť při pravidelné výměně malého množství dat mezi subsystémy, které jsou nezávislé a mohou se např. často náhodně resetovat (napájení, SW chyba a vyvolání RST watchdogem, ...).
To, že ti to nefunguje, není problém UDP, ale tvého řešení.
A ještě jedna výhoda - důležitá hlavněš u systémů s omezenými zdroji - UDP stack není vůbec náročný paměťově, atd všechny související věci.
-
Č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.
-
To je, obávám se, zcela chybný závěr. UDP má v embedded prostředí mnoho výhod oproti TCP, zvlášť při pravidelné výměně malého množství dat mezi subsystémy, které jsou nezávislé a mohou se např. často náhodně resetovat (napájení, SW chyba a vyvolání RST watchdogem, ...).
To, že ti to nefunguje, není problém UDP, ale tvého řešení.
A ještě jedna výhoda - důležitá hlavněš u systémů s omezenými zdroji - UDP stack není vůbec náročný paměťově, atd všechny související věci.
Souhlas. Nevim, jak presne funguje ethernet shield u Arduina, ale z principu bych se drzel UDP. TCP je oproti tomu ukrutny monstrum.
Muze se ale stat, ze samotny shield vypocetne prevysuje Arduino (neco jako GSM moduly SIM800L za cca 100 Kc, ktere jsou o nekolik trid chytrejsi nez samotne Arduino za 40 Kc) a pak by asi slo o TCP uvazovat.
Ale na TCP v techto aplikacich mi jeste vadi, ze je clovek vic zavisly na knihovne, nez kdyz pouzije "hole" UDP. TCP ti sice zaruci, ze kdyz uz data dojdou, tak dojdou ve spravnem poradi. Ale uz se hur zjistuje, jestli uz to dorazilo, jestli to vubec jeste dorazi, kdy to dorazi, kdy bude dalsi pokus, hromady paketu proleti jenom kvuli navazani spojeni. Tohle vsechno si dokazu sam pomerne snadno osetrit v UDP, nez spolehat na nejakou knihovnu. Preci jenom vime, jak to s knihovnami pro Arduino je.
-
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čí.
-
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.
-
Č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.
-
- 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.
-
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.
-
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 :)
-
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
-
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é
-
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...
-
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...
-
Pánové, moc díky za tyhle praktické zkušenosti
-
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.
-
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:
$ 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? :) )
-
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...
-
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
-
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
Jasně, jenže to už právě přináší netriviální režii: potvrzování doručení nebo restart komunikace, případně i potřebu nějaké persistence...
U těch jednoduchých bateriových sensorů se většinou vyplatí použít co nejjednodušší komunikaci, ideálně i přijmout nějaké ty ztráty atd. Komplexní komunikační protokol nestojí za to, aby to místo roku vydrželo na baterku měsíc...
-
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
Jasně, jenže to už právě přináší netriviální režii: potvrzování doručení nebo restart komunikace, případně i potřebu nějaké persistence...
U těch jednoduchých bateriových sensorů se většinou vyplatí použít co nejjednodušší komunikaci, ideálně i přijmout nějaké ty ztráty atd. Komplexní komunikační protokol nestojí za to, aby to místo roku vydrželo na baterku měsíc...
záleží čeho potřebujete dosáhnout (to je jasné) - jaké spolehlivosti
co jste napsal vyznělo jako obava o nedetekování ztráty zpráv(y), bez nějaké režie toho nejde dosáhnout (taky jasné), určitě ne před příchodem kvantové komunikace, no a ten uvedený postup nepotřebuje ani potvrzování ani znovunavázání komunikace a persistenci taky ne
-
záleží čeho potřebujete dosáhnout (to je jasné) - jaké spolehlivosti
co jste napsal vyznělo jako obava o nedetekování ztráty zpráv(y)
No nejlepší je to prostě nepotřebovat. Jakmile zavedu stavový protokol, tak to začnu potřebovat. A pak mám i ty další důsledky. Takže jsem chtěl říct, že stojí za zvážení, jestli to, kvůli čemu jsem zaváděl ten stavový protokol, stojí za ty důsledky.
no a ten uvedený postup nepotřebuje ani potvrzování ani znovunavázání komunikace a persistenci taky ne
A jak by to mělo fungovat? Mám atributy A,B,C, v první zprávě pošlu A, ve druhé B (ta se ztratí) a ve třetí posílám C. Přijímač přijme třetí zprávu, zdetekuje, že mu druhá chybí - a udělá co? Musí mě o tom informovat. A ten informační paket se taky může ztratit... At least once delivery se přece bez nějakého druhu potvrzování implementovat nedá.
-
A jak by to mělo fungovat? Mám atributy A,B,C, v první zprávě pošlu A, ve druhé B (ta se ztratí) a ve třetí posílám C. Přijímač přijme třetí zprávu, zdetekuje, že mu druhá chybí - a udělá co? Musí mě o tom informovat. A ten informační paket se taky může ztratit... At least once delivery se přece bez nějakého druhu potvrzování implementovat nedá.
ten postup má jenom umožnit detekci ztráty zprávy, nic víc, reakce bude odpovídat tomu co vlastně potřebujete
dá se to brát tak, že pokud se něco ztratilo, tak vám může chybět nějaká zajímavá informace o stavu zařízení např. že někdo stiskl tlačítko "vypni topení", reagovat se dá různě, třeba dotazem na všechny stavy
-
Upřesnil bych tu stavovost :) Stav je duležitý jen v rámci jedné zprávy, pro minimalizaci meta-informací.
Něco jako:
TEPLOTA, (implicitně sensor 1), uint8_t, 25, S2, 30, VLHKOST, (uint8_t poděděno), (implicitně S1), 80, S2, 75
Umožní to mít gateway, která nemusí rozumět samotným datům, jen to zkonvertuje do něčeho složitějšího a předá dál. Je to trošku podobné právě M-bus aplikačnímu bloku, kde ale ty typy a jednotky musí být pořád dokola.
-
A jak by to mělo fungovat? Mám atributy A,B,C, v první zprávě pošlu A, ve druhé B (ta se ztratí) a ve třetí posílám C. Přijímač přijme třetí zprávu, zdetekuje, že mu druhá chybí - a udělá co? Musí mě o tom informovat. A ten informační paket se taky může ztratit... At least once delivery se přece bez nějakého druhu potvrzování implementovat nedá.
ten postup má jenom umožnit detekci ztráty zprávy, nic víc, reakce bude odpovídat tomu co vlastně potřebujete
dá se to brát tak, že pokud se něco ztratilo, tak vám může chybět nějaká zajímavá informace o stavu zařízení např. že někdo stiskl tlačítko "vypni topení", reagovat se dá různě, třeba dotazem na všechny stavy
Já bych to viděl spíše tak, že "message counter" odhalí věci, jako zabloudivší SW, problém v HW (prostě opakované zasílání stejné datové zprávy). Tu ztrátu jedné jediné zprávy obsahující informaci o tom, že někdo stiskl tlačítko, musím řešit protokolem a celkově aplikací - takhle mne napadá několik variant:
- v zařízení po stisku tlačítka nahodím příznak a po jeho zpracování přijde ze serveru/GW povel k jeho shození
- stisknutí tlačítka indikuji obsluze rozsvícením nějakého prvku - opět ale zprávou ze serveru/GW
- atd, atp
Bez potvrzení bych si troufl dělat věci typu teploměr, vlhkoměr, ... Ale tlačítka, kontakty, ... jedině s potvrzením.
-
Upřesnil bych tu stavovost :) Stav je duležitý jen v rámci jedné zprávy, pro minimalizaci meta-informací.
Něco jako:
TEPLOTA, (implicitně sensor 1), uint8_t, 25, S2, 30, VLHKOST, (uint8_t poděděno), (implicitně S1), 80, S2, 75
Umožní to mít gateway, která nemusí rozumět samotným datům, jen to zkonvertuje do něčeho složitějšího a předá dál. Je to trošku podobné právě M-bus aplikačnímu bloku, kde ale ty typy a jednotky musí být pořád dokola.
tak to je asi bez problému, měla by tam být nějaká identifikace, což, tuším, bude to za "TEPLOTA,"
-
reagovat se dá různě, třeba dotazem na všechny stavy
No a to je právě ten "reset komunikace", co jsem psal výš.
Navíc persistenci to taky vyžaduje, protože klient i server si musí pamatovat 1) které atributy už poslal 2) jaké má aktuální sekvenční číslo.
Na serveru to nebývá problém, ale na klientovi může být. Třeba takové ESP8266-01 si neumí nic zapamatovat po deep sleepu, takže jakékoliv udržování stavu je opruz. ESP32 už si umí pamatovat v RTC SLOW MEM, takže tam by to problém nebyl.
Něco jako:
Aha, takže to myslíš tak, že vynecháváš opakované atributy u hodnot? Jasný, to je určitě dobrá cesta. A ještě lepší je nedávat tam metadata vůbec ;)
-
Bez potvrzení bych si troufl dělat věci typu teploměr, vlhkoměr, ... Ale tlačítka, kontakty, ... jedině s potvrzením.
Souhlas. Navíc to potvrzování je ve spoustě protokolů "zadarmo".
-
Třeba takové ESP8266-01 si neumí nic zapamatovat po deep sleepu
Kecám, ESP8266 má taky RTC memory.
-
reagovat se dá různě, třeba dotazem na všechny stavy
No a to je právě ten "reset komunikace", co jsem psal výš.
Navíc persistenci to taky vyžaduje, protože klient i server si musí pamatovat 1) které atributy už poslal 2) jaké má aktuální sekvenční číslo.
tak reset komunikace může být leccos, jsou protokoly, které fungují třeba přes TCP a jednou za čas se zeptají na všechna data, prostě pro jistotu, aniž by zavíraly spojení (tomu se někdy říká "data integrity poll")
jestli persistence znamená, že si to pamatuje i mezi restartama, tak to obecně potřeba není, prostě se restartem přeruší spojení a pak se zase naváže od nuly, nejde o to dostat každou zprávu, ale neudělat nějakou blbost, protože to nahoře má špatnou představu o tom co se děje dole
nicméně v MarSikově případě to zřejmě nehraje roli
-
Aha, takže to myslíš tak, že vynecháváš opakované atributy u hodnot? Jasný, to je určitě dobrá cesta. A ještě lepší je nedávat tam metadata vůbec ;)
To je nejjednodušší řešení. Ale jde to jen pokud je pevně daný protokol, kterému spolehlivě rozumí obě strany v jakékoliv představitelné kombinaci verzí. Jakmile to má jít rozšiřovat bez přeflashování půlky sítě, tak se nějaká mírná dynamičnost hodí. A situaci komplikuje i když je bateriově napájená (a špatně dostupná) gateway - logger (tj žádné rPI se spoustou výkonu a internetem).
V mém případě se nebude přenášet informace o datovém typu, ten tam byl jen jako příklad (protože M-bus ho má). Ale půjdou za sebou volně poskládané sekvence [klíč, hodnota] s nějakou možností vyhození redundantních dat (a CRC na pevné pozici). Tím bude jednotný protokol pro jakýkoliv typ senzoru nebo data, která bude senzor chtít posílat jen někdy.
Celý paket má fixní délku (a bit který ho umí zdvojit / ztrojit, něco jako v unicode) a v tuto chvíli klíč (teplota, vlhkost, core Vin) implicitně určuje i datový typ hodnoty. Za daty může přijít modifikátor typu MAX, MIN, S2 + znovu data ve stejném formátu.
Btw, wireless M-bus má celkem pěkně řešenou právě konfiguraci bateriových nodů co se spotřeby týče (senzor musí vydržet 10+ let). Iniciátorem komunikace je vždy senzor a po odvysílání své zprávy může (nemusí) počkat na příkaz, který ho přepne do konfiguračního režimu. A ten timeout je celkem krátký. Tj gateway musí vždycky počkat na to až se senzor ozve (cca každých 3-5 minut) a rychle odpovědět se změnou konfigurace.
-
Btw, wireless M-bus má celkem pěkně řešenou právě konfiguraci bateriových nodů co se spotřeby týče (senzor musí vydržet 10+ let). Iniciátorem komunikace je vždy senzor a po odvysílání své zprávy může (nemusí) počkat na příkaz, který ho přepne do konfiguračního režimu. A ten timeout je celkem krátký. Tj gateway musí vždycky počkat na to až se senzor ozve (cca každých 3-5 minut) a rychle odpovědět se změnou konfigurace.
To je vlastně skoro stejný jako ta konfigurace s retencí v mqtt, co jsem zmínil - sensor se připojí na mqtt, subscribne na konfigurační topic, dostane konfiguraci, odešle data. Výhoda je, že tu konfiguraci můžeš zapsat kdykoli a sensor ji dostane jakmile je online, nevýhoda je, že se pošle při každém navázání spojení. U mqtt-sn by ten problém být nemusel, protože umí pracovat s uspáváním a nepoužívá spojovaný transfer.
-
diskuze se pěkně rozjela a mám se co učit, zatím tuším o co jde, uvidíme za jak dlouho mě ztratíte, kdyby měl něco čas a chuť si o tom popovídat, byl bych moc rád .. rozumím tak půlce
- o validaci komunikace se snažím vlastními silami - to byla motivace příspěvku, jak se toho elegantně zbavit
- nakreslil jsem diagram, aby bylo trochu vidět o co a jak se snažím, díky tomu vidím další možnosti .. do mě :)
(https://preview.ibb.co/dXYaS8/hap_01.png) (https://ibb.co/f589n8)
-
.. do mě :)
Mně přijde, že se hlavně (pokud ti teda nejde vyloženě o vyzkoušení si konstrukce komunikačních protokolů) zbytečně trápíš s věcma, který už jsou dobře vyřešený, řešíš je zbytečně krkolomně, a zbude ti pak míň času na ty zajímavější věci.
Pokud už vyloženě chceš použít ten ethernet, tak určitě nad ním běž do mqtt - budeš mít jeden otevřený port, nebude ti to padat, budeš si moct elegantně zvolit, která zpráva má být potvrzovaná a která ne (potvrzování máš zadarmo) a jako bonus máš věci, který třeba teď ještě nevíš, že chceš, ale budeš je chtít:
1. tu zmíněnou persistenci (v mqtt tzv. "retained message")
2. automaticky odeslanou zprávu při rozpadnutí komunikace (tzv. "last will")
Další nezanedbatelná výhoda MQTT je v tom, že se dá dobře mapovat na MQTT-SN, což použiješ, až zjistíš, že IP nechceš ;)
Jako ne, že by to tvoje řešení nemohlo fungovat, klidně pokud tě baví si hrát zrovna s tímhle, tak to tak udělej, proč ne, aspoň načerpáš zkušenosti :)
-
Mně přijde, že se hlavně (pokud ti teda nejde vyloženě o vyzkoušení si konstrukce komunikačních protokolů) zbytečně trápíš s věcma, který už jsou dobře vyřešený, řešíš je zbytečně krkolomně, a zbude ti pak míň času na ty zajímavější věci.
souhlasím, na ethernetu netrvám, ale přišlo mi to jako nejjednodušší s tím, co jsem věděl a měl
- nechci se utopit ve zbytečnostech, naopak, chci vzít co nejvíce funkčních dílčích celků a ty si spojit a dojít k něčemu funkčnímu
- na MQTT se podívám, díky
- aktuálně řeším funkčnost, za 14 dní provozu jsem měl 1x problém, ale když teče voda na zahradě celý den, tak to problém je
- chybí mi znalost/rada/vedení v koncepčních bodech .. tak to bastlím
-
No a teď si představte, že třeba soudruzi v automobilovém průmyslu používají jednoduchý princip, že ten, kdo chce něco říct, plácne to na sběrnici a ti, co je to zajímá, si to přečtou a ostatní na to kašlou.
A kupodivu to brzdí a akceleruje i bez potvrzování na sw úrovni, jen s vědomím, že zpráva byla ne sběrnici pro všechny čitelná.
Pokud totiž za těchto podmínek adresát nereaguje, není s ním patrně něco v pořádku a čekat na potvrzení je zbytečné.
U MQTT musí naopak broker postupně obesílat všechny přihlášené a zbytečně narůstá provoz na sběrnici.
-
jen s vědomím, že zpráva byla ne sběrnici pro všechny čitelná.
Což je u bezdrátu dost nerealizovatelná podmínka :)
-
No a teď si představte, že třeba soudruzi v automobilovém průmyslu používají jednoduchý princip, že ten, kdo chce něco říct, plácne to na sběrnici a ti, co je to zajímá, si to přečtou a ostatní na to kašlou.
CAN není ethernet a už vůbec ne wifi...
Pokud totiž za těchto podmínek adresát nereaguje, není s ním patrně něco v pořádku a čekat na potvrzení je zbytečné.
Tak tohle je hodně odfláknutá analýza...
Pokud si SW jednotky poskytující data "myslí", že je odeslal, nemusí to ještě znamenat, že na sběrnici opravdu jsou (chyba v nižších SW vrstvách, chyba v HW, chyba na sběrnici, ...). Ne je to, že konzument má problém...
A navíc rozdíl je také v tom, že auto má obsluhu (řidič), která dokáže okamžitě reagovat na případný problém.
A aby ta auta nevypadala tak skvěle - měl jsem jedno a tam když jsem z volantu chtěl přidat hlasitost rádia, tak to na první 3 stisky VOLUME UP reagovalo poklesem hlasitosti. Až teprve potom se hlasitost začala zvedat. Zatímco když jsem neprve 1x stisknul VOLUME DOWN a potom VOLUME UP, chovalo se vše podle předpokladu. Jen dodám - nebylo to tak úplně po každém nastartování, ale jen cca v 1/3 případů.
-
No a teď si představte, že třeba soudruzi v automobilovém průmyslu používají jednoduchý princip, že ten, kdo chce něco říct, plácne to na sběrnici a ti, co je to zajímá, si to přečtou a ostatní na to kašlou.
Už to napsali jiní, ale odladěný CAN přes diferenciální drátovou linku, s jeho detekcí kolizí a prioritním systémem, je trošku něco jiného než snadno zarušitelný bezdrát ve volném ISM (SRD) pásmu.
Mimochodem, víte že CAN má ACK bit? Viz frame struktura v části 3.1.1. třeba tady http://www.ti.com/lit/an/sloa101b/sloa101b.pdf Příjemci modifikují frame už během vysílání a odesílatel si to hlídá.
U MQTT musí naopak broker postupně obesílat všechny přihlášené a zbytečně narůstá provoz na sběrnici.
Ano, ACKy na simplex médiu "žerou" pásmo i baterku. Ale jinak to občas nejde.
-
Celkem jsem si oblíbil UDP multicast, rPI, ESP8266, nějaké počítače s macOS... Každý, kdo se připojí do UDP skupiny, má možnost poslouchat, případně reagovat. Sensory posílají vše každých 15s tím multicastem, jednou za 5m pošlou přes HTTP data do DB (Synology NAS). Posluchači jsou většinou LCD nebo OLEDy na zobrazení, ale i SW. Proti MQTT nevýhoda v nutnosti psát si to sám, ale zase pohodová škálovatelnost. Navíc přes další UDP port (opět multicast) mám DEBUG vzdálených ESP8266 i rPI...
-
Tak o bezdrátu se tu vcelku nehovořilo, pořád to bylo UDP, TCP atp.
Proto jsem nastínil i jinou možnost v podobě filozofie CAN.
A tam opravdu platí, že pokud je zpráva na sběrnici regulérně čitelná, není problém vysílače, že přijímač zprávu nezpracuje, když měl možnost ji přijmout.
Proto taky nikdy neodešlete na sběrnici regulérní CAN zprávu, pokud na ní není alespoň jeden přijímač, který právě tím ACK bitem potvrdí, že zpráva byla čitelná.
Příjemce by měl detekovat, že určitou dobu nedostává data a reagovat nějakým bezpečným způsobem do doby, než dojde k nápravě.
Jen jsem chtěl upozornit, že může být daleko efektivnější publikovat zprávy pro všechny přímo na sběrnici než do nějaké nadřízené databáze, která to pak zpětně rozesílá přihlášeným odběratelům.