sobota, 29 października 2016

Nie miała baba kłopotu ..... czyli nowy firmware dla ESP8266

A miało być tak pięknie

Program MIS po przeróbce na wersję ESP działa - a jakże. Tylko tak jakoś nie do końca.
Działa ale co jakiś czas się resetuje i to bez dania racji w całkiem przypadkowych momentach. Na tym tle tandem NANO<>ESP-01 to skała stabilności i zaufania.

Trzeba więc rozebrać program na części i zobaczyć co takiego może go wytrącać z równowagi. Minimum co trzeba zostawić to BLYNK, kontrola pracy systemu i obsługa kilku przycisków. Wszystko co wydaje się zbędne - out, załadunek do ESP ........ i to samo. Reset co 5-10 min. i wywala coś takiego

 ets Jan  8 2013,rst cause:2, boot mode:(3,0)
Exception (0):
epc1=0x402044a4 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
ctx: sys
sp: 3ffffc30 end: 3fffffb0 offset: 01a0
ets Jan  8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v3de0c112




Powodem jest sprzętowy reset  cause:2,  ale nawet nie dotykam się do resetu więc co?
Niestety prof. Google jest nad wyraz oszczędny w podpowiedziach. Znalazłem tylko tu sugestię o zmianie firmware. Próbujemy więc pogmerać w elektronicznych zwojach mózgowych ESP

Wgrywanie nowego firmware do ESP


Opis jak to zrobić jest na szczęście jasny i klarowny >>>>>>>>>>
Początek można sobie darować. Start od akapitu >>ESP Flash Download Tool<<.
- Ściągamy FLASH_DOWNLOAD_TOOLS_v2.4
- ściągamy najnowszy SDK - mój ESP8266_NONOS_SDK_V2.0.0_16_08_10 był tu >>>>>>>>> 
- rozpakowujemy to gdzieś
- odpalamy FLASH_DOWNLOAD_TOOLS_v2.4 i ustawiamy właściwy port i prędkość na dole po lewej stronie - będziemy mieli do dyspozycji dwa okna: programu i terminalowe
- wprowadzamy ESP w stan bootmode jak do wgrywania programu (GPIO 0 =0 i RST)
- sprawdzamy czy WSZYSTKIE okienka przy nazwach plików są ODZNACZONE
- Naciskamy START na dole i program ładnie sczyta z ESP różne dane


Najważniejsza to informacja o ilości pamięci - do wgrania nowego softu potrzeba już pamięć 1MB (8Mb). Odpadają więc niebieskie ESP-01 z pamięcią 4Mb - kupować tylko czarne z 8Mb!

W moim ESP-07 jest 8Mb więc OK. Teraz w polach set firmware path trzeba wstawić odpowiednie odnośniki do plików z firmwarem i DOBRZE ustawić adresy pamięci gdzie mają być wgrane bloki oprogramowania. TE DOMYŚLNE SĄ BŁĘDNE

Dla ESP-07 z 8Mb wygląda to tak


Są do ustawienia 3 pliki z podkatalogu \bin
- esp_init_data_default.bin z adresem 0xfc000
-  blank.bin z adresem 0xfe000
-  u mnie boot_v1.2.bin lub boot_v1.6.bin z adresem 0x00000 - wybrałem nowszy 1.6
czwarty plik z komendami AT jest w katalogu AT i podkatalogu 512+512 (8Mb)
- user1.1024.new.2.bin z adresem 0x01000

Sprawdzamy wszystko pięć razy czekujemy okienka przy nazwach plików i naciskamy START
Jeśli wszystko jest OK na dole niebieski pasek zacznie się powiększać a w oknie terminalowym zobaczymy kolejne działania programu.
Na koniec dostaniemy coś takiego


  I to w zasadzie wszystko.
W monitorze Arduino IDE możemy sprawdzić co się wgrało komendą AT+GRM (reset)
np. coś takiego


Pięknie. Więc szybko wgrywam program testowy i .......... (tu słowo niecenzuralne).
Procesor już się nie resetuje ale komunikacja z BLYNK rwie się co chwila. Jest gorzej niż było!

