LoRa2MQTT

www
Odpovědět
kiklhorn
Moderátor
Moderátor
Příspěvky: 901
Registrován: 03. červenec 2021, 18:35
Dal poděkování: 107 poděkování
Dostal poděkování: 210 poděkování

LoRa2MQTT

Příspěvek od kiklhorn »

Mám nápad na na využití LoRa komunikujích zařízení v HA.

Gateway - ESP32 + LoRa chip. Jednou naprogramovaná, pak už nesahat. Něco jako koordinátor v ZigBee.
GW by si měla umět poskládat informace o koncových zařízeních a prezentovat je jako zařízení do HomeAssistant.
Říct "ACK, spi. Nebo teď neusni něco pro tebe mám" Nebo tebe ještě neznám, Co umíš a co potřebuješ.

Koncová zařízení - bateriová - třeba úsporné Heltec Cube boardy
Cortex M0+ (5uA .. 7mA) a Lora čip přes SPI. Arduino kompatibilní verze.

Konce se budou budou autorizovat (číslo sítě?) a sdělovat své schopnosti.(sensor/relé).

Pojd´me navrhnout nějakou úspornou strukturu komnkc. Typu první bit = komunikuji otevřeně/šifrovaně, autorizace, unik. ID, typ zprávy.
Jmenuji se, poskytuji/požaduji, timeout pro offline
Data mých senzorů a stavy aktuátorů
Na příjmu budu za x sec.
ACK povel přijat
A další...
Datově co nejúspornější a se zaměřením na co nejdelší spánek.

Vůbec vymyslet celý protokol komunikace řízený konci (komunikují jen když jsou vzhůru a po odeslání dat čekají x ms na příjmu než opět usnou)
a chování bude modifikovat GW.

Zprávu bych si představoval třeba (také téma k diskuzi) bitově: zzzzzzxy aaaaaaaa [m..m][c..c] x=šifrováno? y=komprese? zzzzzz="magic number" aaaaaaaa=adresát m=payload c=nějaké crc payloadu
Přijímač se podívá zda odpovídá magic number. Pokud ne tak se nejedná o "moji LoRa2mqtt" komunikaci a zprávu zahodí.
Přijímač se podívá zda adresa je jeho/zajímá jej, jinak zprávu zahodí.
Vezme m..m, spočítá CRC Nesouhlasí? Zprávu zahodí.
Všechno dosud souhlasí? Dešifrace, dekomprese, zpracování.
Byl by vhodný jako nosič informace komprimovaný json?
Komprese v tom případě povinná a šifrování volitelné? Můžeme mít omezené prostředky a údaj o teplotě asi šifrovat nepotřebujeme.
Klíče by asi stačilo symetrické - nadefinuji si jej pri programování GW a budu jej používat i na zařízeních. To samé s těmi šesti bity "magic number"

Prosím diskuzi.
Vše co si přinesu domů je buď Shelly, nebo to skončí buď pod ESPhome nebo pod Zigbee2mqtt.
Ajťák co pamatuje BBS a OS/2 Warp a je mu jedno o jaký systém nebo síťařinu běží.
HA OS jako jedna z Proxmox VM na Odroid H3+/64GB https://github.com/tteck/Proxmox

WA_V
Nováček na fóru
Nováček na fóru
Příspěvky: 5
Registrován: 08. únor 2023, 17:39
Dal poděkování: 6 poděkování
Dostal poděkování: 1 poděkování

Re: LoRa2MQTT

Příspěvek od WA_V »

To je super nápad a moc se mi to líbí.
Hlavně ta myšlenka GW.
Já to mám zatím nastavený jen jako jednosměrnou komunikaci, ale tohle podstatně rozšiřuje možnosti. Bude se moct například ovládat relé, nebo upravit dálkově parametry. To nemá chybu.
Prozatím jsem dám, co mi na tom konci visí a co by viset mohlo:
SHT 40 teplota a vlhkost
https://www.laskakit.cz/laskakit-sht40- ... 0IQAvD_BwE
T114 Anemometr k meteostanicím WH1080 a WH1090
cena 148 Kč
princip: jazýčkové relé, co otáčka to puls, je potřeba vřadit pullup, výstup RJ11 - prostřední pár, krajní pár je propojen s heading čidlem viz níže
výpočet rychlosti:
v m/s násobit konstantou 0.005560619
(km/h ještě x 3.6)
vyzkoušený timeout 5s
pro vyhlazení klouzavý průměr 20/20

