ZigBee přes Tasmotu 4: Automatické posílání dat senzorem

ZigBee přes Tasmotu 1: Hardware
ZigBee přes Tasmotu 2: Napojení ZigBee senzorů a aktorů na Loxone
ZigBee přes Tasmotu 3: Neznámé ZigBee zařízení (Danalock)
ZigBee přes Tasmotu 4: Automatické posílání dat senzorem

TL;DR

Přes Tasmotu můžeme nastavit koncové ZigBee zařízení tak, aby automaticky posílalo data (změny “attributes”) buď na jiné koncové zařízení nebo na koordinátora (Tasmotu) a tedy i na Loxone. Automatické posílání dat na Tasmotu si u většiny senzorů nastaví Tasmota sama. Pokud ale chceme dostávat data z pro Tasmotu neznámého clusteru (například chceme automaticky dostávat atribut LockState z clusteru 0x0101 Door Locks), musíme si binding nastavit sami příkazem:

ZbBind {"Device":"ZB4.01_Obyvak_zamek","Cluster":"0x0101"}

Stejně tak můžeme na koncovém zařízení nastavit jak často a s jakou citlivostí (hysterezí) má data posílat. Například frekvenci a citlivost posílání dat z teplotního senzoru můžeme snadno nastavit pomocí příkazu:

ZbSend {"Device":"ZB2.02_Digestor","Config":{"Temperature":{"MinInterval":30,"MaxInterval":3600,"ReportableChange":0.2}}}

Příkazy pro koordinátora, příkazy pro koncové zařízení

Ještě, než se pustíme do nastavování koncového zařízení, musíme si uvědomit, že některé ZigBee Tasmota příkazy směřují na koordinátora (tj. ZigBee modul připojený k ESP32 čipu), některé  příkazy směřují na samotná koncová zařízení.

Příkazy pro koordinátora (tj. pro ESP32 resp. pro rádiový modul k němu připojený) jsou mimo jiné:

• ZbConfig (nastavení ZigBee sítě vč. kanálu)
• ZbForget (smazání informací o koncovém zařízení)
• ZbStatus (zobrazí uložené informace o koncovém zařízení)
• ZbName
• ZbPermitJoin
• ZbScan

Příkazy pro koncová zařízení jsou mimo jiné:

• ZbBind
• ZbBindState
• ZbLeave
• ZbPing
• ZbProbe
• ZbSend

Proč je důležité to rozlišovat? Za prvé, zatímco koordinátor reaguje na příkazy okamžitě, příkaz pro koncové zařízení většinou končí chybou. Nenechte se tím vystrašit a odradit! Pokud narazíte na chybu

{"ZbRouteError":{"ShortAddr":"0xA291","Status":66,"StatusMessage":"MAC_INDIRECT_TIMEOUT"}}

tak to má (většinou) prozaické vysvětlení. Koncové zařízení (senzor) je napájené baterií a z důvodu úspory energie přešlo do režimu spánku a vypnulo své ZigBee rádio. Pokud na něj chcete poslat nějaký příkaz, musíte ho nejdřív probudit, například změnou teploty okolo senzoru, otevřením/zavřením kontaktu atp. Senzor se na pár sekund probudí a máte šanci mu něco poslat.

Za druhé, zatímco první skupinou příkazů nastavujeme koordinátora (Tasmotu), druhou skupinou příkazů můžeme nejenom číst a ovládat, ale i nastavovat koncová zařízení. A tato nastavení (“bindings”, “groups” a “attribute reporting”) se ukládají do paměti koncových zařízení, nikoliv koordinátora!

Bindings

V předchozím díle tutorialu jsme si ukázali jak si můžeme vyžádat data (attribute) od koncového ZigBee zařízení. Probíhalo to podobně jako u Modbusu: poslali jsme příkaz 0x00 “Read Attribute” na konkrétní atribut v rámci konkrétního clusteru a v odpovědi nám ZigBee zařízení poslalo požadovaná data. Ale na rozdíl od Modbusu, koncová zařízení ZigBee umí data odesílat i sama! Slouží k tomu “bindings”.

Nejdřív trocha teorie. Začneme tím, že rozlišíme “pairing” a “binding”. Párování znáte – párujete koncové zařízení ke koordinátorovi (ZigBee hub). Je to vlastně připojení k síti (ke koordinátorovi) na fyzické vrstvě. Naopak binding je propojení na datové vrstvě mezi koncovým zařízením a jiným zařízením (jiným koncovým zařízením nebo koordinátorem) nebo skupinou zařízení (“group” – viz níže). Binding se vždy nastavuje na konkrétní cluster: pokud na koncovém zařízení nastavíte “binding”, bude automaticky odesílat cílovému zařízení zprávu, pokud se změní hodnota nějakého attributu v daném clusteru.

