Navázání komunikace s koordinátorem.
Když už známe strukturu dat procházející přes seriový port, pokusme se navázat s koordinátorem základní komunikaci. To znamená odeslat "něco" přes seriový port, na co koordinátor zareaguje. Předpokladem je, že máte k počítači připojený koordinátor podporující protokol EZSP (Skyconnect, SOnOff, ...), správně nainstalovaný ovladač a máte připravený program, který umí odesílat a přijímat data přes seriový port. V jakém jazyce tento program máte napsaný je celkem jedno, moje příklady ale budou v pascalu, tedy Delphi Rio.
Nejprve si pojďme říct, že na komunikaci s koordinátorem a jeho prostřednictvím se všemi zařízeními v zigbee síti je potřeba asynchronní programování. To znamená, že v běžném provozu má jakýkoliv prvek v síti právo vyslat svou zprávu, aniž by k tomu byl od někoho vyzván. Tedy sítí se mohou šířit zprávy, které vznikly kdekoliv a kdykoliv. Takové zprávy se mohou kdykoliv objevit jako vstupní data na seriovém portu našeho programu. A náš program musí umět nejen detekovat přítomnost těchto náhodných dat, ale také je musí umět zpracovat, tedy porozumnět jim, a případně na ně reagovat. No, tato laťka je ještě hodně vysoko.
Ale nic se nejí tak horké, jak se to uvaří. Než se koordinátor a síť dostane do standardního provozního režimu, je potřeba nejprve vše inicializovat. Inicializaci zahajuje vždy uživatelský program. A to je spousta úkonů v klasickém stylu programování. Tedy vyšleme příkaz, počkáme na odpověď a potvrdíme její příjem. To je pro začátek všechno.
První příkaz - Reset koordinátora
Nejprve si musíme vysvětlit, že koordinátor je jakési rozhraní mezi sítí zigbee a ostatním světem. Tedy jako by se skládal ze dvou částí. Jedna část řídí síť zigbee a má na starosti organizování jejího provozu, třeba šifrování. Druhá část komunikuje s vnějším světem. Když mu z tohoto vnějšího světa pošleme příkaz reset, bude se týkat právě jen té části, která komunikuje s vnějším světem. Nezruší se ani šifrovací klíče, ani se neodpojí už spárovaná zařízení. Mluvím o tom proto, že prvním příkazem odeslaným do koordinátora musí být právě příkaz reset. Jeho tvar je:
1A C0 38BC 7E
První bajt je Control byte. Druhý bajt je vlastní příkaz Reset. Další dva bajty jsou CRC počítané z datového bajtu C0. Bude mít tedy vždy hodnotu 38BC. Poslední bajt je Flag. Z toho vyplývá, že pro příkaz Reset není použitá technika Stuffing. A nepoužívá se ani technika Pseudorandomize. Co všechno koordinátor provede po přijetí příkazu Reset se dozvíme v jeho odpovědi:
1A C1020B 0A52 7E
Opět není použit Stuffing ani Pseudorandomize. Význam jednotlivých datových bajtů:
- C1: Potvrzení přijetí příkazu Reset
- 02: Bude proveden HW reset: RESET_POWER_ON
- 0B: Bude proveden SW reset: RESET_SOFTWARE
Dohodnutí verze komunikačního protokolu
Další komunikace už probíhá standardním postupem, tedy:
- Uživatelský program (host) odešle příkaz koordinátorovi
- Koordinátor odpoví
- Uživatelský program odešle potvrzení, že odpověď koordinátora v pořádku přijal (ACK).
Tím je uzavřena jedna komunikační seance. Tyto seance jsou počítány v rozsahu 0 až 7 a jejich hodnota je vkládána do prvního Control bajtu. Stejně tak jsou počítána potvrzení o přijetí (ACK) a i toto číslo se ukládá do prvního Control bajtu. Proto musí mít uživatelský program dvě počítadla, kde si ukládá uvedená pořadí a při odesílání nového příkazu musí do Control byte vložit správnou hodnotu. Nesprávné číslo vyhodnotí koordinátor jako chybu komunikace a "zamrzne". Také se zde už používá technika Pseudorandomize a Stuffing.
Příkazem následujícím po Reset musí být dohodnutí formátu komunikačního protokolu. Protokol EZSP prošel dlouhý vývojem, v jehož průběhu byly přijaty i změny zpětně nekompatibilní. Pokud tedy chceme správně komunikovat s koordinátorem, musíme nejprve zjistit, jaký formát EZSP má implementovaný. To se provede tak, že se odešle Instrukce 00 - Verze ve formátu EZSP 4. Toto je jediný případ, kdy koordinátor rozumí starému formátu příkazu. Jeho povinností je odpovědět, jaký formát EZSP používá on. Tento formát je pak závazný i pro náš program. Následně tedy náš program odešle znovu instrukci Verze ale ve formátu, který používá koordinátor. Tím je dohodnuto, že i uživatelský program tento komunikační formát ovládá. Ve výpisu komunikace tedy můžeme za resetem najít následující sekvenci.
00 00 00 04 // host pošle instrukci verze 04 ve starém formátu 00 8000 09 02 1071 // standardní odpověď, zde verze 09 ACK // potvrzení příjmu odpovědi 00 0001 0000 09 // verze 09, potvrzení, že ji host umí 00 8001 00 09 02 1071 // standardní odpověď, tedy znovu verze 09 ACK // potvrzení příjmu odpovědi
To vše samozřejmě po procesu Pseudorandomize, přidání CRC, procesu Stuffing a přidání Flag bajtu. ACK znázorňuje potvrzení příjmu odpovědi. Celou sekvenci si můžete prohlédnout v úvodu mého logu. Můj koordinátor Skyconnect hlásí formát EZSP 0x09, SOnOff má implementovaný formát EZSP 0x0C. Význam bajtů 02, 10, 71 najdete v dokumentaci UG100 u instrukce 0000 - Version (str. 48).
Uvedený postup má jeden nepříjemný důsledek. Pokud chceme psát "univerzální" program, musíme mít implementovány všechny existující formáty protokolu EZSP. Protože dopředu nikdy nevíme, jakou verzi bude připojený koordinátor používat. Když se podíváte do knihovny belows, která řeší komunikaci protokolem EZSP pro Python, skutečně tam najdete verze 4 až 13. Z toho by se dalo vycházet pro další studium. Já ale zatím pracuji s logem reálné komunikace, vím tedy jistě, že instrukce z tohoto logu pro mé koordinátory fungují. Víc v tuto chvíli není předmětem mého studia.