Na szczęście ten objaw jest już znajomy - to brak sztywnego ustawienia ESP w mod STA i brak wgranej domyślnej sieci wifi.

Pomocny w tym programik ESP Config szybko pozwoli to naprawić. Tylko jest jedno ale - nie można tego zrobić PO wgraniu własnego programu - trzeba mieć czysty ESP z firmwarem.

Więc jeszcze raz flash procesora i ustawienie STA i sieci do logowania programem ESP Config.


Sprawdzam po godzinie zapis  monitora Arduino IDE - nic, czysto, ani jednego resetu czy zerwania komunikacji z BLYNK. Czyżby jeszcze raz sukces?

Zobaczymy jutro a na razie czekamy na cd.........

czwartek, 27 października 2016

ESP8266 - następca Arduino - cz 3

Życie może być prostsze .... Arduino NANO do kosza?

Eksperymenty z ESP8266 to wciągająca zabawa. Tak niewielki moduł za jeszcze mniejszą cenę zaczyna jawić się mocarzem domowej elektroniki procesorowej...
Ale po kolei.

Uruchomiony moduł z ESP-07 obudowałem dodatkowo standardowymi interfejsami
- CYT1 - nadajnik 433 MHz
- CY-07 - odbiornik 433 MHz
- DS18B20 - czujnik temperatury
- transoptor - sterowanie pilota bramy

Dzięki rezystorom podciągającym i LED na moim module wykonanie płytki prototypowej poszło migiem. Wystarczyło połączyć zasilania i 4 linie sygnałowe.

GPIO12 - wyjście do nadajnika
GPIO14 - wejście z odbiornika
GPIO4 - DS18B20
GPIO 5 - transoptor

Z zasilaniem był mały kłopot bo moduły 433 MHz chadzają na 5 V więc trzeba było dorobić dopasowanie sygnału wyjściowego odbiornika CY-07 do ESP. Niespodziewanie ten element zabrał mi najwięcej czasu. Nieskuteczne okazały się dzielniki 1/2 k 10/20 k czy 10k/zener 3,3V. Wszystkie one powodowały jakieś dziwne poziomy na wejściu do ESP i brak dekodowania sygnałów z odbiornika. Dopiero szeregowy opornik 10 k pomiędzy wyjściem odbiornika a GPIO14 ESP-07 rozwiązał problem. Zasilenie tradycyjne na stabilizatorze 3V3 i parę kondensatorów.

Całość wygląda i świeci mniej więcej tak



Z prawej strony zasilanie 5V od dołu kable do przejściowki USB/Serial. 
I o dziwo wszytko działa zajmując ok 22 KB pamięci ESP czyli mniej niż 5% pamięci dostępnej dla programu użytkownika. Co prawda ponad 200 kB zajmuje "pusty" kod z Arduino IDE ale i tak o porównując z 30 KB NANO mamy praktycznie ponad 200 KB wolnej przestrzeni pamięci na własne programy. Prawie nieskończoność.

Coraz bardziej podoba mi się ten procesor choć nie mam praktycznie żadnych możliwości zrozumienia co dzieje się w jego wnętrzu. Już z analizą rejestrów w ATmega328 miałem spore problemy - tu rosną one do kwadratu. Pomijając taki drobiazg, że w porównaniu z ATmegą dokumentacja dla ESP jest szczątkowa i jak piszą w wielu miejsca - najeżona błędami.

Ale o dziwo TO działa i tego się trzymajmy. A już nadchodzi następca ESP8266 - moduł ESP-32 z WiFi i Bluetoothem.

Teraz na dłuższy czas zostawię działający system ESP-MIS-v1 by poobserwować zachowanie procesora i nowych bibliotek BLYNK. One też otwierają szereg ciekawych możliwości i trzeba będzie się zastanowić nad ich wykorzystaniem. Najnowsza wersja aplikacji w telefonie jest prostsza, bardziej czytelna.   Zmienię też  przyszłości kolory na bardziej żywe