T115 Ukazatel směru větru k meteo WH1080 a WH1090
cena 190Kč
princip:
8 jazýčkových relé po 45° na každém visí rezistor
výpočet úhlů z měření odporu v mezipoloze sepnuty dva sousední rezistory
je třeba zajistit napájení konstantním referenčním napětím, vřadit dělič napětí s 10k a pak na ADC
tabulka úhel vs odpor:
0 33k S
22,5 6,57k
45 8,2k SV
67,5 891
90 1k Z
112,5 688
135 2,2k JV
157,5 1,41k
180 3,9k J
202,5 3,14k
225 16k JZ
247,5 14,12k
270 120k Z
292,5 42,12k
315 64,9k SZ
337,5 21,88k
správně naorientovat kompasem - udělat na snímači rysku, nenašel jsem žádné označení 0 polohy
Pro stabilizování kmitání při poryvech počítat cyklicky medián

T116 Srážkoměr k meteostanicím WH1080 a WH1090
cena 181 Kč
princip: dvě stejné nádobky na ose, při naplnění se překlopí a vylije a plní se druhá při překlopení impuls z jazýčkového relé
1impulz = 0.2794mm srážek
internal_filter: 13us
update_interval: 60s
denní souhrn : riemanův integrál
pulup, mezi výstup a zem 10pikoF
RJ 11 prostřední pár
čidlo osvitu ADC z FVP ???
čidlo UV ???
čidlo vlhkosti půdy ???
čidlo výšky hladiny /sněhu ???
čidlo pohybu v zóně PIR ???
čidlo uzavření /otevření ???
čidlo průtoku ???

WA_V
Nováček na fóru
Nováček na fóru
Příspěvky: 5
Registrován: 08. únor 2023, 17:39
Dal poděkování: 6 poděkování
Dostal poděkování: 1 poděkování

Re: LoRa2MQTT

Příspěvek od WA_V »

Máš tam těch informací hodně. Takže útržkovitě:
1. Schema headru se mi moc líbí je to dokonale promyšlený
2. Json/data bych zatím nekomprimoval, myslím že toho nebude tak moc a nevím jakou by s tím mělo esp režii.
3. CRC určitě jo
4. Šifrování bych nechal až na systémy, kde bude centrála ovládat konce, nebo opačně hlídal perimetr PIR/kontakty

kiklhorn
Moderátor
Moderátor
Příspěvky: 901
Registrován: 03. červenec 2021, 18:35
Dal poděkování: 107 poděkování
Dostal poděkování: 210 poděkování

Re: LoRa2MQTT

Příspěvek od kiklhorn »

Promyšlený header moc není, je to jen první nápad.
Radiové spektrum je omezené, u tohoto provozu max. 1% času vysílání je dané normou.
Na rozdíl od LoRaWAN bude využíván jen jeden kanál na jednu GW.
V případě WiFi tě 50m vzdálený soused na stejném kanále pravděpodobně příliš rušit nebude i když jde o časově spojitý provoz, tady u LoRa se bavíme o stovkách metrů až desítkách kilometrů byť s výhodou 1% airtime. Tedy čím kratší zpráva, tím větší šance že dojde naprosto v pořádku.

Právě z důvodu co nejkratší zprávy mne napadají ty dvě varianty - buď binární zpráva nebo komprimovaný json.
Pocitově si myslím že binární zpráva by mohla být jak kratší tak méně náročná na slaboučký procesor konce,
komprimovaný json zas pohodlnější. Ale nemám žádné výpočty, žádné porovnání algoritmů.

[spoiler]Příklad - mám jen jedno čidlo, měřící venkovní teplotu, posílající jen číslo, bez jakékoli identifikace odesílatele, příjemce, prostě vzduchem jde jen číslo.

