
Witajcie moi drodzy.
Przedstawię tutaj krok po kroku proces pisania otwartego oprogramowania dla modułu WiFi XR809/XR3 na przykładzie czujnika otwarcia drzwi. Mój firmware dla niego będzie kompatybilny z Tasmota HTTP i pozwoli używać go niezależnie od serwerów producenta. Da nam to również kompatybilność z Home Assistant i Tasmota Control. Być może będzie to pierwszy taki firmware open source w sieci dla tego modułu, gdyż dużo wzmianek o nim nie znalazłem.
Oprogramowanie to tutaj powstanie w języku C na ARM Cortex-M4F i będzie to moje pierwsze starcie z ARM.
Co zyskamy z utworzenia otwartego oprogramowania?
Tutaj jest identyczna sytuacja jak z ESP8266 i Tasmotą/Domoticzem w porównaniu do firmware producentów. Używając otwartego firmware zyskujemy:
- niezależność od serwerów producenta (np. jak producent upadnie to nasze urządzenie może dalej działać)
- brak śledzenia i zbierania danych ze strony producenta (kwestia nieco dyskusyjna, niektórym to nie przeszkadza, innym bardzo)
- możliwość kompatybilności z innymi rozwiązaniami open source (np. tutaj będzie można było podłączyć łatwo urządzenie do Home Assistant, choć ogólnie to Home Assistant też wspiera komunikacje z eWeLinkIt/Smartlife itp. poprzez logowanie się na ich konto...)
Produkt z tematu
Ten temat dotyczy czujnika otwarcia drzwi zrealizowanego na XR809/XR3 opisanego tutaj:
https://www.elektroda.pl/rtvforum/topic3771510.html
Zdjęcie zestawu:

Zdjęcie w środku:



XR809, czyli mikrokontroler ARM Cortex-M4F pracujący z częstotliwością do 160MHz, oferujący 384KB SRAM i 2MB Flash ROM, dodatkowo posiadający bogate peryferia, m. in. UART, TWI, SPI, PWM, IrDA (T/R), SDIO i ADC:

Sam moduł tutaj nazywa się XR3, jego pinout:

Co trzeba zrobić?
Zastanówmy się jakie zadania składają się na tworzenie własnego wsadu.
Zadania organizacyjne:
- przygotowanie podłączenia hardware niezbędnego do wgrania wsadu (tutaj wystarczy przejściówka UART)
- przygotowanie programu wgrywającego wsad na komputer (jest tutaj dostępny, phoenixMC.exe)
- przygotowanie toolchainu (kompilatora) i SDK XR809
Zadania do implementacji w kodzie:
- nasz firmware musi oferować prostą stronę WWW (zarówno do konfiguracji, jak i dla Tasmota HTTP)
- nasz firmware musi umieć odczytać stan przycisku i czujnika otwarcia drzwi
- nasz firmware musi oferować funkcje parowania i RESET (by móc jakoś mu wpisać raz dane naszego WiFi)
Protokół Tasmota HTTP
Całe Tasmota HTTP można przedstawić obrazowo za pomocą jednego żądania GET wysyłanego poprzez HTTP od klienta (tutaj: telefon z Tasmota Control lub Home Assistant) do serwera (naszego urządzenia).
Zapytanie GET:
Quote:
GET /cm?cmnd=status HTTP/1.1
Host: 192.168.0.110
User-Agent: HomeAssistant/2020.12.1 aiohttp/3.7.1 Python/3.8
Accept: */*
Accept-Encoding: gzip, deflate
Przykładowa odpowiedź:
Quote:
HTTP/1.1 200 OK
Content-type: application/json
{"Status":{"Module":0,"DeviceName":"Tasmota","FriendlyName":["Tasmota","Tasmota2","Tasmota3","Tasmota4"],"Topic":"tasmota_EC3F8F","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0},"StatusFWR":{"Version":"0.1(pic18f)","BuildDateTime":"2020-11-07T11:57:45","Boot":6,"Core":"0","SDK":"0","CpuFrequency":80,"Hardware":"ESP8266EX","CR":"367/699"},"StatusNET":{"Hostname":"tasmota_EC3F8F-8079","IPAddress":"192.168.0.50","Gateway":"192.168.0.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.0.1","Mac":"5C:CF:7F:EC:3F:8F","Webserver":2,"WifiConfig":4,"WifiPower":17.0},"StatusSNS":{"Time":"2021-01-10T19:27:53","DS18B20":{ "Temperature":16},"TempUnit":"C"},"StatusSTS":{"Time":"2021-01-10T19:27:54","Uptime":"0T00:41:19","UptimeSec":2479,"Heap":24,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":37,"MqttCount":0,"POWER1":"OFF","POWER2":"OFF","POWER3":"OFF","POWER4":"OFF","Wifi":{"AP":1,"SSId":"5G_FULL_POWER","BSSId":"30:B5:C2:5D:70:72","Channel":9,"RSSI":98,"Signal":-51,"LinkCount":1,"Downtime":"0T00:00:03"}}}
Ta odpowiedź jest w formacie json.
To jest takie niezbędne minimum. To pozwala odczytać stan urządzenia. Stan urządzenia jest w dwóch (!) miejscach:
- Power":0 - tutaj te 0 to jest zakodowany bitowo stan kolejnych przekaźników (lub przycisków)
- "POWER1":"OFF","POWER2":"OFF","POWER3":"OFF","POWER4":"OFF", - tu jest osobno, jako tekst, też ten sam stan
Ilość stanów jest automatycznie określana na podstawie tablicy ["Tasmota","Tasmota2","Tasmota3","Tasmota4"].
Szczegóły protokołu:
https://tasmota.github.io/docs/Commands/
Przygotowanie środowiska pracy - Cygwin
Jeśli chcemy w pełni pracować na Windowsie to musimy zainstalować Cygwina. Cygwin to środowisko które mimikuje Linuxowy wiersz polecenia na Windowsie. Potrzebny jest tu dlatego, że makefile z XR809 SDK korzysta z Linuxowych komend, np. z cp do kopiowania rezultatów kompilacji bibliotek do danego folderu. Gdyby nie to, to Cygwin nie byłby potrzebny.
Cygwina pobieramy stąd:
https://cygwin.com/install.html
Przy instalacji, po wybraniu instalowania z sieci (Download) i serwera z którego chcemy pobierać paczki, musimy wybrać komponenty które będą nam potrzebne:

Wyszukujemy i zaznaczamy tu make.
Po zainstalowaniu Cygwina uruchamiamy plikiem bat:

Otrzymujemy w ten sposób Linuxową linię komend na Windowsie:

Poruszamy się w niej tak jak na Linuxie, z tym, że jak chcemy przejść np. na dysk D to wpisujemy "cd d:" i to działa, po prostu powstaje sztuczna ścieżka /cygdrive/d
Przygotowanie środowiska pracy - toolchain ARM
Potrzebny toolchain to gcc-arm-none-eabi-4_9-2015q2-20150609.
Można go pobrać tutaj:
https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q2-update
Wybrałem wersję dla Windowsa i wypakowałem na dysk, jednocześnie poprawiając ścieżkę by nie było spacji (one troszkę mieszają, przez nie trzeba pamiętać o cudzysłowie..).
Ostatecznie ścieżka toolchaina u mnie wyszła taka: W:/GNU/4.9.2015q2/bin
Przygotowanie środowiska pracy - XR809 SDK z Git
XR809 SDK pobieramy z git, stąd:
https://github.com/XradioTech/XR809SDK/
Albo po prostu klikając tu "Download Zip":

Albo poprzez Git, można linią komend choć ja korzystam z Sourcetree:

Po wypakowaniu/ściągnięciu musimy zaktualizować jeden plik, gcc.mk.
Musimy tam wpisać cygwinową ściezkę do toolchaina:
Code: bash
Cygwinową, czyli dostęp do dysku poprzez /cygdrive/.
Zawartość XR809 SDK z Git
Paczka SDK podzielona jest na współdzielone biblioteki oraz osobne przykłady.
Współdzielone biblioteki są w folderze /src/.
Większe przykłady są w /project/, mniejsze przykłady są w /project/example/, zawierają:

Proces kompilacji
Kompilacja wsadu dla XR809 (i podobnych) jest dwuetapowa. Najpierw kompilujemy współdzielone biblioteki, tj. folder:
XR809SDK/src/
Następnie kompilujemy wybrany przez nas projekt, przykładowo:
XR809SDK/project/at_demo/
Na kompilację składają się 4 komendy.
Krok 1.1:
W folderze /cygdrive/w/GIT/XR809SDK/src wykonujemy make.

Krok 1.2:
W folderze /cygdrive/w/GIT/XR809SDK/src wykonujemy make install.
UWAGA: ten krok wymaga linuxowego cp (kopiowanie), dlatego uruchamiamy to w Cygwin. Windows nie ma w cmd komendy "cp" Linuxowej, ma swoją (można by przepisać pod to skrypty, ale łatwiej użyć Cygwin).

Krok 2.1:
W folderze /cygdrive/w/GIT/XR809SDK/project/at_demo/gcc (bądź w folderze projektu który wybraliśmy), make:

Krok 2.2:
W tym samym folderze - make image:

Ta komenda użyje mkImage.exe w celu wygenerowania xr_system.img (który potem wgramy przez UART).
Rezultat:

Uproszczenie procesu kompilacji
Trochę za dużo tych kroków kompilacji jest. Jeszcze te przechodzenie między folderami....
W związku z tym przygotowałem skrypt który upraszcza to do jednego polecenia.
Jest to skrypt linuxowy, ale w cygwinie oczywiście zadziała.
Code: bash
Jeśli dostajemy błędy z \r (carriage return), to oznacza to, że zapisaliśmy go w standardzie końców linii Windowsa (\r\n) i trzeba zamienić go na standard unixowy (unix line endings), np. poprzez Notepad2:

Podłączenie hardware
XR809 programujemy przez UART tak jak ESP8266.
Czyli standardowo - USB TO TTL HW-597 (zworką ustawiamy 3.3V poziomy logiczne):


Oprócz tego, zgodnie z notą katalogową:
datasheet wrote:
During firmware burning, both PB02 and PB03 need to be connected to a low level. When the module works properly, PB02 and PB03 cannot be connected to a low level
Do tego pin EN - inaczej RESET - (by móc resetować układ). Zasilanie z baterii na pokładzie (nie z USB, nie z UART).
Więc wykonane podłączenia:


Wgrywanie wsadu
Gotowy wsad jest plikiem xr_system.img, przykładowo w XR809SDK\project\at_demo\image\xr809.
Do wgrania wsadu służy phoenixMC.exe
Program ten wymaga by port UART nie był w użyciu, więc zamykamy port w Realterm czy jaki tam używamy terminal.
Poniżej opisane kroki na GUI (otwieramy plik img wygenerowany):

Po stronie hardware:
1. RESET do masy
2. zwieramy PB02 i PB03 do masy
3. odłaczamy RESET od masy (może być w powietrzu)
Inaczej mówiąc, w trakcie bootowania PB02 i PB03 musi być na masie by wejść w tryb programowania.
datasheet wrote:
During firmware burning, both PB02 and PB03 need to be connected to a low level. When the module works properly, PB02 and PB03 cannot be connected to a low level
Wtedy klikamy Burn:

Powinno zacząć wgrywać wsad:

Gotowe:

Potem już normalnie uruchamiamy XR, czyli:
Po stronie hardware:
1. RESET do masy
2. odłączamy PB02 lub PB03 do masy
3. odłaczamy RESET od masy (może być w powietrzu)
Uruchamiamy wsad AT
Umiemy już kompilować i wgrywać wsad. Więc możemy wgrać wsad AT (po uwcześniejszym jego skompilowaniu, na repo nie ma jego plików binarnych).
Teraz powinniśmy być w stanie przez UART wykonywać komendy. Domyślna baud to 115200.
Sprawdźmy komendę AT+S.HELP (pamiętając o CR LF, znakach końca linii i powrotu karetki):

AT działa.
Teraz wypróbujmy komendę AT+S.SCAN.

Moduł widzi sieci WiFi. Jesteśmy w stanie się z nim komunikować.
Własna komenda AT
No to może na początek spróbujmy się podpiąc do tego AT z własną komendą. Oczywiście ostateczna wersja naszego firmware nie będzie przechodziła poprzez AT, ale na próbę warto coś takiego zrobić.
Komendy są w at_command.c:

Jest to tablica nazw komend, wskaźników na funkcje je obsługujące i krótkich opisów tych komend (do generowania Help).
Do edycji kodu (przez cały temat) używałem Notepad2.
Dodałem coś na koniec:

Pełny kod funkcji (może brakować #include):
Code: c
Komenda ta połączy XR809 z naszym routerem.
Czy nasza komenda działa?

O powodzeniu procesu dowiemy się z logów routera.

Dodatkowo warto sprawdzić czy to jest ten adres MAC co ma XR (w AT jest komenda by go poznać) oraz czy komenda ping go widzi (i przestaje widzieć jak odłączymy zasilanie).
Pierwszy serwer HTTP
Po krótkim przeglądnieciu SDK można zorientować sie, że biblioteka serwera HTTP jest gotowa do użycia.
Znajduje się w src\net\shttpd-1.42.
Jest tam również jej demko, mini-serwerek już gotowy: src\net\shttpd-1.42\examples\web_server_demo.c
Spróbowałem go uruchomić. Wpiąć jego uruchomienie we wcześniej pokazaną komendę. Oczywiście trzeba dodać #include itp, ale pliki o dziwo już w kompilacji były (trochę dziwne, że kompilują web_server_demo.c....):
Code: c
Po wgraniu wsadu i wykonaniu komendy serwer działa:

Swoją drogą widać że to był serwer dla pokrewnego układu, XR871, a nie dla XR809 z tematu, ale grunt, że działa.
Na tym będziemy bazować naszą obsługę Tasmota HTTP.
Wpinamy się w serwer HTTP by obsłużyć GET
Po krótkiej analizie kodu z pliku XR809SDK\src\net\shttpd-1.42\examples\web_server_demo.c można łatwo dostrzec jak dodaje się obsługę żądania GET dla danego URL:
Code: c
Musimy użyć shttpd_register_uri i dodać obsługę GET /cm?cmnd=status HTTP/1.1.
shttpd_register_uri bierze za argumenty wskaźnik na kontekst (ctx), ścieżkę URI oraz wskaźnik na funkcję.
Aby stworzyć swoją funkcję, skopiowałem i przerobiłem set_ap_info:
Code: c
Rejestracja GETa:
Code: c
Rezultat w konsoli po wysłaniu GET:

Jeszcze jest problem z parsingiem argumentów GET, ale to za chwilę.
Rezultat w przeglądarce:

I teraz najlepsze - to jest juz kompatybilne z Tasmota Control z Google Play.
https://play.google.com/store/apps/details?id...s_software.TasmotaControl&hl=pl&gl=US
Po dodaniu device po IP, rezultat w Tasmota Control:


Oczywiście te wszystkie dane to placeholdery, tzn. na sztywno wpisane wszystko.
Parsing parametrów GET
Chwilę zastanawiałem się czemu parsing parametrów GET mi nie działa. Odpowiada za niego ta funkcja:
(void) shttpd_get_var("cmnd", arg->in.buf, arg->in.len, value, sizeof(value));
Dla POST działało.
Ale implementacja funkcji wyjaśnia o co chodzi.
Code: c
arg->in.buf to bufor tekstowy argumentów dla POST, tylko i wyłącznie.
Dla GET trzeba jej podać string argumentów GET, w ten sposób:
(void) shttpd_get_var("cmnd", query_string, strlen(query_string), value, sizeof(value));
Po tej zmianie dla zapytania GET /cm?cmnd=status otrzymujemy:

W ten sposób możemy wyłuskać wartości argumentów GET.
Odczyt stanu drzwi
Teraz trzeba się zastanowić jak odczytać stan drzwi z tego czujnika:

Ten czujnik reaguje na magnes, magnes sprawia że kontakty się stykają. Moim zdaniem wystarczy do tego odczyt pinu w trybie cyfrowym, 0 lub 1.
Przykłady obsługi pinów znalazłem w XR809SDK/project/example/gpio/main.c
Code: c
Wkleiłem więc je do testowanego przeze mnie fragmentu kodu i zrobiłem tak, że ciąg znaków "tst" w query string sprawdza tak czy czujnik coś wykrywa.
Code: c
Wyświetlanie (tylko do sprawdzenia czy działa, na szybko):
Code: c
Testujemy. "Drzwi zamknięte":


"Drzwi otwarte":


Działa - pora zintegrować to z Tasmota HTTP.
Pierwsze oznaki funkcjonalności
Posprzątałem nieco kod i podpiąłem też przycisk z płytki jako drugi input. Poniżej kod generowania odpowiedzi na zapytanie Tasmota HTTP (kod specjalnie napisany w miarę jasno, dałoby się to zrobić lepiej i krócej):
Code: c
Rezultat w Tasmota Control:

Z aktywnym czujnikiem ("zamknięte drzwi"):

Z wciśniętym przyciskiem:

Czyli wszystko działa.
Historia w konsoli UART pokazuje jak często Tasmota Control odpytuje XR o stan:

Reset do trybu AP - przycisk na stronie
Na ten moment kod na sztywno podłącza się do mojego routera WiFi, ale tak nie może być.
Przecież w takiej sytuacji trzeba by zawsze programować XR809 by go podłączyć do naszego WiFi.
Z tego powodu trzeba uruchomić tryb otwartego AP by móc łatwo konfigurować urządzenie.
Na próbę damy na stronę WWW przycisk tworzący otwarty AP.
Strona WWW XR jest w src/net/shttpd-1.42/examples/source.h.

Dodany przycisk "Reset AP":

Trzeba dodać obsługę zapytania GET, tak jak wcześniej dla komendy Tasmoty (ścieżka /reset_ap):

I funkcję która to obsłuży:
Code: c
(od razu zaznaczam, że lepiej byłoby odczekać 1 sekundę w głównej pętli i wtedy zmieniać stan sieci, bo w bieżącej wersji nie dostaniemy odpowiedzi na to GET bo się XR809 od razu odłączy)
Po wciśnięciu przycisku tracimy kontakt z modułem i pojawia się jego sieć WiFi:

Po podłączeniu się do tej sieci, pod adresem IP 192.168.51.1, możemy na nowo skonfigurować moduł:

Tu się podaje nasze hasło i SSID (trzeba jeszcze zrobić by pole było typu password, ale to żaden problem, kwestia HTML):

(właściwie to zrobiłem tu nie otwarty AP, lecz AP o znanym SSID i haśle, ale na jedno wychodzi. Można by jeszcze dodać randomizację tego "12345" w SSID tak by np. zawierało MAC)
Reset do trybu AP - fizyczny tactile switch na PCB
Zrobimy, że wciśnięcie przycisku na 5 sekund resetuje urządzenie do domyślnego AP (XR sam tworzy sieć WiFi), byśmy mogli potem do niej się podłączyć i skonfigurować mu dane o naszym routerze.
Musimy jakoś sprawdzić, czy przycisk jest wciśnięty 5 sekund.
Postanowiłem wpiąć się w pętle z pollingiem zdarzeń HTTP, wywołanie shttpd_poll blokuje na 1 sekundą, więc w sam raz:
Code: c
Po moich zmianach:
Code: c
To działa, aczkolwiek podejrzewam, że jest tu drobny błąd - shttpd_poll nie blokuje zawsze na 1000ms, tylko na mniej jeśli dotrze pakiet.
W następnej wersji być może zmienię to XR-ową (albo nie) bibliotekę przycisków, która sama obsługuje debouncing i tego typu sprawy:
Code: c
Szczegóły w project/example/button/main.c
Obsługa diody LED z pokładu
To jeszcze może udostępnijmy diodę LED dla Home Assistant poprzez Tasmota HTTP. Tak by można też było nią posterować.
To bardziej też jest tutaj w ramach demonstracji co i jak zrobić niż jako praktyczna porada (po co nam sterować diodą na drzwiach?), ale myślę, że będzie warto.
Dioda podłączona jest tutaj:

Obsługa pinu GPIO, PA12, w trybie wyjścia:
Code: c
Skoro chcemy widzieć jej stan przez Tasmota HTTP, to trzeba dodać ją jako np. "Power3" do pakietu stanu "przekaźników":
Code: c
g_gpio_led, str_state3, "Tasmota3" zostało dodane.
A jeśli chcemy móc nią sterować, to trzeba też obsłużyć pakiet GET /cm?cmnd=Power1%20Off HTTP/1.1.
Power'y indeksowane są od 1 (nie od 0), stany mogą być On lub Off.
Mój kod parsingu tego (bardzo uproszczony i bez zabezpieczeń):
Code: c
I już możemy migać - i to poprzez Tasmota HTTP:


Jedna drobna poprawka - krótka odpowiedź pakietu stanu
Nie będę już tego opisywać szczegółowo, bo to już praca czysto w obrębie wiedzy ogólnie z języka C, a nie z XR809, ale niestety musimy jeszcze zachować kompatybilność z krótkim formatem odpowiedzi Tasmota HTTP, czyli na zapytanie:
Quote:
GET /cm?cmnd=POWER1 HTTP/1.1
Host: 192.168.0.110
User-Agent: HomeAssistant/2020.12.1 aiohttp/3.7.1 Python/3.8
Accept: */*
Accept-Encoding: gzip, deflate
Musimy odpowiadać:
Quote:
HTTP/1.1 200 OK
Content-type: application/json
{"POWER1":"OFF"}
(w tym momencie program odpowiada całym opisem stanu urządzenia).
Poniżej przerobiony kod (i ta wersja już działa z HA):
Code: c
Stałe IP
Ze względu na sposób działania Tasmota HTTP (urządzenie nasze jest serwerem, a my je odpytujemy o stan) przyda się tutaj stałe IP. Już by nie komplikować zrealizowałem to poprzez rezerwację IP dla adresu MAC na routerze:

Można by to zrealizować też przez określoną nazwę hosta i DNS.
Końcowy test z Home Assistant
Na koniec sprawdziłem moduł z Home Assistant, używając do tego skryptów Tasmota HTTP opisanych tutaj:
https://www.elektroda.pl/rtvforum/topic3789324.html
czyli zaktualizowanej wersji tego pluginu, HTTAS by JiriKursky:
https://github.com/JiriKursky/httas
UWAGA - na ten moment wersja httas z Githuba nie zadziała z nowszymi wersjami Home Assistant. Wynika to ze zmiany sposobu w który obsługiwane są coroutines. Pojawi się błąd: "ValueError: Coroutine not allowed to be passed to HassJob."
Dlatego polecam pobrać moją poprawioną wersję:
W /config/configuration.yaml dałem namiary na urządzenie:
Code: yaml
Po restarcie od razu się pojawiło:

"MyRel1" tutaj to stan otwarcia drzwi, "MyRel2" to stan przycisku, "MyRel3" to stan diody.
Stan diody możemy zmieniać z poziomu Home Assistant. Pozostałe są tylko do odczytu.
Prezentacja działania:



Automatyzacje w Home Assistant
Taka integracja pozwala już robić nam automatyzacje w Home Assistant, na przykład otwarcie drzwi będzie tu powodować zapalenie diody LED (na jej miejsce można dać dowolne urządzenie kompatybilne z HA):
Code: yaml
switch.socket to ścieżka do encji ustawionej wcześniej w /config/configuration.yaml
Większa responsywność czujnika
W przypadku czujnika otwarcia drzwi można jeszcze zwiększyć czas reakcji HA na zmianę jego stanu. Robi się to w konfiguracji, wystarczy dopisać scan_interval (wartość w sekundach):