poczekajmy aż cdn .........

niedziela, 23 października 2016

ESP8266 - następca Arduino - cz 2

Nie wszystko z górki .... problemy z biblioteką <DS18B20.h>


Własna płytka adaptera z modułem ESP-07 śmiga aż miło. Na razie tylko z programem bazowym. Po początkowych schodach z zawieszaniem się transmisji WiFi (patrz poprzedni post) ostateczne rozwiązanie w postaci chwilowego uśpienia procesora całkowicie wyeliminowało  problem.
Możemy przejść do eksperymentu nr 2 - instalacji kompletnego programu MIS w ESP8266. Pominę oczywiście charakterystyczne dla Arduino sposoby logowania do WiFi i BLYNK oraz procedury testowania komunikacji. Pozostawię te z programu bazowego dla ESP.

Przekopiowanie całego programu poszło gładko - pierwsza kompilacja - i oczywiście problem. Kompilator wypluwa  serię komunikatów o błędach - dotyczą one problemu ze znalezieniem pliku

C:\Dane\Arduino\esp_new\libraries\DS18B20/DS18B20.h:6:26: fatal error: avr/pgmspace.h: No such file or directory

 #include <avr/pgmspace.h>


Szybka kwerenda po kilku blogach - rzeczywiście jest coś na rzeczy z ze standardową biblioteką Arduino DS18B20.h do obsługi czujnika temperatury. Jednak na każdym proponują inny sposób rozwiązania problemu, który sprowadza się do grzebania w bibliotekach źródłowych Arduino IDE. Nie pałam chęcią mieszania w plikach źródłowych  szczególnie, że jak piszą nie zabezpiecza on przed problemami na przyszłość gdy wgrywa się nowszą wersję IDE.

Pozostaje więc poszukać innej biblioteki do obsługi DS18B20. Pierwsza nawinęła się biblioteka DallasTemperature.h   ktorą zamiast zainstalować w Arduino IDE tradycyjnie dodałem do folderu libraries   w katalogu z programami .ino.

Pierwsze  wrażenie z analizy przykładów nie jest zachęcające - obsługa czujnika wygląda na bardziej złożoną niż w bibliotece DS18B20 wiec trzeba będzie co nieco zmienić w programie. W przykładzie nie widać też nigdzie miejsca do wprowadzenia kodu czujnika - jedyną zmienną jest nr portu z przyłączonym czujnikiem. Czyżby program był genialny i  sam szukał i obsługiwał czujnik bez początkowego wprowadzenia adresu czujnika?

Program DEMO dla Dallas wygląda tak


Na próbę uruchamiam przykład z tej biblioteki na płytce BRAMA3 - tu mam pewność, że czujnik jest sprawny i znam jego kod. A  tak wynik działania programu

 




I pięknie. Pozostaje sprawdzić czy biblioteka jest akceptowana przez kompilator dla płytki ESP
JEST!!!
Problem można uznać za rozwiązany i to z dodatkowymi bonusami. Biblioteka Dallas pozwala
- w pełni kontrolować parametry pomiarowe czujnika i to w układzie z wielokrotnymi czujnikami na tym samym porcie
- sama odszukuje adres czujnika
- działa pod ESP8266
Wchodzi wiec do pakietu stałych bibliotek.

Pozostaje mi tylko obudować moduł ESP dodatkowymi elementami (nadajnik/odbiornik 433 MHz, czujnik DS18B20 i transoptor do sterowania pilotem) i zobaczymy jak ESP poradzi sobie z całym programem inteligentnego domu


Więc czekamy na cd......

piątek, 14 października 2016

ESP8266 - następca Arduino

ESP8266 - mały może więcej 

 