Pokud to pošlu čitelně v ascii -23.5
00101101 00110010 00110011 00101110 00110101
Pokud si ale řeknu - teplotu chci nacpat do jednoho byte, vlastní formát.
jednotlivé bity:
1. = znaménko -/+
2..7 = číslo 0..63
8. = půlstupeň

tak -23.5 zapíšu takto
10101111

To je 1/5 původní délky zprávy, k dispozici mám rozsah od -63.5 do +63.5 s rozlišením půl stupně.
Je to krátké, procesor to nic nestojí (možná ještě míň než ASCII), doba vysílání se zkrátí na 1/5. Je to na každý domácí teploměr dostatečné?

(Jasně, vím že tu mám kladnou a zápornou nulu, že by se dal použít klasický kruh a mít rozsah ještě o jeden stupeň vyšší)[/spoiler]
Vše co si přinesu domů je buď Shelly, nebo to skončí buď pod ESPhome nebo pod Zigbee2mqtt.
Ajťák co pamatuje BBS a OS/2 Warp a je mu jedno o jaký systém nebo síťařinu běží.
HA OS jako jedna z Proxmox VM na Odroid H3+/64GB https://github.com/tteck/Proxmox

WA_V
Nováček na fóru
Nováček na fóru
Příspěvky: 5
Registrován: 08. únor 2023, 17:39
Dal poděkování: 6 poděkování
Dostal poděkování: 1 poděkování

Re: LoRa2MQTT

Příspěvek od WA_V »

S tim binárním přenosem máš i podle mého náhledu pravdu. Pak stačí i jednoduché binární operace na dekódování. Stejně i tak z těch čidel jdou informace velmi úsporné o velikosti několika bajtů. Ještě k tý hlavičce. Je to sice Tvůj první nástřel ale nevidím tam nic, co by mi nedávalo smysl. Stelně se teprve až praktickýma zkouškama ukáže co to bude chtít navíc a co je naopak zbytečný. Pokud někdo další nepříjde s přesvědčivými argumenty, rozhodně jsem za binární kódování.
Popravdě ty věci kolem vysílacích norem neznám vůbec. Jen co je volný a jakým maximálním výkonem můžeš zářit. Budu si to muset nastudovat. Co vidím na svých přenosech, tak se signál dere cca přes né více jak deset wifi AP a je to v pohodě. Řekl bych, že to za celý den zahodí tak deset paketů z několika tisíc. Je ale fakt, že vysílám pakety o velikosti několika bajtů. Podrobněji jsem to neanalyzoval, protože využívám std. arduino knihovny.

kiklhorn
Moderátor
Moderátor
Příspěvky: 901
Registrován: 03. červenec 2021, 18:35
Dal poděkování: 107 poděkování
Dostal poděkování: 210 poděkování

Re: LoRa2MQTT

Příspěvek od kiklhorn »

Popravdě ty věci kolem vysílacích norem neznám vůbec
Měl jsem někde daleko přehlednější zhuštěnou tabulku, ale tady jsou všechny informace:
https://eur-lex.europa.eu/legal-content ... 32019D1345
https://jwcn-eurasipjournals.springerop ... 019-1502-5
Vše co si přinesu domů je buď Shelly, nebo to skončí buď pod ESPhome nebo pod Zigbee2mqtt.
Ajťák co pamatuje BBS a OS/2 Warp a je mu jedno o jaký systém nebo síťařinu běží.
HA OS jako jedna z Proxmox VM na Odroid H3+/64GB https://github.com/tteck/Proxmox

kiklhorn
Moderátor
Moderátor
Příspěvky: 901
Registrován: 03. červenec 2021, 18:35
Dal poděkování: 107 poděkování
Dostal poděkování: 210 poděkování

Re: LoRa2MQTT

Příspěvek od kiklhorn »

1) Šifrování (AES128-CBC) by neměl být problém na ničem současném, když to zvládne i 8bit Arduino, případně i s akcelerací na Gateway s ESP32.

https://uart.cz/1466/sifrovani-v-arduinu/
https://github.com/ffosilva/AES32

CRC podobně - buď pomalu, nebo s minimem paměti.

