jak se resi routovani zpravy v siti?
kdyz moje zarizeni posle zpravu jine 2 to preposlou, dalsi 4 to preposlou a do ciloveho zarizeni to bude chodit x-krat z ruznych mist?
Používá se jednoduchý záplavový algoritmus, který zohledňuje hodnotu TTL nastavenou ve zprávě. Ta tedy zaplaví okolí, ale nezahltí celou síť.
Presne na tohle sem se chtel taky zeptat, ale nevydrzel sem to a nasel si odpoved. Pouzivaj managed flooding. Kazda zprava ma hoplimit a tedy limit jak daleko se dostane + nody pry koukaj jestli nekdo jinej retransmituje a kdyz jo, tak to vynechaj. Tedy by se asi melo eliminovat putovani stejnym smerem - zpravy ktery uz zarizeni videlo nepreposila, ale porad se to posila na vsechny strany. Prej chytry routovai by vyzadovalo vykon v zarizenich a nejaky zpravy na udrzovani routovacich informaci. https://meshtastic.org/blog/why-meshtastic-uses-managed-flood-routing/
16. 10. 2024, 08:13 editováno autorem komentáře
to routovani ve velkych sitich bude narocna zalezitost. uvazoval jsem o siti z mobilnich telefonu jen pomoci bluetooth a wifi bez gsm sluzeb. ale proroutovat zpravu mezi hromadou telefonu v adresatovi by bylo narocne. taky me napadlo, ze by slo mozna pouzit pravidlo 6 stupnu odlouceni, ale to by kazdy telefon musel mit seznam ostatnich zarizeni a kazdy stroj s unikatnim id.
To musi byt strasne neefektivni prece.
V podstate to je broadcast a nody si hlidaj at se nezacykli na te same zprave.
A siri se to jako vlna / wavefront, jak kdyz zapalite listi v lese? (jen tedy s omezenim TTL).
Takze kapacita cele site je stejna, jako kapacita jednoho nodu? Cekal jsem neco lepsiho teda, kdyz uz nekdo buduje mesh.
Tohle je dobry leda tak na velikou zahradu / halu. Ne na celorepublikovy site napr.
Taky se mi nezdá, jak ta síť může přežít, když všichni dostávají všechno. Přehlcení je nevyhnutelné.
To je zajímavý problém a řešili jsme ho i na LinuxDays. To směrování se dá časem změnit, pouhou aktualizací firmware. Když bude fyzická vrstva, zbytek se dá ladit. Přeci jen je to mladý projekt.
No.. teoreticky ano, ale prakticky to znamená změnu protokolu. A jelikož se komunita neshodla ani na Medium / Fast (ČR) vs. Long / Fast (Brno), tak nevidím switch sítě na upravený protokol zase tak optimisticky.
Ja ano. Proste by se treba od verze firmware 3.0 zmenil protokol/algoritmus a hotovo.
Neco jako zmena z IPv4 na IPv6.
To nebyl dobrý příklad :) Rozšíření IPv6 a podpora u poskytovatelů dává spíš za pravdu mě. Jakýkoliv fork to má těžké. Obzvláště jakmile dojde k produkčnímu nasazení.
Kdybych to resil ja, tak na ty nejnizsi vrstve bych nechal idenfitikaci verze protokolu (napr. jak mate v IP pak verzi 4 ci 6), a node bude pracovat se svoji verzi, ci verzemi ktere zna, a navic by mohl mit schopnost detekovat (pocitat) pocet paketu ktere nezna - a pak to v telemetrii sdelovat.
Pak by nekdo, kdo se o tyhle nody stara a dohlizi na ne, mohl vedet ze chytrejsi sousedi upgradovali.. a mohl zvazit prechod svych zarizeni na tu novou verzi.
Zda podporovat dve verze ( N a N+1 ), nebo podporovat dve stylem ( #1 a N ), aby slo delat OTA upgrade fw pres tu #1, uz necham na nekom jinem :-)
Ten filtr poslechem sousedů mi přijde divný. To přece musí narazit na problém vzdálenějších nodů:
Pokud máme skupinu A - B - C - D, kde se překrývá dosah sousedů tak, že B slyší A, C slyší A i B, ale D neslyší A ani B, tak zpráva od A k D nedorazí:
- A vyšle zprávu.
- B ji uslyší a přepošle (ale D ji neslyší)
- C ji uslyší, ale uslyší i opakování of B, tak je ticho
- D neslyší nic
Bylo by zajímavé to zkusit na tom jejich simulátoru https://github.com/meshtastic/Meshtasticator/blob/master/INTERACTIVE_SIM.md
a vysle zpravu a b ji slysi, b ji posle c.
c ji mohlo slyset treba poprve od a tak uz ji ignoruje od b.
c ji mohlo slyset poprve od b tak uz ji ignoruje od a.
d ji treba muze slyset od c a c ji do d posle, protoze ji neposle jen do a nebo b, ale d ji z a ani b nemohlo slyset, tak d ji muze slyset jen od c.
takze nevidim problem.
"B" zprávu nepošle "C", "B" zprávu prostě zopakuje.
"C" ji znovu nikam nepošle, protože už ji slyšelo od "A" i "B".
Tam není nic jako "C" ji do "D" pošle, ale do "A" nebo "B" ne. Tam se to buď odvysílá, nebo neodvysílá. Je to rádiový broadcast. Takže pokud to "C" nepošle, tak "D" nic neuslyší.
Takže ta optimalizace na omezený retransmit je buď hodně agresivní a "D" zprávu nedostane, nebo to neustálé opakování tu frekvenci zaruší na celkem dost dlouho a "A" svoji zprávu uslyší minimálně dvakrát znovu.
Jen abychom si rozuměli. Tam není žádný cíl nebo next hop. Meshtastic nemá ustálenou a sestavenou topologii. Používá "chytrý" flood broadcast.
* ok, tak A ji vysle.
* B i C ji prijme.
* B i C ji znova odesle.
* A ji prijme od B i od C, ale uz to ma v zaznamech tak nic nedela.
* B ji znova prijme od C a C ji znova prijme od B, ale oba ji maji v zaznamech tak nic nedelaji.
* D vidi jen na C a kdyz ji C odeslalo tak ji D prijmulo a je konec.
Ale o tom se tu přece celou dobu bavíme. "C" ji nepošle. Protože optimalizace broadcastu.
"C" tu zprávu už slyšelo od autora "A" a slyšelo její opakování od "B".
Takže pokud Michal Hrušecký píše, že
Kazda zprava ma hoplimit a tedy limit jak daleko se dostane + nody pry koukaj jestli nekdo jinej retransmituje a kdyz jo, tak to vynechaj.
Tak "C" tu zprávu neodvysílá a "D" ji nedostane.
Tady https://meshtastic.org/docs/overview/mesh-algo/#example je napsáno to samé:
Since node 1 heard the rebroadcast by 2, it will not rebroadcast again.
Jediná optimalizace tohoto problému, kterou jsem našel je, že příjemci s nižším SNR opakují první (kratší timeout). Což funguje jen pokud je to stejný hardware se stejnou anténou.
ta neaktivita je na stane prijemcu.
viz. bod 3
* B i C ji znova odesle.
kazdy prijemce jednou vzdycky prijme a jednou vzdycky odesle.
ale kdyz ji prijme podruhe, tak ji uz podruhe neodesle.
17. 10. 2024, 14:28 editováno autorem komentáře
Ne, neodešle. Jasně jsem Vám to citoval z webu Meshtasticu a je to vidět i v tom časovém diagramu tam.
Node 1 to v jejich příkladu nikdy neodvysílá.
https://meshtastic.org/assets/images/SNR_based_flooding-c574565610e85879688f3c96e4494e92.webp
A už jste ve svém okolí někdy viděli node někoho jiného? Veškeré moje experimenty s Meshtastic (HW jako T-Lora32, Heltec V2/V3, apod. jsem jako HAM nakupoval primárně kvůli LoRa APRS pro 433MHz, a LoRaWAN na 868MHz) skočily na tom, že se v okolí žádný další node nevyskytoval.
Jinak jsou na Internetu návody na Meshtastic node (napájený ze solárních panelů) s dostatečným krytím, umístěný ve volné krajině, nemusí se jít nutně cestou nakoupeného kitu.
V okolí Kolína jich pár je, mě aplikace ukazuje že celkem jich zachytila (se skoky) 226, takže to asi roste :-) (Heltec V3, Solar,baterie cca 8Ah).
Řekl bych, że po LinuxDays a tomhle článku to znatelné vyroste. Bude zajímavé to sledovat, jen moji kamarádi si objednali celkem pět zařízení.
Jaky je limit na maximalni pocet zarizeni? TTN treba omezuje LoRa traffic pro kazdou jednotku z duvodu legislativnich omezeni, takze mainstreamovy komunikacni kanal z toho nikdy asi nebude...
Ta Meshtastic sit je jen jedna verejna, nebo se musim registrovat k nejake skupine pomoci nejakeho spolecneho klice? (u TTN se taky vzdy registruje ke konkretni gatewayi)
16. 10. 2024, 14:08 editováno autorem komentáře
Maximální počet zařízení omezen není. Teoreticky je možné provozovat libovolné množství nodů v síti. Prakticky ale začnete od určité velikosti narážet na technické limity. V Evropě máme na 868 MHz povolen pouze 10% duty cycle, takže pokud bude jeden dobře umístěný node přeposílat hodně zpráv, tak se bude muset občas odmlčet (Meshtastic si hlídá duty cycle za každých 10 minut).
Meshtastic je decetralizovaný a nikdo jej nekoordinuje. Každý si může pořídit zařízení a začít ho používat bez jakékoliv registrace. Pokud se chcete zapojit do komunikace s ostatními v česku, pak je nutné nastavit si stejné parametry jako ostatní -- modem preset medium/fast, stejný veřejný kanál, atd. Koordinujeme se na czmesh.cz
Pokud ale chcete svoji vlastní soukromou síť, pak si můžete zvolit nastavení libovolné a mít kanály s tajnými klíči, které budete znát jen vy. To se hodí na vybudování senzorové sítě v malé lokalitě - okolí vesnice, tábořiště, velké pole, atd.
> V Evropě máme na 868 MHz povolen pouze 10% duty cycle
Když dám na kopec 10 nodů, které se budou střídat (jakmile jednomu dojde 10% limit, převezme to další), mám legálně vyřešený problém?
Ne. Obcházení zákona technickými kličkami se nepovažuje za vyřešený problém.
Hlavně si uvědomte, že pracujete se sdíleným médiem. Radiové vlny nejsou full-duplex. Vysílat může vždy jen jeden. Takže zarušením celého pásma si nepomůžete.
Jak by to zarusilo pasmo?
mam 10 zarizeni
Jsou vedle sebe a jsou spojeny pomoci BT. A davaj si vedet kdo je master. Master odpadne az mu odpadne limit... do te doby ostatni jako by neexistovaly...
Mozna by bylo dobre mit treba dva dokrejvaci, navic... Takze nejak nechapu ja kje to obchazeni pravidel. Pravidla jsou dana na zarizeni ne na vlastnika...
Podminky splneny...
A je deset synchronizovaných vysílačů patřících jednomu vlastníkovi jedno složité zařízení nebo 10 jednoduchých?
Pásmo to zaruší snadno, 100% využití neumožní nikomu jinému v okruhu několika kilometrů vysílat.
"Jak by to zarusilo pasmo"
Fyzika vime?
Ale legislativne by to samozrejme koser bylo. Ono se ale nepredpoklada, ze by to nekdo chtel realne pouzivat. Proto je to omezeni stanoveno jak je.
Takže je jich 9 vypnutých a jeden zapnutý a střídají se. A tím papírově dodrží 10% duty cycle, akorát ve skutečnosti vysílají 100% času. A tomu neříkáte zarušení pásma? Nemluvě o tom, že teda nebudou mít co opakovat, protože se jim nikdo nedovolá no..
Záleží na přesné frekvenci. Alternativou je LBT (listen-before-talk). A garantuje to výrobce, uživatele to zajímat nemusí.
A popravdě.. nechápu, proč je potřeba za každou cenu být vtipný.
Vysílat cokoliv můžete jen s povolením. V tomto případě na základě všeobecného oprávnění č. VO-R/10/03.2021-4
k využívání rádiových kmitočtů a k provozování zařízení krátkého dosahu - https://ctu.gov.cz/sites/default/files/obsah/vo-r10-032021-4.pdf
Stejne to je smutne.
V EU mame na 868 MHz jen 1 kanal pro meshtastic s max 27 dBm a 10% vyuzitim.
V US maji na 915 MHz 104 kanalu, 30 dBm a 100% vyuziti.
Podle teto tabulky vychazi nejhure EU a Ukrajina https://meshtastic.org/docs/configuration/radio/lora/#region
https://meshtastic.org/docs/configuration/radio/lora/#region
https://meshtastic.org/docs/overview/radio-settings/
Nj, ale všimněte si, že v USA třeba zase vůbec nemají volně použitelných 433 MHz. Každý region má něco.
takze cela technologie ma omezeni na 10 zarizeni v okoli a pak mame zarusene pasmo a nikdo nemuze vysilat? Pokud je to tak, tak potes koste, to se moc ta technologie nerozsiri... ja prave cekam na IOT sit ve ktere budu moci mit cca 300 zarizeni a zatim je to nesmysl z pohledu ceny i implementace.
Ale klient nemusí vysílat 10% času. Klidně může vysílat jen dvakrát denně. Tady jde hlavně o routery (repeatery) a ten mesh flooding.
A i v tom záplavovém algoritmu se Meshtastic snaží omezit zbytečná vysílání tím, že nejdřív poslouchá provoz.
Samozřejmě, že aplikace, která plně využije své pásmo na těch 10%, bude okolí způsobovat potíže. Ale pak se dá skočit frekvenčně o kousek vedle, kde je 868 MHz s omezeným duty cycle na 1% (nebo dokonce 0.1%).
Poprvé jsem to zkusil před 2 měsíci v Plzni. Viděl jsem několik stanic (jednotky). Teď jsem to zkusil znovu a slyším jen ticho.
Doplneni. Po 3.5h jsem v Plzni naprimo alespon obcas zaslechl 15 uzlu site. Z toho jeden co vypada jako by profrcel kolem po D5
Příjem prvního paketu od okolních nodů může trvat klidně i několik hodin. Pokud je v síti klid a nikdo neposílá zprávy, pak je nutné počkat na NodeInfo broadcast paket a ten mají některé stacionární nody nastaven až na 6 hodin. Síť v Praze a okolí (i Plzni) už je dost velká a docházelo k zahlcení některých výše položených zařízení. Proto se na czmesh.cz dohodlo, že NodeInfo interval bude 6 hodin.
Vnitřně s tím tak nějak bojuju. Chtěl bych to používat, protože to zapadá do mého "portfolia" HAM, EMCOMM/ARES - no jenze bohuzel, jsem v miste kde to NIKDO nepoužívá (na malinkem meste) a ani v okolí to není lepší. Takže si to zkouším na stole, dvě zařízení 868, hm, občas nefunguje BT spojení, občas nedorazí zpráva, já ti nevím předsedo ... vedle toho je tu zcela funkční LORA APRS, na první dobrou funguje, pokrytí neříkám že nejlepší, ale asi budu investovat (čas a peníze) spíš do pokrytí LORA APRS než Meshtastic - i když se mě to líbí. Ti co v tom jedou už dlouho stejně říkají, že se to zahlcuje (tam kde je provoz) nebo tam nikdo není. Nakonec ani ta uživatelská základna není to nejlepší, kde kdo si myslí, že tomu rozumí, malé (originál) anténky, dělají se routery atd. - já vím že v tom nemá bejt žádnej řád, ale ono to prostě globálně jinak fungovat nebude. Možná na to původní určení - malé územní celky v rámci měst ok, tam to asi dává smysl. Mimochodem, díky nastavení to rozhodně není pro každého - je tam toho tolik, stačí jeden špatný klik a je to celé rozbité ... je to pro geeky, je to krásná hračka. Kdo si hraje nezlobí :-) držím projektu Meshtastic palce.
Ano, má to své mouchy, ale postupně se je daří chytat.
Projekt je relativně mladý a na popularitě (nejenom u nás, ale i ve světě) nabírá teprve poslední rok. Github repozitář je velmi aktivní a nové verze FW se vydávají každou chvíli. V porovnání s APRS, které existuje od 80. let je Meshtastic v plenkách.
S odpojováním od Bluetooth jsem měl problémy cca půl roku zpátky, teď už mi můj RAK node běží spolehlivě. Nebo např. RAK4631+RAK19007 nemá úplně ideálně vyřešenou napájecí část a vstup pro solární panel. Stávalo se mi, že se node úplně odmlčel a bylo nutné vyézt na střechu a provést restart. Stačilo použít jiný HW s lepším zdrojem a už několik měsíců vše funguje.
> Možná na to původní určení - malé územní celky v rámci měst ok, tam to asi dává smysl.
Tady 100% souhlasím. Meshtastic nemůže být (při současném mesh algoritmu a omezeních na 868 MHz) globální síť s desítkami tisíc uzlů. Osobně ho vnímám jako ideální technologii pro menší izolované síťe pro IoT. Ale rozhodně mě baví i možnost vyměnit si pár zpráv s ostatními, když někam jedu.
Meshtastic je stoprocentně komunitní záležitost, pokud nemáš kolem sebe komunitu, tak prostě není co Meshtastikovat :-) to tak je a vzhledem k dosahu to tak i zůstane. Vlastnosti 868MHz v kombinaci s velmi malým výkonem z toho prostě dělají věc pro místa kde žije vícero geeků - to jsou velká města.
já tomu fandím, je super, že se něco děje. třeba se někdy v budoucnu k meshtasticu jako uživatel vrátím, třeba ještě něčím překvapí. projekt BBS pro meshtastic je za mě zásadní, v tom vidím potenciál, že se do decentralizované sítě dostane možnost nechat někomu někde vzkaz nebo soubor atd. navíc se ty BBS dokáží synchronizovat, to je naprosto super. z toho jsem nadšenej já osobně, ale zase na druhou stranu, prý to zahcuje už tak zahlcenou síť ... to je velká škoda ...
Nojo, ale BBS meshtastic pořád stojí a padá na husté síti. Pokud neudělají internet gateway systém jako má APRS nebo DMR.
Pro nás HAMy (a preppery s oprávněním) tu je pořád Winlink nebo třeba i staré a skoro mrtvé Packet radio na VHF nebo dokonce HF, žejo.
Já si od Meshtasticu slibuju hlavně to, že prozkoumají slepé uličky a přispějí k vývoji těch mesh algoritmů daty z provozu. Hlavně v ČR, kde je 868 MHz prostě na delší vzdálenosti problém.. je tu moc kopců uprostřed a ta frekvence už moc mimo přímou viditelnost nejede.
Komerční mesh dělá i třeba tady několikrát prezentované IQRF. A mesh pro lokální prostředí má i Zwave a Zigbee. Celkem by mě zajímalo srovnání vlastností těch protokolů.
Určitě je to super, cokoliv co vysílá a nějak se to programuje je super, komunita si s tím hraje, sebevzdělává se, něco se někdo přiučí, k něčemu přičichne. Mimochodem, ještě stojí za zmínku projekt RNode to je takovej "moderní" packet.
17. 10. 2024, 17:57 editováno autorem komentáře
tipuju, ze to je podobna technologie co ma apple s airtagy a iphony, ze reaguji na radiovy signal a kdyz je v okoli jine zarizeni, tak se da vystopovat jine apple zarizeni.
Ne, Airtagy používají bluetooth a nevytvářejí žádnou síť. Fungují jen jako majáky pro telefony, které se pohybují v okolí a posílají standardní cestou přes mobilní síť informace o tom, se kterými majáky se potkaly.
Meshtastic proti tomu používá velmi robustní modulaci LoRa, která i při minimálním výkonu lítá na kilometry až desítky kilometrů. Jednotlivé uzly se přímo spojují do velké sítě a předávají si zprávy. Nepotřebují k tomu žádnou mobilní síť a další infratrukturu. V tom připomínají spíš klasickè vysílačky.
LoRA hlavně kromě modulace přímo v protokolu používá všechny správné techniky pro přípravu dat (prokládání, odstranění dc složky, samoopravný kód a hammingovo kódování).
A už tahle "softwarová" stránka dělá hrozně moc.
To většina lidí s FSK rádiem připojeným k Arduinu nikdy nenaimplementovala a posílala si datové bajty napřímo. Takže se nedívím, že je LoRA oblíbená.
Na druhou stranu já Semtech nemám moc rád. Protokol je uzavřený a patentovaný, je omezený okruh výrobců. Ale alespoň ho na univerzitách důkladně zanalyzovali a popsali: https://dl.acm.org/doi/10.1145/3546869
Zkusil jsem a vzdal to - kdo si chce na Meshtastic pokecat, tak kecá na Telegramu . Dostat přes to zprávu podle mě snad ani nejde.
To spis porovnavate nejakou sluzbu vs. nizsi vrstvu (fyzicke medium).
Taky si moc nepokecam s UTP kabelem trcicim ze zdi :D
Ani ne. Ty nody jsou obvykle bluetooth - LoRA - Meshtastic převodník k telefonu, kde běží aplikace. A ta aplikace umí víceméně jen posílání zpráv a správu těch zařízení.
nedavno jsem cetl, ze pro rizeni drony, aby nesly elektronicky rusit, pouzivaji velmi tenke opticke vlakna dlouha az 8km.
to by mohla byt dalsi zajimava technologie, v prirode kde je klid do listi zahrabat tenkou optiku a propojovat kilometry vzdalene kraibicky :-)
Ale jak často? Pokud bude fungovat detekce, kde je to přerušené (které vlákno) a ekonomicky levné ho nahradit (natáhnout nové)... Někdy by stačilo to natáhnout na sloupy. Pokud je to tenké a nenápadné ;-)
17. 10. 2024, 00:46 editováno autorem komentáře
lukem vystrelit do koruny stromu spagat prez vetev a vytahnout lanko do koruny stromu, treba do vysky 4m.
tenke opticke vlakna maji prurez i mene nez 1 mm.
Vítr a padající větve to rozervou za chvíli. A nejpozději v zimě to zničí namrzající déšť (zatíží a přetrhne).
... vlakna pouzivana pro drony neni zadna novinka, kdo nema mliko na brade tak vi co je to malutka. To vlakno je na jedno pouziti, takze nepotrebuje zadnou ochranu a muze byt tenke.
Pohozene nekde v lese nebo i na sloupech by vydrzelo funkcni tak maximalne jednotky dnu.
4 MB pro ESP po Mesthastic síti? No.. teoreticky asi ano, ale prakticky si to neumím představit. To by tu už tak křehkou síť (protože flood broadcasty) zabilo.
takze kazda aktualizace znamena vzit fyzicky zarizeni a nejak ho offline aktualizovat? Takze budu travit dny aktualizovanim zarizeni na ruznych mistech? Tak to se jim na to IOT s prominutim...
Ne nezbytně. Teoreticky by stačilo se dostat na příjmovou vzdálenost wifi a aktivovat OTA mechanizmy přes ni. Nemusíte ho rozmontovat a sundat.
Pěkné, chci vyzkoušet.
Je nějaké zařízení (rádio) s ethernetem napájené ideálně z PoE?
V CZ se reálně používá 868 nebo 433 MHz nebo obojí?
V ČR se primárně používá 868 MHz. Rádio s ethernetem bude maximálně RPi s usb kabelem píchlým do něčeho jako Heltec V3 :)
Obvykle v těch modulech je NRF nebo ESP32, takže Wifi nebo Bluetooth.
Díky. ESP32 s ethernetem existují, i od LiliGo, další ESP32 s ethernetem a PoE jsem bral na Alí. Ale nemají LoRa rádio :). Chci to dát na střechu, tam je jen ethernet přes přepěťovku, žádný další drát tam nechci, funkční přepěťovky jsou drahé.
Vezmu z Alí 2x T-Echo s displejem a uvidím, jestli mě to bude bavit a později třeba node na tu střechu, až budu vědět víc.
A co tam dát jen PoE splitter na napájení a wifi na komunikaci (pro testy)? Drát je drát, ale když je to experiment, tak není potřeba být tak důkladný :)
Asi jsem se sem propad z jiný planety ALE - ani článek a už vůbec ne diskuse mi nedává odpověď - K ČEMU JE TO SAKRA DOBRÝ? To je jako nějaký distribuovaný chat, nebo nějaká IOT, nebo extra pomalý internet zdarma, nebo.. Neměl by tímto článek začít?
V článku je v 6. a 7. odstavci explicitně napsané co Meshtastic umí. Myslím, že na základě toho už si člověk představu udělá.
Jako vypadá to super a měl bych hned využití... jen jak by se k tomu připojil alarm od Jablotronu? Tuší někdo?
Jablotron nabízí i/o moduly, které se dají trigrovat na základě nějakých události. a meshtastic umí pracovat s i/o vstupy. Problém je jen v tom že to uvidí celý svět (zjednodušeně řečeno) a nemusí to být spolehlivě úplně (opet zjednodušeně řečeno). Rozhodně jde připojit cokoliv.
Používám https://www.hitobchod.cz/jb-118n-sbernicovy-signalni-modul-vystupu-pg--8-vystupu
Mám k tomu připojené na jednotlivé PINy ESP a pak už je jen na fantazii, co s tím dál.