Długo zbierałem się by poważnie potraktować to coś. Z większości postów wyziera dość pesymistyczny obraz chińskiego procesora. Niby 32 bitowy RISC z 80 MHz 512 kB  96 kB RAM ale  tylko 9 dostępnych portów GPIO (a tak naprawdę tylko 5! do swobodnego zaprogramowania), SPI I2C UART i jedno 10 bitowe wejście A/D. To wszystko bardzo skromne jak na dzisiejsze procesory tej klasy. Chimeryczny, bardzo wrażliwy na zakłócenia, generujący dziwne przebiegi na swoich pinach  w stanach nieustalonych, bez porządnej dokumentacji, ciągle zmienianym firmware - generalnie lipa.

I tylko dwie rzeczy, które rozkładają konkurencję na łopatki:
- pełne sprzętowe WiFi IEEE 802.11 b/g/n z WEP i WPA/WPA2
- CENA - 1,7 - 2 $ na  Aliexpress

To w zasadzie przesądza kwestię czy warto się czymś takim zajmować. Pełne WiFi a nawet pełny punkt IoT za 2$! Oczywiście, że tak.
Dodatkowy argument to wsparcie ESP8266 przez Arduino IDE i działające w większości  bez problemu standardowe biblioteki z tego systemu. Czego chcieć więcej. Świat IoT bez Arduino ? Zobaczymy.....

Do tej pory ESP-01 dzielnie mi służył jako łącze ze światem dla ulubionego NANO. I świetnie ten tandem wg mnie współpracuje. Szczególnie że Atmega jest dosyć stabilna z zainstalowanym BLYNK a ESP działa z oryginalnym firmwarem i SDK. I w razie czego ustawia do pionu ESP gdy ten traci przytomność czyli komunikację ze światem. Ale to jednak dwa procesory przy czym słabszy i o mniejszej pamięci bierze na siebie obsługę całego systemu. Coś nie tak z punktu widzenia logiki.

Pierwszą próbę samodzielnej pracy ESP-07 już zaliczyłem - miernik wilgotności gleby  w zasadzie zadziałał . Ale to zabawka w porównaniu z tym co chciałbym na ESP uruchomić.

Sam goły ESP- 07 lub 12 słabo nadaje się do zastosowania. Rozstaw 2mm i konieczność dołożenia szeregu rezystorów by mogło to-to działać zmusza do zastosowania płytki przejściowej. Są takie ale jakieś niedorobione. Tylko trzy rezystory podpinające na takiej dużej płytce? - mam ale nie używam


Ciekawym gotowym  rozwiązaniem wydaje się natomiast nowa płytka D1 MINI - ma na pokładzie w zasadzie wszystko a dodatkowo przejściówkę na RS do programowania ESP. I tylko 2,60$ na Aliexpress. Zamówiłem



 W oczekiwaniu na przesyłkę z Chin zabawiłem się w stworzenie własnej płytki przejściowej takiej min-max. Minimum powierzchni maksimum elementów.  W mojej technologii wykonania mógł to być druk tylko na elementy przewlekane, Ale i tak udało mi się upchnąć na płytce całkiem sporo.


Rezystory R1 R2 to dzielnik napięcia by móc przyłączyć serial z logiką 5V. Rezystory na CH_PD, Reset GPIO0 GPIO2 GPIO15 oczywiste. Dodałem oporniki na GPIO4 i 5 jako podpinające do I2C by można bezpośrednio sterować dodatkowe moduły z tą szyną. LEDy dodałem na mało przydatne piny GPIO0 i GPIO15, które muszą mieć określone stany na moment wgrywania oprogramowania i uruchamiania programu. LEDy dopięte są tak by wymuszać konieczne stany na tych portach (GPIO0 do VCC, GPIO15 do masy).  R12 to kondensator :) 100nF na zasilaniu.
Dla ułatwienia piny do programowania wyprowadziłem po jednej stronie płytki pod kątowe złącze szpilkowe.

A to gotowa płytko do zamówienia w ulubionej firmie MERKAR.pl


Zamówiłem - dostałem 16 szt. Będzie w czym rzeźbić choć cena malutkiej płyteczki to prawie 5 zł. D1 MINI wychodzi jednak taniej. I to zmontowana i z elementami.  Nic to  - moja jest LEPSZA :). Mogę na przykład wstawić ESP-07  lub ESP-07s z dodatkową anteną zewnętrzną.



