Forum
Jednoducha odpoved je ano moze.
Ked budes hladat, niekde na fore je odkaz na github, kde su nejake podklady.
Otazka je zivotnost po update.
Pánové, tak si tu čtu vaše plány, jak ke každému senzoru budete dávat Arduino/ESP,... nahrávat SW na dálku... Čtu si tu debatu, jestli data ze senzorů do rozvaděče posílat přes RS485 (Modbus) nebo ethernet (UDP)....
Cítím potřebu zmínit ještě jednu alternativu: posílejte data ze senzorů do rozvaděče "nativním" protokolem toho kterého senzoru (tj. 1-wire, I2C, atd atd.). Nedávejte Arduino k senzorům, stačí jedno Arduino v rozvaděči, které posbírá data ze všech senzorů a pošle je do Loxone.
Je mi jasné, co mi na to řeknete. Takto se to "prostě nedělá", páč třeba sběrnice I2C je určená nanejvýš na centimetrové vzdálenosti v rámci jednoho zařízení. 1-wire je sice určená na delší vzdálenosti, ale pořád je to velmi nespolehlivá sběrnice. Já vím, z vlastní zkušenosti. Mám obyč nestíněné UTP kabely, souběh se silovými. Logoval jsem si 1-wire a dostával jsem se třeba až na 20% chybovost (tj. 20% dotazů na senzory skončilo chybou nebo timeoutem). Dokonce jsem vypozoroval, že chybovost přes den kolísá a je nejvyšší v době, kdy svítím přes AC triaky... Pak jsem si napojil nějaké senzory světla přímo přes I2C sběrnici (cca 10m). I2C je opravdu na 10m nespolehlivá, 2x denně se kousla (a Arduino vytuhlo).
První řešení je to, co navrhujete vy: eliminovat chyby v přenosu na nulu tím, že k senzoru dáte "převodník" (Arduino/ESP) a nahradíte nespolehlivý "nativní" protokol něčím lepším - RS485 nebo ethernet.
Druhé řešení: akceptovat a smířit se s tím, že přenos dat ze senzoru do rozvaděče půjde přes nespolehlivý protokol. A Arduinu v rozvaděči řeknete: "v případě chyby v komunikaci se senzorem počkej 100ms, pak to zkus znovu".
Je to primitivní a překvapivě účinné. Na čtení z 1-wire si dám limit 10 pokusů a jsem v klidu. I2C sběrnici si nastavím tak, aby se v případě chyby nezasekla, ale restartovala. Výsledek? Přestože Arduino v rozvaděči komunikuje se senzory po nespolehlivých nativních protokolech, data do Loxonu posílá se 100% spolehlivostí.
V rozvaděči mám jedno Nano, které se stará o 10ks teplotních 1-wire senzorů, 3ks DHT22 a 2ks BH1750FVI (světlo) senzorů. Představa, že bych ke každému senzoru dával Arduino jako převodník na RS485/Ethernet.... To by mě jeblo.
Pokud chci přidat další senzor, nemusím bastlit nový převodník. Prostě píchnu kabel na volný pin Arduina a v konfiguraci skeče si jednoduše nastavím, že na I/O Arduina číslo XY je nový datový pin (v případě I2C senzorů adresní pin) toho a toho senzoru.
Tady je ten skeč:
https://github.com/budulinek/Arduino-multiple-sensors-UDP
ty jo priznam se ze pro me to je fakt kacirska myslenka. i2c na 20 metrech mi prijde sileny.
na druhou stranu se mi hodne libi ta jednoduchost reseni
Za zkoušku nic nedáš. Jinak ty cca 2 chyby I2C sběrnice za 1 den jsem měl při připojení 2ks BH1750FVI, perioda odečítání dat ze senzoru 2 sekundy. Takže když si to spočítáš, chybovost docela malá, řádově menší než u 1-wire senzorů.
Každopádně, nezapomeň si ve skeči u I2C sběrnice nastavit setWireTimeout, aby ti sběrnice při chybě nevytuhla. Viz můj skeč nebo třeba https://www.fpaynter.com/2020/07/i2c-hangup-bug-cured-miracle-of-miracles-film-at-11/
Joo a abych nezapomněl. Pokud používáte ty "nativní" sběrnice (1-wire, I2C, DHT) na delší vzdálenosti, nezapomeňte na pull-up rezistory (mezi +5V a data). U 1-wire nutnost, u DHT doporučuju, u I2C jsem zatím nepotřeboval.
Tedy pro mne zas šílené řešení je použití těchhle "nativních sběrnic" sensorů.
Jednak to znamená, že přidání jednoho čidla znamená přeprogramování té UDP gateway s možností zanést novou chybu do už odladěného řešení.
Pak mne napadlo, co bude uživatel dělat, když bude chtít použít na sběrnici víc než dvě čidla osvětlení. ( Protože ten senzor nabízí jen konfiguraci dvou adres podle stavu vstupu ADR.)
Kouknul jsem do toho programu a to řešení mne tedy dostalo......
Jestli jsem to dobře pochopil, používá se jen jedna adresa a ke každému čidlu se kromě i2C sběrnice táhne ještě jeden drát, který aktivuje čtení z konkrétního čidla. To by mi tedy hodně rychle došly dráty v UTP kabelu....
Za mne tedy daleko jednodušší použít univerzální gateway a přidávat senzory dle libosti.
Navíc netřeba "vymýšlet kolo", vhodná řešení už někdo naprogramoval.
Drát i bezdrát třeba MySensors.org - s tím mám vlastní zkušenost, když jsem potřeboval data z konce zahrady, kde už není wifi, tak 1x nano + RFM69 jako senzor a ESP8266 + RFM69 jako gateway a za odpoledne bylo hotovo. Na stole jsem rozchodil i tu jejich RS485 síť, i když pořád říkám, že pro tyhle multimaster protokoly jsou lepší budiče pro CAN sběrnici než pro RS485, protože dokáží zpracovat i kolizní stavy.
Další možnost pak třeba PJON.org
Jednak to znamená, že přidání jednoho čidla znamená přeprogramování té UDP gateway s možností zanést novou chybu do už odladěného řešení.
Ne. Přidáním dalšího čidla nic nerozhasíš. Program je naopak odladěný tak, aby přidávání dalšího čidla bylo super easy. Stačí v konfiguráku přidat další data pin (resp. adresní pin).
Pak mne napadlo, co bude uživatel dělat, když bude chtít použít na sběrnici víc než dvě čidla osvětlení. ( Protože ten senzor nabízí jen konfiguraci dvou adres podle stavu vstupu ADR.)
Kouknul jsem do toho programu a to řešení mne tedy dostalo......
Jestli jsem to dobře pochopil, používá se jen jedna adresa a ke každému čidlu se kromě i2C sběrnice táhne ještě jeden drát, který aktivuje čtení z konkrétního čidla.
Samozřejmě, světelný senzor BH1750FVI se dá adresovat jenom pinem. Pokud máš jenom jeden senzor, můžeš si drát ADDR odpustit.
To by mi tedy hodně rychle došly dráty v UTP kabelu....
Pokud nepočítám napájení a zem, tak na senzory potřebuješ:
- 1-wire: 1 drát
- DHT22: 1 drát
- BH1750FV: 3 dráty (resp. 2 dráty pokud máš jen 1 senzor)
Pro srovnání:
- Ethernet: 4 dráty
- RS485: 2 dráty
Samozřejmě, moje řešení se hodí pro situace, kdy máš v jednom místě 1-2 senzory. Pokud máš meteostanici s pěti senzory, je z hlediska počtu drátů efektivnější posílat data ethernetem.
Za mne tedy daleko jednodušší použít univerzální gateway a přidávat senzory dle libosti.
Navíc netřeba "vymýšlet kolo", vhodná řešení už někdo naprogramoval.
Drát i bezdrát třeba MySensors.org - s tím mám vlastní zkušenost,
Hmm, umí MySensors.org asynchronní čtení několika senzorů? Čtení senzorů nějaký čas trvá a já nechci, aby se vzájemně zdržovaly. Umí MySensors.org čtení několika 1-wire sběrnic?
Upřímně, letmo jsem zjišťoval, jestli to MySensors.org umí a nezjistil jsem to. Předpokládám, že neumí (kdyžtak mě oprav). A pokud jsem neměl jistotu, že to MySensors.org umí, nechtělo se mi investovat čas na učení jejich API.
Prvotní motivací pro můj projekt bylo to, že jsem nemohl najít návod, jak udělat čtení několika 1-wire sběrnic (Loxone 1-wire Extension, Unipi Neuron i Railduino umí číst vždy jen jednu 1-wire sběrnici). Internet je samozřejmě plný skečů na čtení senzorů. Který z nich to ale umí asynchronně? No, třeba u DHT knihovny jsem si asynchronní čtení musel dopsat sám, aby to vůbec fungovalo...
když jsem potřeboval data z konce zahrady, kde už není wifi, tak 1x nano + RFM69 jako senzor a ESP8266 + RFM69 jako gateway a za odpoledne bylo hotovo. Na stole jsem rozchodil i tu jejich RS485 síť, i když pořád říkám, že pro tyhle multimaster protokoly jsou lepší budiče pro CAN sběrnici než pro RS485, protože dokáží zpracovat i kolizní stavy.
Tady určitě souhlasím. Pokud máš specifickou situaci (senzor z konce zahrady, bezdrát, meteostanice atd.), je lepší použít jiné řešení (třeba ty MySensors.org).
Moje řešení je určeno na drátové připojení většího množství senzorů pomocí Arduina centrálně umístěného v rozvaděči.
kde je popsanu u mysenzor ta dratova varianta prosim?
co jsem nasel tak tady pisou o bezdratu
Sensor nodes - continuously read the status of all attached sensors and pass the sensor data through the radio network back to the gateway.
—
vic se mi libi aby kazdy cidlo melo svuj mozek a posilalo data po necem normalnim. to i2c na velkou vzdalenost jeste asi zkusim, ale nejak se mi to nezda 😀
zatim se asi cim dal vic se klonim k tomu modbusu - homeassistant ho umi nativne. canbus bych musel prelozit a poslat pres mqtt nebo tak neco asi.
Nevím co přesně myslíte pod pojmem asynchronní čtení senzorů.
V koncepci MySensors prostě node pošle data když má co poslat. Většinou když dojde k jejich změně, pokud se nezměnila tak jednou za nějaký časový interval + je tam i nějaký "heartbeat". Nemusí se čekat na žádný pokyn pro čtení z nadřízeného systému. Jinak každý node umí číst jakékoli čidlo a počet sběrnic, jaký jste pod Arduinem schopen naprogramovat. To je od přenosové části odděleno.
Jinak BH1750FVI může mít dvě různé adresy, takže pokud máte na sběrnici jen dvě tato čidla, žádné pomocné adresní vodiče nepotřebujete. Každému čidlu pomocí pinu ADR nastavíte jinou adresu. S tím ovšem ten kód co používáte jaksi nepočítá.
Tady máte popsaný celý koncept:
https://www.mysensors.org/about/overview
Máte něco jako gateway, která propojuje síť senzorů do nějakého nadřízeného systému. Třeba Home Assistant má přímo modul pro spolupráci s touto sítí. Podrobnosti neznám, já používám Domoticz, který to má podobně. Dokonce můžete mít víc sítí - drátovou, rádiovou atd. Pro rádio a některé controllery funguje i jakési "DHCP" - nově připojený senzor dostane přiděleno ID po připojení. ( tohle zrovna nefunguje u těch drátových sítí )
Senzory v jedné síti mohou komunikovat i přímo mezi sebou.
Tady je popsaný ten protokol pro RS485:
https://www.mysensors.org/download/serial_api_20
Tady je kód pro gateway senzorů připojených k ní přes RS485 a gateway přes USB do PC:
tady pak ukázka pro jeden node na RS485 - konkrétně čidlo pohybu:
https://github.com/mysensors/MySensors/blob/master/examples/MotionSensorRS485/MotionSensorRS485.ino
Jinak já ten MySensors nepropaguji, jen to sleduji a když se mi to hodilo, tak jsem něco použil.
Nevím co přesně myslíte pod pojmem asynchronní čtení senzorů.
Tím mám na mysli, že běh Arduina není blokován (pozastaven) při čekání na data ze senzoru. Např. 1-wire teplotní senzory potřebují až 750ms na konverzi dat a třeba nejpoužívanější libka (DallasTemperature.h) v defaultním nastavení pokorně čeká na konverzi. Pod "asynchroní" mám na mysli to, že Arduino pošle na 1-wire požadavek, nečeká na jeho vyřízení (na konverzi) a místo toho obstarává jiné věci (jiné senzory). Až je konverze hotová, přečte si data.
Jinak BH1750FVI může mít dvě různé adresy, takže pokud máte na sběrnici jen dvě tato čidla, žádné pomocné adresní vodiče nepotřebujete. Každému čidlu pomocí pinu ADR nastavíte jinou adresu. S tím ovšem ten kód co používáte jaksi nepočítá.
To je pravda. Můj kód pracuje jenom s jednou adresou a pin ADDR používám de facto jako "chip select". Chtěl jsem mít kód maximálně flexibilní, aby se daly snadno přihazovat druhá, třetí, čtvrtá 1-wire sběrnice nebo druhý, třetí, čtvrtý BH1750FVI senzor. To, že počínaje druhým BH1750FVI senzorem musíte použít adresní drát, je daní za tu flexibilitu.
V koncepci MySensors prostě node pošle data když má co poslat. Většinou když dojde k jejich změně, pokud se nezměnila tak jednou za nějaký časový interval + je tam i nějaký "heartbeat". Nemusí se čekat na žádný pokyn pro čtení z nadřízeného systému.
V mé koncepci si u každého typu senzoru nastavíte časový interval čtení senzoru (jak často se má Arduino senzoru ptát na data) a hysterezi. Tj. jestli má Arduino posílat do nadřazeného systému všechna měření nebo jen hodnot překračující nějakou úroveň hystereze (pokud si dáte nenulovou ale velmi nízkou hysterezi, budete mít přeposílání "jen při jakékoliv změně"). Kombinaci hystereze + nucené přeposílání hodnot (přeposlání dat i když nedošlo k jejich změně) zatím nemám, díky za tip, pokud bude čas, tak implementuju.
Arduino na pokyny z nadřazeného systému nečeká, chová se podle intervalů a hysterezí nastavených v configu. Měl jsem v plánu i implementaci těchto "pokynů" z nadřazeného systému (tj. kromě periodického čtení senzorů byste si mohli nadřazeným systémem data vyžádat), ale nějak nebyla potřeba a zůstalo to v kategorii "TODO". Vlastně - trosky těchto plánů najdete na konci ve skeči 🙂 V tuto chvíli Arduino přijímá akorát příkaz na reset sebe sama.
vic se mi libi aby kazdy cidlo melo svuj mozek a posilalo data po necem normalnim. to i2c na velkou vzdalenost jeste asi zkusim, ale nejak se mi to nezda
Mozek.... mozek se musí bastlit a programovat a v neposlední řadě mozek zabere spoustu místa. Tam, kam čidla dávám (pod vypínače, dovnitř větráku v koupelně atd.) by se mi žádný mozek (tj. arduino + max485 nebo ethernet shield) ani náhodou nevešel. Viz třeba
https://www.vodnici.net/community/postid/10783/
zatim se asi cim dal vic se klonim k tomu modbusu - homeassistant ho umi nativne.
Pokud teda už chceš zkusit modbus, zvážil bych cestu miniaturních "bezmozkových" modbus čidel:
https://www.aliexpress.com/item/1005001987356811.html
https://www.aliexpress.com/item/4000146911851.html
https://www.aliexpress.com/item/4000146579383.html
https://www.aliexpress.com/item/32790103964.html
Než si ale s Ali objednáš mraky levných převodníků DS18B20 -> RS485, zvaž ještě jednu věc, která tu pokud vím ještě nepadla: topologie. Modbus je určený pro liniovou topologii. Jak se bude chovat, když připojíš 20 čidel do hvězdy? Nebude náhodou stejně nespolehlivý jako ty moje "nativní sběrnice" (a navíc pomalejší kvůli sekvenčnímu dotazování senzorů)? Stojí pak vymýšlení modbus převodníků u čidel za to?
jj jasne ze v pripade pouziti modbusu bych se snazil rovnou pouzit cidla co jedou po modbus pokud by to slo.
S hvezdicovou topologii mas pravdu no.
ach jo, vse ma nejaky komplikace. prozkoumam jeste ty mysenzors pres rs485
sběrnice pro modbus může být dost dlouhá, takže pokud máš volné páry, tak můžeš jít po jednom páru k čidlu, druhým se vracet a tím zas pokračovat k dalšímu čidlu.
Tak s tou velikostí je opravdu výhoda, něco tak malého jako samotné DS18B20 s procesorem neuděláte.
Jinak to asynchronní čtení znám spíš jako non-blocking, ale myslím, že u DS18B20 se takto dnes už řeší standardně a nečeká se těch 750ms na výsledek. Já bych si spíš představil podobné řešení i těch samotných příkazů z onewire knihovny. Tam bych čekal využití HW časovačů. Ale když kouknete do těch knihoven, tak je to samý delay a zákazy přerušení.
DHT je to samé, snad jen to i2c, když využívá HW procesoru, snad bude řízené přerušením, ale nemám čas se teď podívat do zdrojáků.
A pokud dobře počítám, tak reset 1wire sběrnice, odeslání adresy a načtení dat trvá okolo 2 ms. Za tu dobu AT Mega na 20MHz může vykonat cca 20 000 instrukcí. To moc asynchronně nevypadá.