Jeśli otrzymujemy błąd:
Quote:
Logger: homeassistant.components.hassio
Source: components/hassio/__init__.py:420
Integration: Hass.io (documentation, issues)
First occurred: 11:53:21 (1 occurrences)
Last logged: 11:53:21
Invalid config for [switch.httas]: value must be at least 3 for dictionary value @ data['switches']['socket']['scan_interval']. Got 1. (See ?, line ?).
to można zmniejszyć minimalną wartość w custom_components/httas/switch.py:

Myślę, że 1 sekunda odstępu pomiędzy odświeżeniami nawet dla stanu drzwi jest wystarczająca.
Napotkane problemy
Podczas zapoznawania się z XR809 napotkałem zasadniczo jeden, dość nietypowy problem. Kosztował mnie on ponad godzinę czasu.
W trakcie prac nad resetowaniem płytki (przycisk RESET tworzący Access Point o znanym nam haśle) zobaczyłem, że nagle płytka resetuje się (wraca do main()) w momencie gdy chcę utworzyć AP lub podłączyć się do istniejącego.
Taki sam rezultat miało włączenie skanu sieci WiFi - wszystko resetowało płytkę.
Jak myślicie, jaki był tego powód?
Odpowiedź w spoilerze:
Spoiler:
Okazało się, że w trakcie prac bateryjki się nieco za bardzo rozładowały i przy niskim ich poziomie XR809 resetuje się gdy zacznie się aktywność WiFi. Problem naprawiłem zamieniając baterie na nowe.
Okazało się, że w trakcie prac bateryjki się nieco za bardzo rozładowały i przy niskim ich poziomie XR809 resetuje się gdy zacznie się aktywność WiFi. Problem naprawiłem zamieniając baterie na nowe.
Popularność XR809
Na koniec jeszcze chciałbym dać jedna drobną uwagę, gdyż wiem, że nie każdy mógł zrozumieć w pełni moje intencje. Oczywiście wiem, że XR809 i pokrewne są bardzo mało popularne i pewnie czytelnik na takiego XR809 nie trafi w ciągu swojej kariery. W tym temacie bardziej chodziło mi o ogólne pokazanie mechanizmów jak takie uruchamianie nieznanego modulu działa (i od strony technicznej i od strony organizacyjnej - bo informacje co i jak zrobić były szczątkowe jak zaczynałem z tym).
Dla użytkownika - jak używać mojego wsadu XR809
To poniekąd wynika z całego tematu, ale opiszę to jeszcze krótko w pigułce.
1. wgrać mój xr_system.img przez UART na XR809 (z katalogu project/at_demo/image/xr809/)
2. wcisnąć przycisk dłużej niż 5 sekund
3. podłączyć się do sieci WiFi xr-123 itp, hasło 12345678
4. otworzyć 192.168.51.1, podać tam SSID i hasło naszego WiFi
5. na routerze dodać rezerwację IP dla MAC XR809
6. w Home Assistant dodać plugin Tasmota HTTP (httas by JiriKursky)
7. w Home Assistant dopisać namiary na nasze urządzenie w configuration.yaml
Dalsze plany
Na ten moment planuję przede wszystkim zajrzeć do zakupionego termometru/higrometru LCD, w którym też siedzi XR809:


Następnie pewnie nieco ulepszę przedstawiony tu kod. Teraz jest nieco bez składu i ładu i być może dałoby się go "wysypać" jakimś przepełnieniem bufora. No i pewnie trzeba też dodać save(), tzn. zapis konfiguracji WiFi do pamięci na wypadek wyjęcia baterii, ale to nie problem, gdyż at_demo z SDK posiada przykładową funkcję save.
Podsumowanie
Opracowany tu wsad całkowicie uniezależnił kupiony czujnik otwarcia drzwi od serwerów producenta i pozwala używać mi go bezpośrednio z Home Assistant. Pisanie tego oprogramowania było zasadniczo składaniem aplikacji z gotowych komponentów, bo to co ważniejsze w SDK już było, z serwerem HTTP włącznie. O dalszym ciągu projektu przesądzi ilość wolnego czasu oraz ilość napotkanych urządzeń z XR809 (XR1, XR2?, XR3), choć jedno już na celowniku mam.
W załączniku ostatnia wersja kodu (załączam całe SDK wraz z binarką), z zastrzeżeniem, że jest to PRZED przepisaniem go na czysto i zawiera praktyki które nie powinny mieć miejsca w finalnej wersji.
Cool? Ranking DIY