Pierwsza warstwa oporniki, druga ESP-07, złącza szpilkowe i płytka gotowa do testów.



Dla nowej płytki postanowiłem wgrać najnowsze oprogramowanie Arduino IDE i BLYNK. Arduino.cc (tylko w nim umiem zainstalować dodatkowe płytki ESP) wydało wersję 1.6.12 ze znakomitą funkcją zwijania części kodu należących do danej funkcji czy procedury. Przy pisaniu większych kodów wprost nieodzowne!


I spróbowałem całość uruchomić z programem miernika wilgotności gleby.
Kompilacja wysypała się na pierwszym zakręcie. Wracam do wersji 1.6.9 - ładnie się kompiluje ale płytka zachowuje się bardzo niestabilnie - nie chce nawiązać połączenia z WiFi i trzeba ją kilkukrotnie resetować.
Wracam do wersji 1.6.12 szukając co może wieszać kompilację. Z logów wynika że brak jakiś plików dla płytki ESP. Zaraz - już kiedyś to chyba przerabiałem. Oczywiście !!! Problem tkwi w braku podfolderu  >Portable<
Kasuję wszystko i instaluję IDE i sterowniki do płyty ESP od nowa. Poszło. Jeszcze tylko ten problem braku połączenia z WiFi. Co zaskakujące cały program działa bez problemu a procesor nawet nie próbuje nawiązywać łączności przez WiFi. Widać to po zasilaczu i po wielkości pobieranego prądu.
Może program lub procesor wyłączył WiFi - jest to możliwe w ESP8266 na kilka sposobów. Ale znam tylko jeden sposób by na powrót aktywować moduł RF do komunikacji WiFi. Trzeba wprowadzić procesor w stan uśpienia DEEPSLEEP z parametrem WAKE_RF_DEFAULT
Dodaję więc wywołanie procedury zwierając jednocześnie porty RST i GPIO16 (niezbędne dla wybudzenia procesora)

ESP.deepSleep(x * 1 * 1000 * 1000, WAKE_RF_DEFAULT);

Po uśpieniu i wybudzeniu procesora transmisja WiFi nawiązuje się bez problemu. Ale po odłączeniu procesora od zasilania problem powraca. Przeglądarka Internetu podpowiada że może to być normalne zachowanie procesora w trybie oszczędzania energii - gdy brak jest danych do wysłania przez WiFi przechodzi on automatycznie w stan wyłączenia modułu RF. Ale dlaczego gdy próbuje coś wysłać procesor nie przywraca działania części radiowej modułu WiFi już nie znalazłem.
Ok na razie - do czasu znalezienia odpowiedzi na to pytanie - pozostanie mi przywracanie działania modułu RF poprzez chwilowe usypianie procesora. Dodam to do procedury samokontroli prawidłowej pracy systemu.

Dla potrzeb przyszłych implementacji przygotowałem "czysty" kod zawierający tylko podstawowe elementy:
- konfiguracje portów
- nawiązanie połączenia WiFi
- nawiązanie połączenia z BLYNK
- timery
- miganie LEDami w ukladzie i w aplikacji w telefonie jako kontrola poprawnej pracy systemu
- procedury samokontroli nawiązania łączności WiFi i z BLYNK
- Watchdog



Jest to baza dla przyszłych programów, które chciałbym uruchomić na tym chińskim wynalazku
Do ciekawszych fragmentów kodu zaliczam
  • watchdoog - linie 15-17, 76-85, 104-105 i 116
  • nie wstrzymujące obiegu programu logowanie do WiFi i BLYNK - linie 122-127
  •  procedura testowania i resetowania przy braku komunikacji - linie 137-190
I to tyle na dziś.

A  więc cd ma niewątpliwą szansę nastąpić..........


wtorek, 11 października 2016

Jak zrobić termostat do pieca CO w 10 min - czyli BLYNK w akcji

Zabawa elektroniką nigdy nie była jeszcze tak tania i prosta!