https://api.riot-os.org/group__sys__che ... crc16.html
https://github.com/RobTillaart/CRC

A nejde zapnout CRC přímo na SX chipu? Různá dokumentace míchá LoRa a LoRaWAN protokoly, budu muset projít podrobněji.

Bude potřeba otestovat.

2) Kalkulačka a manuály
https://lora-developers.semtech.com/bui ... calculator
https://lora-developers.semtech.com/doc ... documents/
Zajímavé z hlediska spotřeby u SX1276: https://semtech.my.salesforce.com/sfc/p ... 0fIAQuNLXY
U novější SX1262 se dá dostat níže, ale to není zrovna často se vyskytující modul https://iopscience.iop.org/article/10.1 ... 012092/pdf

3) Uvažuji správně že koncová zařízení obsahující prvek jako relé, LED apod. ovládané z HA by měly být "stále" online?

Pokud vezmu graf spotřeby s kombinací sleep, CAD, případný příjem s nejnižším bitrate (podporuje to knihovna?) tak se dostávám na spotřebu při "stálém" příjmu 10mA po cca čtvrtinu času - takže reálně cca 2.5mA (snad to odvozuji správně). Heltec moduly co obsahují navíc k radiu i cortex M0 (ASR6501/PSoC4000) tak udávají spotřebu procesoru max 7mA.
Tedy teoreticky s koncovým zařízením "stále" na příjmu se dostaneme pod průměrných 10mA (radio + MCU), spíš ještě daleko níž. To bych řekl že otevírá i zajímavé možnosti při napájení z baterie + solár (tu stejně bude potřeba dimenzovat pro to ovládané relé nebo motor) a https://heltec.org/cubecell_overview/ dev moduly s ním i počítají.

Navíc asi bude možné u věcí kde to nevadí přihodit 0.5-1.5s deep sleep (interval než mqtt v HA vrátí zpět původní stav přepínače pokud state zůstane nezměněn po odeslaní command) a vyřešit to časovaným násobným odesíláním ze strany GW

Senzorová koncová zařízení jsou asi jasná - většinu času snad budou spát. A jestli spotřeba ve spánku bude 50 nebo 500nA je pro teď asi úplně jedno.

4) Vzhledem k tomu co mám teď k dispozici tak chci (snad tento víkend)
a) - funkční pracovní verzi komunikačního protokolu
b) - implementaci alespoň pár základních typů senzorů a akčních členů podporovaných HA
c) - udělat základní demo s použitím 3ks TTGO T-Beam
Vše co si přinesu domů je buď Shelly, nebo to skončí buď pod ESPhome nebo pod Zigbee2mqtt.
Ajťák co pamatuje BBS a OS/2 Warp a je mu jedno o jaký systém nebo síťařinu běží.
HA OS jako jedna z Proxmox VM na Odroid H3+/64GB https://github.com/tteck/Proxmox

WA_V
Nováček na fóru
Nováček na fóru
Příspěvky: 5
Registrován: 08. únor 2023, 17:39
Dal poděkování: 6 poděkování
Dostal poděkování: 1 poděkování

Re: LoRa2MQTT

Příspěvek od WA_V »

Koukám, že si to pojal ultimativně včetně řízení koncových zařízení. Možná by stálo za úvahu to rozlišit.
1. jen neřízené čidla
2. zařízení s akčním členem
To 1. by se lehce dalo řešit jen z aku a 2. by muselo mít lepší zdroj.

kiklhorn
Moderátor
Moderátor
Příspěvky: 901
Registrován: 03. červenec 2021, 18:35
Dal poděkování: 107 poděkování
Dostal poděkování: 210 poděkování

Re: LoRa2MQTT

Příspěvek od kiklhorn »

Jakmile jsem se snažil řešit zpracování jen trochu složitější datové struktury v callback funkci tak ESP padalo.
Zjistil jsem
a) callback funkce jsou řešené jako obsluha přerušení (a tedy by to mělo být krátké, žádný delay, a raději ani výpis na sériovou linku)
b) v obsluze přerušení ESP32 se nedá používat FPU
c) kompilátor (minimálně pod Arduino frameworkem) je tak ... že i v kódu přerušení se snaží pro některé datové typy použít FPU

