reklama

UDP komunikace: Raspberry <-> Arduino

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #30 kdy: 21. 06. 2018, 14:16:40 »
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...

reklama


v

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #31 kdy: 21. 06. 2018, 14:32:18 »
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

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #32 kdy: 21. 06. 2018, 15:11:57 »
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á.

v

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #33 kdy: 21. 06. 2018, 15:32:24 »
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

MarSik

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #34 kdy: 21. 06. 2018, 16:02:13 »
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.

reklama


václav

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #35 kdy: 21. 06. 2018, 16:05:20 »
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.

v

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #36 kdy: 21. 06. 2018, 16:07:46 »
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,"

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #37 kdy: 21. 06. 2018, 16:09:05 »
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 ;)

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #38 kdy: 21. 06. 2018, 16:10:21 »
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".

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #39 kdy: 21. 06. 2018, 16:19:27 »
Třeba takové ESP8266-01 si neumí nic zapamatovat po deep sleepu
Kecám, ESP8266 má taky RTC memory.

v

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #40 kdy: 21. 06. 2018, 16:28:09 »
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

MarSik

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #41 kdy: 21. 06. 2018, 16:58:11 »
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.

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #42 kdy: 21. 06. 2018, 17:10:22 »
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.

rpi_ard

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #43 kdy: 21. 06. 2018, 19:38:18 »
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ě  :)
hap_01" border="0

Re:UDP komunikace: Raspberry <-> Arduino
« Odpověď #44 kdy: 21. 06. 2018, 19:58:52 »
  .. 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 :)

 

reklama