Chcę termostat - mam termostat i to piękny kolorowy dostępny w telefonie czy tablecie. A wszystko za ZERO zł.
Oczywiście promocyjna cena wynika z wcześniej wykonanego modułu IoT z Arduino NANO i ESP-01 ale nie zmienia to faktu że rozbudowa o kolejne funkcje może być praktycznie bezkosztowa - nie licząc kosztu widgetów BLYNK które trzeba dokupić gdy przekroczymy darmowy limit. Ale i tu nastąpiły ogromne zmiany. Chłopaki dodali kilka nowych świetnych widgetów (o tym przy innej okazji) ale przede wszystkim wprowadzili możliwość zmiany ich parametrów przez komendy wysyłane z procesora. Możemy więc zmienić kolor opis a nawet liczbę pozycji wyświetlenych przez widgety co otwiera ogromne pole do eksperymentów i zmienia całkowicie, na korzyść, filozofię prezentacji zdarzeń zachodzących w systemie procesorowym. I znakomicie potania korzystanie z aplikacji BLYNK, choć i obecne koszty są śmiesznie niskie.

Przy okazji wdrożenia w termostatu pieca CO do systemu  inteligencji domowej przerobiłem więc cały program BRAMA2 do najnowszej biblioteki BLYNK (v0.3.9) i najnowszej aplikacji na Android (v1.15.3) bo ten zestaw otwiera możliwości związane z nowymi widgetami i ich funkcjami.

Nowy system, który będzie podstawą dalszego rozwoju domowej inteligencji od dziś będzie zwał się MIŚ. Miało to być rozwinięcie Mały Inteligentny System .....  ale czy trzeba jakiegoś uzasadnienia? Będzie więc MIŚ (z angielska MIS) bez uzasadnienia.

W przerobionym programie uporządkowałem nieco procedury i deklaracje przez co całość stała się (mam nadzieję) nieco bardziej przejrzysta i czytelna. Moim celem jest dojście do pełnej modułowej budowy systemu tak by można było szybko i niezawodnie tworzyć podsytemy IoT zawierające tylko niektóre z wybranych funkcji systemu MIŚ. I tak będą powstawać kolejne mutacje MISiów w zależności od konkretnych potrzeb czy pomysłów do realizacji. Pewnie nie obędzie się bez dalszej nauki języka C by skutecznie tworzyć procedury i funkcje będące  modułami systemu MIŚ a może i przyjdzie kolej na tworzenie własnych bibliotek. Ale to jeszcze nie teraz.

Jak wspomniałem projektanci BLYNK wciąż dłubią przy programie rozbudowując go nowe ciekawe funkcje. Aplikacja w telefonie przybrała więc inny kształt moim zdaniem dużo czytelniejszy i łatwiejszy do opanowania. Po pierwsze zrezygnowałem prawie całkowicie ze wskaźników typu LED -za wyjątkiem LEDa v1 który miga wskazując na poprawną komunikację procesor<>BLYNK. Wszystkie inne vLEDy,które sygnalizowały wykonanie komendy przesłanej z aplikacji zastąpiłem zmianą koloru elementu (najczęściej jest to przycisk) wywołującego daną komendę. Działa znakomicie i daje ciekawe efekty wizualne. Dodatkowo wykorzystałem możliwość zmiany opisu (LABEL) danego widgetu przez co uzyskałem dodatkowy efekt poprawy czytelności tego co dzieje się mikrokontrolerze. Zmian tych dokonuje procesor więc są one jednocześnie potwierdzeniem że komenda lub funkcja działa prawidłowo. Świetna sprawa. Zaimplementowałem nawet licznik czasu działania pompy obiegowej na widgecie przyciku! To już pełen odlot i barok. A to dopiero początek eksperymentowania z nowymi możliwościami BLYKa.

Nowy ekran aplikacji wygląda mniej więcej tak



Przycisk PILOT po naciśnięciu zmienia kolor na biały gdy procesor potwierdzi wykonanie komendy Jeśli brak jest  potwierdzenia kolor pozostanie niebieski.