ZigBee “binding” se možná dá přirovnat k MQTT “publish” a “subscribe”, ale s jedním podstatným rozdílem: MQTT je centralizovaný protože informace o tom co se komu má (pře)poslat jsou uložena centrálně v “MQTT broker” (např. Mosquitto). Naopak ZigBee bindings jsou decentralizované, protože je nastavujeme na koncovém zařízení. Každé ZigBee zařízení (vč. zdánlivě “pitomých” senzorů a tlačítek) můžeme naučit co (“Cluster”) má komu (“ToDevice” nebo “ToGroup”) posílat. Odesílání dat potom probíhá automaticky, dokonce i když odstraníte koordinátora ze sítě! Počet bindings, které si může zařízení zapamatovat, je omezený, ale v jednu chvíli můžete mít nastaveno několik různých bindings na různá cílová zařízení (resp. cílové skupiny) současně.

OK, trocha praxe. Nejdřív by stálo za to zjistit, kam všude ZigBee zařízení svá data posílá. Nejdřív dotaz na Sonoff čidlo vlhkosti a teploty:

ZbBindState ZB2.02_Digestor

Z výsledku zjistím, že tenhle senzor má v paměti uložené celkem 3 bindings týkající se clusterů 0x0001 (Power Configuration, ve kterém je i atribut ke stavu baterky), 0x0402 (Temperature Measurement) a 0x0405 (Relative Humidity Measurement). Všechny bindings mají stejné cílové zařízení “ToDevice”, v mém případě tajuplné “0x04CD15FEDEB49F81”. To není nikdo jiný než moje Tasmota. Jak je možné, že sensor má v paměti tyhle 3 bindings? No protože ho to Tasmota naučila poté, co se s tímto senzorem spárovala. Během “párování” senzoru Tasmota zjistila, že se jedná o senzor vlhkosti a teploty a rovnou odělala i “bindování” – poslala na něj tři příkazy ZbBind, kterými senzor nastavila tak, aby jí posílal změny ve třech clusterech, ve kterých jsou atributy, které ji zajímají (tj. stav baterky v %, teplota a vlhkost). Teď zkusíme Danalock:

ZbBindState ZB4.01_Obyvak_zamek

mi vyplivne jenom jedno binding (na cluster 0x0001 – baterka):

{"ZbBindState":{"Device":"0x76C6","Name":"ZB4.01_Obyvak_zamek","Status":0,"StatusMessage":"SUCCESS","Total":1,"Start":1,"Bindings":[{"Cluster":"0x0001","Endpoint":1,"ToDevice":"0x04CD15FEDEB49F81","ToEndpoint":1}]}}

Tasmota bohužel neumí door locks, takže během párování udělala automatické binding jenom na baterku. To musíme napravit tím, že naučíme Danalock nové binding na cluster 0x0101 (Door Lock) pomocí příkazu ZbBind (dokumentaci k tomuto příkazu najdete zde). “ToDevice” vynecháme, což znamená, že cílovým zařízením odesílaných dat bude Tasmota samotná:

ZbBind {"Device":"ZB4.01_Obyvak_zamek","Cluster":"0x0101"}

Od této chvíle bude Danalock automaticky posílat Tasmotě (a tedy i Loxonu) zprávu vždy když ručně zamknu nebo odemknu zámek (tj. vždy když se změní atribut 0x0000 “LockState” v clusteru 0x0101 “Door Lock”).

Podobným způsobem můžete udělat binding mezi jedním koncovým zařízením a jiným koncovým zařízením. Použijete opět příkaz ZbBind, ale doplníte do něj “ToDevice”. Jak už jsme se zmínili výše, v tomto případě bude zdrojové zařízení posílat data a příkazy přímo na cílové zařízení, i když bude koordinátor odpojený ze sítě. Pokud bude koordinátor v síti přítomný, bude “v kopii” dostávat zprávy, které si mezi sebou koncová zařízení posílají.

Pro zrušení propojení použujeme příkaz ZbUnbind. Pokud zadáme “ToDevice”, ruší se binding na dané cílové zařízení. Pokud jej vynecháme, smaže se binding na Tasmotu, např:

ZbUnbind {"Device":"ZB4.01_Obyvak_zamek","Cluster":"0x0101"}

Groups

ZigBee protokol umí sloučit vícero zařízení do “groups”. Přesněji řečeno, můžete své ZigBee zařízení naučit, aby se stalo členem nějaké ZigBee skupiny (group). Jakmile máte zařízení přiřazená do skupiny, můžete příkazy ZbSend, ale i ZbBind posílat nikoliv na jedno konkrétní zařízení, ale na celou grupu. V praxi tak můžeme provázat (“binding”) jedno zdrojové zařízení (například tlačítko) s celou skupinou cílových zařízení (např. ZigBee žárovek) najednou.

Podobně jako “bindings” (informace o tom, jakému koncovému zařízení nebo koncové skupině se mají posílat informace z daného clusteru), tak i informace o členství v “groups” není uložena v koordinátorovi (Tasmotě), ale v paměti samotných koncových zařízení. Zatímco ale “bindings” umí udělat všechna ZigBee zařízení, připojování do skupin umí pouze některá z nich – ta která umí cluster 0x0004 (Groups). Bližší info ke skupinám najdete v dokumentaci.