Takže mne to sice stálo dva dny, ale teď v callback funkci jen data uložím do bufferu o maximální možné velikosti zprávy (256 byte) a nastavím příznak "data jsou k dispozici". A co si s nimi v hlavní smyčce programu, kde mohu používat vše, udělám je už téměř neomezené.

Takže nějaký kód v noci asi publikovat stihnu, ale ne ve stavu v jakém jsem chtěl.
Vše co si přinesu domů je buď Shelly, nebo to skončí buď pod ESPhome nebo pod Zigbee2mqtt.
Ajťák co pamatuje BBS a OS/2 Warp a je mu jedno o jaký systém nebo síťařinu běží.
HA OS jako jedna z Proxmox VM na Odroid H3+/64GB https://github.com/tteck/Proxmox

kiklhorn
Moderátor
Moderátor
Příspěvky: 901
Registrován: 03. červenec 2021, 18:35
Dal poděkování: 107 poděkování
Dostal poděkování: 210 poděkování

Re: LoRa2MQTT

Příspěvek od kiklhorn »

Test rychlosti:

Posílám stoznakový řetězec a měřím dobu od reakce na tlačítko do dokončení odeslání.

kódování 4/6, CRC

SF7, BW 250000 - 210ms
SF10 BW 125000 - 1240ms

Podstatné nízkoúrovňové věci mi už fungují bez pádů, je potřeba dopsat alespoň nějakou state-machine.

Na té nižší úrovni si chci ještě pohrát s volbami pro
LoRa.enableInvertIQ();
LoRa.disableInvertIQ();

Kdy snad půjde zvolit aby klienti "neslyšeli" sebe navzájem a zabývali se pouze komunikací s GW a naopak - aby GW neposlouchala případnou další GW. Bude to nějaká drobná úspora spotřeby klientů.
Uvažuji nad scénářem se dvěma paralelními GW. Buď na dvojrychlostní síť - rychlé klienty třeba do 200m a pomalé na větší vzdálenost, nebo dva různé kanály pro velké množství zařízení. Neříkám že to budu realizovat rovnou, ale budu s tím počítat v protokolu.

Poznámky: //průběžně doplňováno
Každý klient by měl mít na GW záznam se stavem
- klient zahajuje komunikaci, kontaktuje GW
GW odpovídá buď
- rychlý ACK pokud je klient zná a použije přijatá data. (a klient může jít hned spát)
- klient stav známý

- rychlý SET + data pro klienta
- čekání na potvrzení od klienta o splnění příkazu

- rychlý NACK, repeat -> známý klient, zkomolená data

- WAIT (kliente čekej na příjmu, nebo se přihlas za třeba 500ms? pro další příkaz) pokud pro GW je jeho stav
- stav neznámý -> pokus o načtení z HA přes MQTT ... klient přechodný stav čekající s timeoutem
- stav nový(nepředstavený) = HA jej nezná
-> GW pošle klientovi žádost o představení a klient zahájí protokol ADOPT - představení (názvy, typy, (senzorů, aktuátorů, dat) a GW nakonfiguruje klienta přes autodiscovery v HA

- ADOPT
- stav nový -> stav známý

- stav chyba (a z ní v dalším kole ACK, NACK, ADOPT...)
- pokud známý klient posílá neúplná, nebo jiný typ dat než očekávaný, nebo mimo rozsah, nebo dlouho mlčí (třeba po změně SW klienta)


Implementovat Request/Response úrovně (žádné, jednoduché, dvojité potvrzování)

--- udělat buffer, frontu zpráv k odeslání. Odesílány budou okamžitě po přijetí zprávy od adresáta
Vše co si přinesu domů je buď Shelly, nebo to skončí buď pod ESPhome nebo pod Zigbee2mqtt.
Ajťák co pamatuje BBS a OS/2 Warp a je mu jedno o jaký systém nebo síťařinu běží.
HA OS jako jedna z Proxmox VM na Odroid H3+/64GB https://github.com/tteck/Proxmox

Odpovědět

Zpět na „LoRa“