Wskaźnik temperatury czujnika zmienia kolory w zależności o stanu programowego termostatu. Gdy temperatura mierzona przez czujnik na module MIS jest większa niż nastawa wskaźnik świeci na czerwono. Gdy jest niższa pulsuje (cyklicznie zmienia kolor czerwony/niebieski) co oznacza wysyłanie do pieca komendy ZAŁĄCZ.

Przycisk POMPA po załączeniu i wysłaniu potwierdzenia o załączeniu pompy zmienia kolor na biały. Dodatkowo zamiast opisu POMPA pojawia się licznik n x 10 sek - czas pozostały do wyłączenia pompy


cdn..



sobota, 8 października 2016

Domowe IoT w rozbudowie >> centralne ogrzewanie + Arduino + BLYNK

Ciepło na żądanie czyli BLYNK steruje kotłem CO

Okres wakacyjny i pięknej wrześniowej pogody przeleciał (za)szybko. Ale są i plusy - w deszczowy dzień można poświęcić więcej czasu na procesorowe dłubactwo.

Planowana wcześniej rozbudowa "inteligencji" domowej o możliwość zdalnego sterowania gazowym kotłem centralnego ogrzewania ma więc szansę na realizację. Bez tego mój system to raczej 1/2 inteligentnego domu a może i 1/4 ( taki trochę ćwierćinteligent).
Pierwszy problem - jak sterować - jest dość oczywisty. Obecnie temperatura w domu kontrolowana jest przez prosty ale niezawodny i co najważniejsze - bezprzewodowy - termostat DIGITIME-800.


Dane techniczne też napawają optymizmem - transmisja pomiędzy termostatem a gniazdem radiowym idzie na 433,92 MHz. Ciekawe czy standardowa biblioteka <RCSwitch.h>, która dekoduje sygnały z czujki ruchu poradzi sobie z odbiorem kodu termostatu. I zobaczymy jak działa monitor uruchomiony na terminalu BLYNK w programie BRAMA2.


No proszę - jak pięknie. Kod 5592332 załącza a 5592323 wyłącza piec CO. Należy tylko wysłać te kody do gniazda od pieca i po robocie!
Ale jak przerobić ten kod na coś takiego -  elroTransmitter.sendSignal(3, 'C', onoff); zrozumiałego dla biblioteki <RemoteTransmitter.h> ?

Wewnątrz biblioteki ukryte są takie funkcje
static void sendTelegram(unsigned long data, unsigned short pin);
static void sendCode(unsigned short pin, unsigned long code, unsigned int periodusec, unsigned short repeats);
Funkcja sendCode odpada - jak wół w opisie zaznaczono że transmituje ona jedynie pierwsze 20 bitów pozostałe zaś ignoruje. A rozwiniecie binarne liczby 5592323 to 10101010101010100000011 a więc co najmniej 23 bity. Pozostaje funkcja sendTelegram tylko co zrobić z nagłówkiem synchronizacyjnym 9 bitowym.  I jeszcze w to wszystko wcisnąć liczbę powtórzeń kodu. Uff zaczyna robić się ciężko.

Może łatwiej będzie z częścią nadawczą biblioteki <RCSwitch.h>. To biblioteka przeznaczona do nadawania i odbioru kodów w postaci liczb a nie zbiorów odzwierciedlających dipswitche i klawisze na pilocie.

Użycie biblioteki <RCSwitch.h> do nadawania kodu wydaje się banalnie proste
deklaracja pinu nadajnika    mySwitch.enableTransmit(3);  (nadajnik na porcie D3)
i wysyłamy kod w kosmos  mySwitch.send("0101010101010101000000111");  kod uzupełniłem o dodatkowe 0 na początku by zgadzała się liczba bitów - 24 szt.

Wstawiam do programu BRAMA2 - i ...... kicha. Program piękne wiesza się na procedurze transmisji kodu do pieca CO. Albo  kody obu bibliotek <RCSwitch.h> i <RemoteTransmitter.h> się gryzą albo ...... nie mam pojęcia co. Trzeciej biblioteki już nie mam.