Attribute Reporting

Když jsem si pořizoval první ZigBee senzory, žil jsem v mylné představě, že frekvence posílání dat je “natvrdo” nastavená v každém senzoru. Dokonce jsem vybíral senzory podle toho, jak často a s jakou citlivostí měří a posílají data… Ve skutečnosti si frekvenci (resp. citlivost) posílání dat můžete sami nastavit v přes Tasmotu! To má obrovský význam u bateriových senzorů – sami si určujete, jak často se má zařízení probouzet, zapínat rádio a odesílat data podle toho, co je pro vás důležitější: výdrž baterie nebo četnost a citlivost (přesnost) odessílání dat?

Attribute reporting je vlastně doplňkem k bindings. Přes bindings si na úrovni celého clusteru nastavujete, kam se mají automaticky posílat data. Přes attribute reporting si na úrovni jednotlivých attributes nastavujete, jak často se mají data posílat.

ZbSend {"Device":"ZB4.01_Obyvak_zamek","Config":{"LockState":{"MinInterval":1,"MaxInterval":3600,"ReportableChange":0}}}

Ve skutečnosti se jedná o generický command (0x06 “Configure Reporting”) se třemi parametry:

• “MinInterval” je nejkratší možný interval mezi zprávami. I kdyby se hodnota atributu měnila častěji, nová zpráva se nepošle dříve, než po uplynutí této doby.
• “MaxInterval” je nejdelší možný interval mezi zprávami, musí být vždy větší než MinInterval. Po uplynutí této doby pošle zařízení zprávu, i když se hodnota atributu od předchozí zprávy nezměnila. “MaxInterval” můžete využít při validaci v Loxonu: u virtuálního UDP vstupu si do políčka “Překročení časového limitu při příjmu” dejte hodnotu “MaxInterval” navýšenou o pár sekund. Pokud Loxone nedostane ani po uplynutí “MaxInterval” zprávu od daného senzoru, Loxone vyhodí chybovou hlášku a vy budete vědět, že senzor je nedostupný (pravděpodobně se vybila baterka).
• “ReportableChange” nastavuje citlivost senzoru. Pokud je změna atributu větší než zde nastavená hodnota, zařízení pošle zprávu. Nula znamená “při jakékoliv změně” (hodí se u diskrétních proměnných jako je právě LockState). U spojitých proměnných (teplota, vlhkost) můžete použít i desetinnou tečku.

Dávejte si pozor u bateriových zařízení, která usínají (a vypínají rádio). Pokud nastavíte vysokou “ReportableChange”, zařízení usne na velmi dlouhou dobu (třeba i několik hodin), vypne si rádio a vy mu nebudete moci poslat žádný další příkaz (ani příkaz na snížení “ReportableChange”). Pak už pomůže jenom nové párování.

Při párování totiž Tasmota automaticky provádí nejenom auto-binding na clustery, ze kterých chce od senzoru dostávat data (viz výše), ale zároveň nastavuje “attribute reporting” na defaultní hodnoty. Pokud vás zajímá, u kterých atributů to dělá a jak vysoké jsou ony defaultní hodnoty, podívejte se do souboru /tasmota/tasmota_xdrv_driver/xdrv_23_zigbee_8_parsers.ino a vyhledejte si const Z_autoAttributeReporting. Jednotlivé parametry (např. USE_ZIGBEE_MAXTIME_BATT) jsou konfigurovatelné při kompilaci Tasmoty, jejich defaultní hodnoty najdeme v /tasmota/my_user_config.h , kde zjistíme, že defaultní hodnota “MaxInterval” pro BatteryPercentage je 4*60*60 sekund. Tím se nám vysvětluje, proč žádné ZigBee zařízení (dokonce ani okenní kontakt, který se nehýbe) nemá “lastseen” větší než 4 hodiny – každé 4 hodiny se totiž probudí, zapne své rádio a pošle na Tasmotu zprávu o stavu baterky. A pokud ani tuto zprávu tu nepošle a lastseen stoupne nad ony 4 hodiny, znamená to, že zařízení se dostalo mimo dosah signálu nebo mu došla baterka.

Pokud byste někdy potřebovali spustit autobindovací rutinu (vč. nastavení reportingu na defaultní hodnoty) ručně, můžete použít příkaz ZbProbe:

ZbProbe ZB2.02_Digestor

OK a poslední věc. Pokud jste si na senzorech nastavili vlastní hodnoty attribute reporting, poznamenejte si ty hodnoty někam stranou (třeba do poznámky v Loxone Configu), protože:

• Bohužel není způsob, jak se zařízení zpětně dotázat na aktuálně nastavené hodnoty.
• Při příštím párování Tasmota automaticky přepíše vaše hodnoty reportingu na defaultní.

Tak a to je vše…..

Pomohl Vám náš blog? Chcete nás podpořit? I málo udělá radost 😉