Zaczynamy więc całą zabawę  od adrema.
Po pierwsze dobrze wiedzieć co naprawdę nadaje termostat. Do tego celu świetnie nadaje się przykład ReceiveDemo_Advanced z bibloteki <RCSwitch.h>.  Sprawdzę też jak wyglądają inne kody - te z pilotów i czujek PIR.

pilot - Decimal: 5522769 (24Bit) Binary: 010101000100010101010001 Tri-State: FFF0F0FFFF0F  PulseLength: 324 microseconds Protocol: 1

termostat - Decimal: 5592323 (24Bit) Binary: 010101010101010100000011 Tri-State: FFFFFFFF0001¨ PulseLength: 209 microseconds Protocol: 1
 

czujka ruchu - Decimal: 14013756 (24Bit) Binary: 110101011101010100111100 Tri-State: 1FFF1FFF0110 PulseLength: 408 microseconds Protocol: 1

Okazuje się że są to wszystko protokoły określane jako nr 1 ale różniące się miedzy sobą długością znaku!. Każdy z kodów ma inny PulseLengtth i to różniący się w takim stopniu, że praktycznie uniemożliwia bezpośrednią współpracę tych trzech urządzeń nawet jeśli udałoby się na każdym z nich ustawić te same kody nadawczo- odbiorcze. A więc wniosek pierwszy - nasz system IoT robi tu za swoisty ruter komunikacyjny łączący pomiędzy sobą urządzenia o różnych parametrach tego samego protokołu.

Drugi wniosek to ten że obie biblioteki powinny umożliwiać wysyłanie kodów każdego z trzech rodzajów urządzeń o ile tylko znajdę sposób by dobrać się do procedury tworzenia wynikowego kodu, który potem odbierany jest przez bibliotekę <RCSwitch.h>.

Zanim sprawdzę dlaczego transmisja kodu biblioteką <RCSwitch.h>  wiesza program spróbuję jednak uruchomić wysyłanie kodów biblioteką   <RemoteTransmitter.h> - wtedy nie będę musiał przerabiać całego programu BRAMA2 zamieniając kody pilotów na odpowiadające im liczby kododwe (z "3, 'C', onoff" na 5522769). Problemy widzę co najmniej dwa - jak wysłać kod w postaci liczby i czy zmiana PulseLengtth dla kodów termostatu nie wpłynie na pracę procedury elroTransmitter.sendSignal(3, 'C', onoff);

..............................
 ........ 2 h ..............
............................... 

Po dwóch godzinach analizy i pomocy od kolegi Rosjanina wychodzi mi, że z biblioteki  <RemoteTransmitter.h> bez jej głębokiej przeróbki  nie da się wykroić transmisji dowolnego kodu. W 32 bitowym kodzie zaszyte są bowiem na stałe parametry długości impulsu i liczby powtórzeń a trudno to zmienić przed procedurą transmisji. Biblioteka <RemoteTransmitter.h> wędruje więc do kosza.

Biblioteka <RCSwitch.h> jak pisałem jest prosta w użyciu. Dodatkowo bardzo łatwo można ustawić wszystkie istotne parametry transmisji. Kod obsługujący gniazda ELRO wygląda tak

    mySwitch.setPulseLength(320); 
    mySwitch.setProtocol(1);            
    mySwitch.setRepeatTransmit(4);


   mySwitch.send(5525844, 24);

Zaś sterujący piecem CO

    mySwitch.setPulseLength(210);
    mySwitch.setProtocol(1);
    mySwitch.setRepeatTransmit(4);
   
    mySwitch.send(5592332, 24);



I po kłopocie. Wszystko śmiga aż miło więc czeka mnie odczytanie wszystkich kodów pilotów w wersji liczbowej i przeróbka całego programu BRAMA2 pod bibliotekę <RCSwitch.h>. Ale to już całkiem inna historia.


Tak więc cd niewątpliwie nastąpi .......