Flashowanie ESP-01 i innyh ESP8266

Lenistwo - cecha niewątpliwie pozytywna 

Zawsze doceniałem pozytywną rolę jaką w naszym  (mówię o facetach oczywiście) życiu odgrywa lenistwo. Czasami nabyte czasami wrodzone - ale na szczęście immanentnie związane z pierwszo i drugorzędowymi cechami określanymi jako męskie.
Nie będę tu wymieniał epokowych wynalazków ewidentnie związanych z tą piękną cechą - dość powiedzieć, że dzięki zmywarce wielu mężów uniknęło rozwodu a nawet polubiło zmywanie naczyń!

Własne klocki LEGO - odcinek II

Duży może więcej....

 Od chwili zmuszenia ESP8266 do pracy nie mam już problemów z dostępnością pamięci w małym ATMELu-328. Największy kod BRAMA4 obsługujący wszystko co do tego czasu zaimplementowałem w domowym IoT zajmuje niecałe 20KB. Przerzucenie BLYNKa do ESP-01 dało jeszcze jeden pozytywny aspekt - cały system automatycznie przechodzi w stan pracy autonomicznej przy braku połączenia z siecią lub serwerem BLYNK. W porównaniu z BLYNKiem  zainstalowanym w NANO praktycznie przejmującym  kontrolę nad procesorem przy braku połączenia taki stan to spełnienie  marzeń.

A więc 80MHz  traktor dzielnie ciągnie wózek inteligentnego domu. ESP-01 nie ma jednak żadnych dodatkowych portów możliwych do swobodnego wykorzystania toteż szansa na obciążenie jego taczki  jest już niewielka. Ale gdy pomyślę, że dla powiększenia pamięci NANO wydałbym 10-20 zł to rozwiązanie z dodatkowym ESP-01 (1,6$) jako rozszerzeniem pamięci programu wydaje się super optymalne. A wszystko to niejako przy okazji instalacji WiFi bez, której cała zabawa w IoT pozbawiona jest sensu.

ESP-01 pracuje u mnie jak wzorcowy SLAVE pod komendą z małego NANO przejmując na siebie całą obsługę BLYNK i WiFi. A wszystko to jest sterowane banalnie prostym protokołem opartym na stringu.
"Kxx:yyy" gdzie  K >komenda   xx > nr vPin   :  > separator   yyy > dane
i to wszystko czego potrzebuje ESP-01 by poprawnie komunikować się z BLYNK i wykonywać zlecone mu zadania

Cóż więc takiego robi nasz chińczyk:




Wszystkie procedury związane z połączeniem z BLYNKiem są w programie głównym.
BLYNK_WRITE_DEFAULT() (30-39) odczytuje po resecie i wysyła do NANO wszystkie zapamiętane stany vPinów.
 Blynkwrite(String str2)  (41-67) przetwarza otrzymane z NANO komendy na polecenia BLYNK lub wykonuje je wewnątrz ESP-01.
Na końcu programu mamy procedury migania ledami dla celów kontrolnych. Program główny wygląda nader skromnie.

   


ESP-01 odpowiada przede wszystkim  za nawiązanie i obsługę połączenia WiFi. Ale nie zobaczymy tego w kodzie programu. Wszystko odbywa się na poziomie sprzętowym a niezbędne komendy do uruchomienia całej procedury zajmują jedynie kilka linijek (205-227).U mnie więcej bo dodana została  dodatkowo procedura zmiany domyślnych nastaw logowania do WiFi. Idea opisana jest tu>>>> ale próba implementacji tej funkcjonalności w programy BRAMA kończyła się niepowodzeniem przez brak pamięci w NANO. Dopiero układ dwuprocesorowy pozwolił mi ponownie wrócić do pomysłu i to z pełnym sukcesem. Aktualna biblioteka pozwala zmienić dane logowania WiFi przy użyciu terminala BLYNK i jednego vPrzycisku. Nowe dane logowania zapamiętywane są w EEPROMie.



Biblioteka "transmit.h" spełnia funkcję identyczną do tej w NANO tj. obsługuje łącze serialowe dla wymiany danych z drugim procesorem. Nic tu specjalnego nie ma poza odbiorem w poolingu danych z RS232 i sprawdzeniem poprawności odebranego kodu. To skromne zadanie wzbogaciłem o możliwość "podglądania" odbieranych i wysyłanych danych na serialu i terminalu ESP. By nie zaśmiecać transmisji i nie generować nadmiernego ruchu w domowym internecie funkcje podglądu są zdalnie załączane vPrzyciskami V32 i V33. Taki sam mechanizm został dodany do NANO stąd dwie dodatkowe zakładki w aplikacji telefonu służące jedynie celom testowym. Baaaaardzo przydatna funkcjonalność.

Teraz kilka tygodni testów i zobaczymy co jeszcze trzeba będzie dodać lub poprawić

Przed nami święta więc

Spokojnych Pogodnych Świąt Bożego Narodzenia

I czekamy na cd .....

NANO do D1 mini > "nie chce mi się z tobą gadać"

Czy dedukcja może zastąpić porządny oscyloskop?

Dziś miała być druga część tasiemca o własnych bibliotekach ale zdecydowanie wygrał temat na wskroś elektroniczny. A było to tak ....

Własne klocki LEGO - pierwsze prywatne biblioteki

Każdy śpiewać może trochę lepiej lub trochę gorzej...

Podzieliłem byłem swój program BRAMA na dwie części (opis tutaj) pomiędzy ESP i NANO. To niebywałe jak taki niewinny zabieg ułatwia "panowanie" nad tworzonym kodem.
Stworzenie wąskiego gardła jakim jest serial do wymiany danych pomiędzy modułami znakomicie porządkuje sprawę zmiennych choć na pierwszy rzut oka powinno to utrudniać a nie ułatwiać pisanie nowego kodu. Ale  takie ograniczenie w sposób naturalny zmusza do porządku i dyscypliny w zawiadywaniu zmiennymi. Ogranicza swobodę (a wręcz swawolę) jaką mamy wewnątrz programu kiedy chcemy przesłać informację z jednego segmentu do drugiego. Mogę to zrobić przecież na 1000 i jeden sposobów. I robię. Przez to mapa wektorów przesyłanych informacji pomiędzy programami/funkcjami ww programie (gdyby ją stworzyć) wyglądałaby pewnie jak kłębowisko poskręcanych kabli pod moim stołem. Zapanowanie nad tym jest możliwe do pewnego momentu. Potem trzeba z mozołem śledzić drogę przesyłu takich sygnałów i co one tam po drodze robią lub powinny robić. To konieczność wielokrotnego przeskanowywania całego kodu programu by prześledzić całą ścieżkę od początku do końca i to bez żadnej gwarancji że czegoś tam po drodze nie przeoczyłem.

Stworzona sztucznie "wąska rura" przesyłu danych to rodzaj wiązki z ładnie poukładanymi kablami łączącego pomiędzy sobą różne urządzenia. Nie trzeba już podążać za każdym pojedynczym sygnałem - wystarczy popatrzeć jakie bloki łączy stworzony kanał i jaki rodzaj sygnałów mamy w wiązce. Jeśli jeszcze w jakiś logiczny sposób ponazywamy te sygnały to ich obróbka po obu stronach wiązki znakomicie się upraszcza. Jedyny problem to wybór "szerokości" kanału przesyłowego tak by w przyszłości nie trzeba było pruć całej wiązki by dołożyć jeszcze jeden potrzebny kabel.
Sądzę że właśnie taką funkcję spełniają w programie STRUKTURY i trzeba będzie się nimi zająć na poważnie. Najpierw jednak trzeba nauczyć się dzielić program na niezależne bloki i umieć je wzajemnie skomunikować.

Na pierwszy ognień poszedł kod BRAMY3 nazwany dla niepoznaki BRAMA 3 1/2. To kod oparty na podziale zadań pomiędzy NANO i ESP-01. NANO odpowiada za sterowanie peryferiami a ESP za komunikację z BLYNK. Połączenie obu mikrokontrolerów dokonuje się za pomocą sprzętowego seriala na obu modułach. Robi to wszytko co poprzednie BRAMY:
- symuluje pilota bramy garażowej i sygnalizuje stan otwarcia bramy
- symuluje wszystkie piloty oświetlenia w domu i na zewnątrz
- steruje pompą obiegu CO
- steruje kotłem CO równolegle do bezprzewodowego termostatu
- mierzy temperaturę
- miga ledami i ma inne nieistotne bajery
Kod jest mocno rozwojowy w tej strukturze więc pewnie będziemy do niego wracać jeszcze nie jeden raz.
Po podziale kodu na dwa osobne procesory postanowiłem dodatkowo poszatkować kody na funkcjonalne biblioteki.To taka zabawa/wprawka ale i test czy stosowanie własnych bibliotek w czymkolwiek pomaga przy tak niewielkich (400-600 linii) kodach.

Część zainstalowana w NANO składa się z części głównej kodu zapisanej na chwilę obecną jako brama3v7.ino i wydzielonych bibliotek  "klaw.h", "transmit.h" "dallas.h"  "pompa.h" "piec_co.h"  Nazwy wskazują funkcje programu jakie zostały w nich skupione.
Wszystkie biblioteki znajdują się w podkatalogu głównego programu brama3v7.ino dlatego wywołuje się je poprzez #include "klaw.h" w nawiasach "" a nie w < >.


Program główny brama3v7.ino


W programie głównym są umieszczone podstawowe pętle programu SETUP ( ze wszystkimi ustawieniami początkowymi programu) i LOOP (zminimalizowana do trzech funkcji - obsługi w poolingu timera, odbioru z 433 MHZ i odbioru z RS232).  Zostawiłem też tutaj programy błyskania ledami kontrolnymi na płycie głównej i w aplikacji BLYNK, czytanie stanu przełącznika, testowanie komunikacji z ESP i jego ewentualne resetowanie.

Oznacza to, że NANO pozostało wiodącym procesorem w systemie - kierującym i nadzorującym w całości jego poprawne funkcjonowanie.Pytanie kto nadzoruje NANO jest jak najbardziej uzasadnione. Jeśli NANO padnie lub się zawiesi - na dziś  niestety - powiesi się cały system. Ale to jest tylko stan przejściowy. W następnych ćwiczeniach praktycznych NANO zostanie przeformatowane poprzez wgranie nowego bootloadera tak by uruchomić można było na nim sprzętowy watchdog zawarty w ATMEGA328. Na dziś ze względu na błąd w bootloaderze watchdog wiesza cały procesor. Dodam też być może krosowe sprawdzanie NANO przez ESP i powiadamianie o awarii do aplikacji BLYNK. Ale to przyszłość.

Na razie w programie głównym pozostawiłem wszystkie wywołania procedur uruchamianych zmianą stanów vPinów w BLYNK (66-110) by mieć to wszystko w jednym miejscu i łatwo kontrolować modyfikacje. Chwilowo jest tu też sterowanie i kontrola otwierania bramy (130-155) ale i ona pewnikiem trafi do swojej biblioteki.

Na początku programu głównego zadeklarowane są moje biblioteki "" ale także niektóre biblioteki systemowe < > znajdujące się w katalogu "libraries" użyte w moich bibliotekach. Nie wiem czemu ale musiałem powtórzyć te deklaracje także tutaj by kompilator nie wyrzucał błędów. Dobrze, że nie następuje dwukrotne dołączenie tych bibliotek przed czym ostrzegają wszelakie kursy programowania - sprawdzone.W programie głównym są też deklaracje portów NANO przydzielonych do różnych zadań (37-42).
Nie ma za to deklaracji zmiennych choć znowu wszelkie kursa poprawnego programowania absolutnie to zalecają. U mnie deklaracja zmiennej następuje w bibliotece, w której jest wykorzystywana. Dlaczego? Deklaracja zmiennej w bibliotece "xxx.h" jest widziana w programie głównym a odwrotnie NIE! Również kolejność wywołania bibliotek ma wpływ na "widzialność" zmiennej w innych bibliotekach. Zmienna by być widziana w kolejnej bibliotece musi być zadeklarowana we wcześniej wywołanej bibliotece.
Jeszcze inaczej jest z deklaracjami i wywołaniami funkcji i procedur. I znowu - procedury (funkcje) zadeklarowane w bibliotekach są widziane w programie głównym. Odwrotnie, by biblioteka mogła wywołać procedurę z programu głównego lub innej biblioteki musi na początku tej biblioteki być predefiniowana. Będzie to widać  w kolejnych bibliotekach.

Biblioteka "dallas.h"


Ta moja biblioteka podoba się mi najbardziej - jest krotka, treściwa i zawiera wszystko do obsługi czujnika temperatury DS18B20. Nawet procedury ustawień początkowych, które winny znaleźć się w pętli SETUP są tu mieszczone w osobnej procedurze setdallas() W lini 2 jest deklaracja nr portu z przyłączonym czujnikiem temperatury. Dodanie obsługi czujnika w nowym programie to

- przekopiowania biblioteki "dallas.h" do katalogu programu
- dopisaniu #include "dallas.h" na początku programu
- ustawienia nowego portu czujnika
- wywołaniu procedury setdallas() w sekcji SETUP
i wszystko
   
Biblioteka "klaw.h"



Biblioteka klaw.h to taki zlepek rożnych funkcji przypisanych do symulacji pilota świateł wszelakich w domu i na zewnątrz za pomocą sterowników ELRO. Zlepek bo oprócz deklaracji wszystkich kodów wysłanych lub odbieranych w paśmie 433 MHz (33-58)' deklaracji tabeli kodów poszczególnych pilotów (64-93) i procedur nadawania i odbioru kodów (94-129) umieściłem tu deklaracje kolorów widgetow BLYNK (12-31). Gdzieś je musiałem umieścić i trafiły tu - najczęściej bawię się kolorami zmieniając parametry przycisków w APP BLYNK. Biblioteka jest usługową wobec innych bibliotek dlatego deklarowana jest jako pierwsza. W liniach 123-125 wywołuję procedury znajdujące się w innych bibliotekach. By były one dostępne, na początku musi nastąpić ich predefinowanie (5-8).  Format predefinicji to deklaracja funkcji zakończona średnikiem - koniecznie!
Deklaracja biblioteki #include <RCSwitch.h> jest oczywista bo z niej korzysta program transmisji 433MHz. Mniej oczywista jest deklaracja #include <Arduino.h>. Bez niej kompilator "nie rozumie" wywołania wielu procedur znamiennych dla ARDUINO IDE np. Serial.print(). Choć w programie głównym takiej deklaracji nie ma to wszystko tam działa a tu nie. Pokręcone to trochę jakoś ....

Biblioteka "transmit.h"




Biblioteka "transmit.h" to protokół komunikacji pomiędzy NANO i ESP-01 oraz wywołanie procedur uruchamianych wysyłanymi z ESP komendami. Na początku predefinicje procedur użytych w programie głównym. Odpowiadają one numerom vPinow, ktore je wywołują. To prosty i czytelny sposób porządkowania katalogu wszystkich funkcji związanych ze zmianami wartości na vPinach.
 Niżej (17-44) procedura void Blynkwrite(String str2) odpowiedzialna za dekodowanie nr vPinu i jego wartości (w postaci Stringa) oraz dowiązanie do niego odpowiedniej procedury wykonawczej. To odpowiednik procedury BLYNK_WRITE(VPin) z BLYNKa.

W linii 21 wydzielam fragment przesłanego stringa zawierający nr vPin a w linii 22 zamieniam string na liczbę. Linia 23 to wydzielenie drugiego fragmentu stringa z danymi dla vPinu. Jak zostanie ona potraktowana dalej (jako INTEGER BOOL lub STRING) zależy już od mojej decyzji w procedurze obsługi vPinu.

Dalsza część kodu to część nadawcza bloku transmisji -  formatowanie stringa będącego komendą dla ESP (56-83). A więc funkcjonalnie odpowiada ona procedurze Blynk.virtualWrite(VPin, Data) z BLYNKa.
Jak widać zdefiniowałem 7 typów komend zależnych od typu przesyłanych do BLYNK danych a więc dane typu:
- tekstowe typu STRING (prefix S)
- liczbowe typu Integer (prefix I)
- sterowanie vLED (prefix L)
- sterowanie kolorem widgeta (prefix C)
- sterowanie opisem przycisku - stan OFF (prefix F)
- sterowanie opisem przycisku - stan ON (prefix N)
- inne komendy (prefix O)
Czemu aż tyle? Niestety TYLKO tyle i to jeszcze nie koniec. Chłopaki z BLYNKa odeszli od pięknej początkowej unifikacji wywoływania wszystkich funkcji widgetów poprzez procedurę Blynk.virtualWrite(VPin, Data). Teraz np. by zmienić kolor trzeba wywołać procedurę Blynk.setProperty(pin2, "color", chardata2); stąd potrzeba osobnych komend wywołujących taką funkcję. Niestety to nie koniec bo widgetów przybywa a z nimi konieczność dodawania kolejnych nowych komend. Ale to przyszłość - na razie to co jest wystarcza mi do obsługi moich programów.

I na koniec (84-116) procedury odbioru i dekodowania stringa przesłanego z ESP serialem. Wszystkie komendy wysyłane przez ESP mają prefix "V' i kończą się znakiem /r /n. Te dwa elementy są znacznikami poprawności odbieranego kodu.

Biblioteka "pompa.h"




Kolejna z opisywanych bibliotek "pompa.h" odpowiada za sterowanie pompą obiegową CO.Na początku tradycyjnie już predefinicje procedur przy czym ciekawostką jest konieczność deklaracji void pompazal(); mimo iż procedura ta znajduje się w tejże bibliotece. Problem w tym, że jest ona wywołana wcześniej (33) niż zdefiniowana (38). Czort wie dlaczego taka kolejność nie wywoluje oburzenia kompilatora w głównym programie  a w bibliotekach jak najbardziej. Dziwne to jakieś ......
Pompę uruchamia bądź czujka PIR (52) lub vPrzycisk w telefonie (45)  na czas odmierzany procedurą void licznikobiegu(). Procedura wysyła kod załączania co 10 sek aż do osiągniecia przez licznik wartości 0. Potem odlicza do wartości ujemnych by kilkakrotnie wysłać kod wyłączenia pompy (ot tak dla pewności). W trakcie odliczania na vPrzycisku wyświetlany jest stan licznika (bajer taki) i zmieniany jest kolor przycisku. Wysyłanie odpowiedniego kodu zał/wył odbywa się w liniach 29 i 40.
Jako extras dodałem widget timer pozwalający ustalić przedział czasu, w którym pompa ma prawo się załączyć od czujki PIR. Obecnie to czas między 7:00 a 23:00. Poza tymi godzinami wejście do łazienki nie generuje sygnału załączenia pompy obiegowej CO. Kąpiel o 4 nad ranem? Bez przesady!

Biblioteka "piec_co.h"





Biblioteka umożliwia ręczne zdalne zadanie temperatury (niezależnie od bezprzewodowego regulatora w pokoju) i wyłaczenie grzania gdy czujnik na module pokaże osiągnięcie zakładanej temperatury w pomieszczeniu w którym znajduje się moduł. Temperatura ustawiana jest co 0,5 oC a regulacja posiada histerezę 0,5 oC. Nie jest to jakieś super dokładne ustawianie temperatury bo czujnik ds18b20 nieźle fałszuje (już wprowadziłem korekcję -3oC) ale nie jest to podstawowy regulator ciepła w domu.
Dwa vPrzyciski w aplikacji telefonu umożliwiają nastawę temperatury odczytywaną na wyświetlaczu na vPinie 17
Procedura pieconoff()  cyklicznie porównuje temperaturę zadaną z rzeczywistą i gdy temperatura nastawiana jest co najmniej o 0,5 oC wyższa - włącza piec migając naprzemiennie kolorami wyświetlacza(36). Maksymala temperatura nastawy to 26oC minimalna 13oC

A tak to wygląda wizualnie w telefonie. O zakładkach monitorów opowiem przy okazji opisu programu w ESP-01.

Uff. To najdłuższy post i najdłuższy wygenerowany do tej pory kod. A to dopiero pierwsza część umieszczona w NANO ...........więc cd niewątpliwie musi nastąpić .........

D1 mini - ESP8266 profesjonalnie

Inni mogą (jednak) lepiej

Po prawie 50 dniach (chiński rekord długości czasu dostawy) dotarł - D1 mini
Nie ma dwóch zdań - robi wrażenie swoją profesjonalnością wykonania. Za 2,5$ w pełni wypasiona płytka z większością potrzebnych bajerów - pełne USB, stabilizator 3V3, przycisk reset, polaryzacje pinów. Słowem wszystko co potrzeba by odpalić samodzielnie procesor z WiFi bez konieczności dokładania czegokolwiek.

ESP 8266 <> Arduinno NANO - zmiana miejsca instalacji BLYNK

Duży może więcej

Nurtuje mnie od jakiegoś czasu zagadnienie współpracy UNO/NANO z ESP8266. A dokładniej, czy słaby 8 bitowy mikrus procesorowy winien nadzorować działanie całego systemu i jeszcze sterować o wiele potężniejszym mikrokontrolerem ESP8266. Brak w tym logiki poza logiką historyczną - Arduino był pierwszy i to on obrastał w kolejne peryferia w tym odpowiedzialne za komunikację różnego rodzaju shieldy.  Ale od czasu gdy ESP wkupił się w łaski Arduino IDE i może być traktowany na równi z Atmelami utrzymywanie stanu rządzenia dużego przez małego wydaje się anachronizmem. Szczególnie, że zapełnienie 32 KB pamięci UNO/NANO dokonuje się błyskawicznie  przy wykorzystywaniu BLYNKa a 10 krotnie większa pamięć ESP8266 pozostaje praktycznie pusta.

O przewadze zmywarki nad ręcznym myciem garów - biblioteki cd ..

Biblioteka TIMERS.H z daleka i bliska

Jakiś czas temu dotknąłem pobieżnie tematu bibliotek tych genialnych narzędzi programisty I choć to podstawa całej filozofii klocków lego, o której opowiada ten blog to jednak wszystko jest jeszcze przede mną. Zdałem sobie sprawę z tego analizując moją najbardziej ulubioną bibliotekę Timers.h.

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.

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.

ESP8266 - następca Arduino - cz 2

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

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.

I to tyle na dziś.

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

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.

Arduino i ESP8266 w projekcie Home IoT (inteligentnego domu)

Wnioski z działania

Dotychczasowe funkcjonowanie "centrum zarządzania" inteligentnym domem jest więcej niż bardzo dobre.

Praktycznie nie obserwuję jakichkolwiek resetów systemu a wszystkie funkcje (sterowanie cyrkulacją ciepłej wody, sterowanie gniazdami ELRO 433 MHz,sterowanie bramą garażową) działają bezproblemowo. Dodatkowo, po zamontowaniu całości w obudowie czujki PIR całość prezentuje się  naprawdę dobrze. Obudowę pozostawię nie zamkniętą gdyż istotne elementy systemu (NANO, ESP-01, nadajnik i odbiornik 433 MHz) zamontowane są w przejściówkach z goldpinami (jest to układ bądź co bądź testowy) przez co cała konstrukcja jest wyższa niż głębokość obudowy.
Równie ważne jest to że układ praktycznie nie nagrzewa się pomimo zasilania z zasilacza 12 V i konieczności zejścia z napięciem do poziomu 5 i 3,3 V. A to dzięki wysokosprawnej miniaturowej przetwornicy DC DC 12/5 V zamontowanej pod spodem płytki drukowanej. Więcej ciepła wydziela stabilizator 5/3,3V mimo że spadek napięcia na nim to tylko 1,7V i zasila jedynie układ ESP-01. Te chińskie mini przetwornice to naprawdę świetne rozwiązanie do zasilań elektroniki.

O aplikacji BLYNK pisałem już wielokrotnie - bez niej cała ta zabawa w Inteligentny dom nie miałaby większego sensu. Sam nigdy nie napisałbym programu wizualizacyjnego podobnej klasy nie mówiąc już o stworzeniu skutecznego i bezbłędnie działającego łącza internetowego pomiędzy procesorem a aplikacją w telefonie. Chłopaki z BLYNKa wciąż rozbudowują system dodając nowe widgety i funkcjonalności ale nawet to co już jest stanowi rewolucję dla rynku DIY. Trzymam kciuki by ich projekt się powiódł i by zarobili tyle by nie musieć sprzedać się wielkim tego świata. Zobaczymy......

Największa rewolucja od początku tworzenia projektu IoT nastąpiła w oprogramowaniu procesora. Kod programu jest najszybciej zmieniającym elementem w całej zabawie. To zrozumiała bo właśnie w tym zakresie mam najwięcej do nadrobienia. I jakkolwiek kopiowanie fragmentów kodu z innych obcych programów jest podstawowym sposobem jego powstawania  to udaje się mi już z sukcesem tworzyć własne fragmenty działające mniej więcej tak jak tego oczekuję. Najważniejsze jest to, iż program w połączeniu z procesorami (NANO i ESP-01) tworzy w miarę niezawodny system bez zawieszania się czy dziwnych nie planowanych zachowań. To jest nawet ważniejsze niż różnorodność czy elegancja tworzonych funkcji. System na którym w 100% nie można polegać gdy chodzi o ciągłość pracy nie nadaje się praktycznie do stosowania. Świadomie nie wyprowadzam więc na zewnątrz przycisku RESET do przywracania poprawności pracy modułu kiedy dochodzi do jego zaburzenia  np. z powodu zewnętrznych zakłóceń, zaniku napięcia zasilania czy innych zdarzeń "wysypujących" kod programu. Program sam musi sobie poradzić w takich sytuacjach. W programie sporo więc miejsca zajmują elementy samokontroli i autostartu umożliwiające przywracanie prawidłowej jego pracy. Do rozwiązania wciąż pozostaje jednak  problem złej obsługi watchdoga w module NANO. To ostatni element jaki muszę dopracować by uznać tą część programu za w miarę skończoną.

Całość programu na obecną chwile wygląda tak





I to na razie tyle w temacie domowej inteligencji

 cdn ............ jak mniemam

Arduino IoT - podsumowanie cz. 2

Wnioski, uwagi, spostrzeżenia

Hardware

Moduły Arduino zdały egzamin celująco jako baza do nauki programowania współczesnych procesorów. Są dobre, tanie i niebywale przyjazne. A wszelkie problemy jakie można napotkać podczas pracy nad własnymi projektami rozwiązuje błyskawicznie prof. Internet. Idea bootloadera uruchamianego automatycznie z programu kompilującego (Arduino IDE) upraszcza cały proces tworzenia projektu do niezbędnego minimum. I jeszcze znakomita funkcja monitora pozwalająca na błyskawiczną analizę w działaniu napisanego kodu. 

Arduino IoT - podsumowanie 5 miesiecy

PROCESORY = Powroty bywają fascynujące

Miał być pryma aprilis a zrobiło się z tego całkiem poważne hobby. Obecny świat procesorów dla opornych okazał się nadzwyczaj przyjazny. Kluczem jest oczywiście Internet i jego nieprzebrane zasoby wiedzy. Ale też możliwość kontaktu z podobnymi pasjonatami tworzących najprzeróżniejsze projekty i udostępniających je całkowicie za darmochę. A sprzęt .... cóż małe chińskie rączki składają nieprzebrane ilości urządzeń i modułów oferując je za przysłowiowy psi grosz z darmową dostawą do domu.

IoT z Arduino i ESP - pierwsza wersja finalna

Nowe płytki drukowane BRAMA2 już dotarły. Można więc złożyć razem trzy projekty :
- sterowanie gniazdami ELRO w całym domu
- automatyka pompy cyrkulacji ciepłej wody
- sterowanie bramą garażową

Arduino biblioteki - cd ..... obsługa Timer

Biblioteki odliczania odcinków czasu

Doświadczenie nas uczy, że najwięcej czasu procesor przeznacza na nierobienie niczego (podwójne przeczenie w programowaniu daje prawdę w życiu różnie). A dokładniej - na sprawdzanie lub czekanie na sygnał informujący, że jest coś do zrobienia. 

Arduino biblioteki - cd... obsługa Button

Pierwsze "poważne" programy chodzą  można więc zacząć małe porządki.
Z wrodzonego lenistwa i przyjętej filozofii klocków LEGO dobrze byłoby zastosować gotowe procedury w co najmniej dwu przypadkach

• sprawdzania klawisza lub ogólniej - zmiany stanu na porcie 
• odliczania czasu, lub wykonywania procedur w określonych interwałach

Jak zwykle w przypadku Arduino Internet oferuje nam całą gamę bibliotek do wyboru. Coś trzeba wybrać

Bezprzewodowy miernik wilgotności gleby z odczytem w telefonie

ESP8266 w działaniu - czyli projekt z bateryjką

Czas coś popełnić z samodzielnie działającym ESP8266. W poczekalni jest pomysł na małą automatykę ogrodową - coś co odciąży od obowiązku doglądania i podlewania donic i pojemników z warzywami w ogrodzie. Skrzyń z warzywami jest trochę a nawet chwilowy niedobór wody odbija się znacząco na kondycji roślin  i plonach. Trzeba więc zatrudnić dobrego dżinna by robił to za mnie.

ESP8266 na poważnie cz. 3

Aaa kotki dwa - czyli jak skutecznie uśpić ESP-12

Dziś spróbujemy wprowadzić nasz moduł w stan uśpienia. Do wyboru jest kilka modów ograniczenia prądu pobieranego przez procesor. tu>>>>>>>>>

ESP8266 na poważnie cz. 2

Dzień drugi - nie ma łatwo

Poprzedni dzień kursu nauki ESP to był dobry dzień - w trzy godziny udało się uruchomić ESP a do tego pełen sukces uruchomienia BLYNKa na tym procesorze. Z małymi problemami z driverem konwertera - ale poszło. Pajęczyna niestety nie zdaje egzaminu - poruszenie jakimś kabelkiem zawiesza procesor i pomaga tylko reset.

ESP8266 na poważnie cz. 1

Czyli IoT BEZ ARDUINO!

Czekam na miniaturowe przetwornice z Chin by móc dokończyć projektowanie płytki POMPA+BRAMA więc w przerwie poćwiczę ESP w pracy standalone (po naszemu "samodzielnej" to jakby nie do końca to samo).

Schemat modułu podstawowego IoT

IoT wersja 3.0

Po pierwszej płytce pozytywne doświadczenia zachęcają do wykonania kolejnej.
Tym razem będzie to bardziej uniwersalny moduł zawierający dodatkowo część nadawczo-odbiorczą na 433 MHz. Wraz ze sterownikiem pilota i ESP do komunikacji z BLYNK układ taki powinien pokryć większość funkcji jakie przewiduję dla domowej jednostki centralnej IoT. Niewielki dyskretny i ładny moduł zarządzający peryferiami i dające możliwość zdalnego nadzoru z telefonu/tableta.

ESP8266, ESP-01 kolejna odsłona

Dziś kolejne zajęcia z cyklu - ESP8266 z bliska.

Arduino i transmisja 433 MHz - cz 2

Zamówienie doszło błyskawicznie i jest profesjonalnie zapakowane.  Wszystko w ochronnych piankach i oddzielnych torebkach antystatycznych oczywiście czytelnie opisanych. Jestem pod wrażeniem. Duży plus dla firmy MICROS.

Płytka drukowana odcinek 2

Nadejszło lato a z nim zamówione pierwsze płytki drukowane do projektu "brama"
Porządny szklany laminat, metalizowane otwory,  pocynowane ścieżki i powiercone otwory.
Pełen profesjonalizm. I za przystępną cenę - 16zł +VAT z transportem za sztukę. Jak dla mnie super.
Zareklamuję firmę MERKAR bo warto.

Arduino i transmisja 433 MHz - cz 1

Testy modułów

Komunikacja w "górę" tj. Internetowa na razie działa bez zarzutu. Zarówno w wersji przewodowej na W5100 jak i bez kabla na ESP-01. Duża w tym zasługa BLYNK'a przejmującego skutecznie zarządzaniem jednym i drugim modułem sieciowym.
Czas wrócić do do transmisji w "dół" do czujników i elementów wykonawczych na paśmie 433 MHz.
Niestety dobry bo tani moduł FS100A - nie jest dobry choć tani

Projekty z Arduino na płytce drukowanej (PCB)

Druk - odrobina profesjonalizmu

Wykonanie układu na płytce stykowej zajmuje 10 min. Już po chwili pajęczyna oplatająca Arduino i moduły i elementy dodatkowe gotowa jest do testowania oprogramowania. To naprawdę duże ułatwienie w stosunku do klasycznie lutowanego pająka. I możliwość dowolnych zmian bez użycia jakichkolwiek narzędzi. Gorąco polecam stosowane płytek stykowych we wczesnej fazie tworzenia projektu.

Sterowanie bramą wjazdową i garażową z Arduino - errata 1

Gotowy układ sterowania bramami zainstalowany u odbiorcy końcowego działa pięknie ..... tylko się wiesza! Po 24 do 48 h gaśnie żółty led a cały sterownik jest głuchy jak pień. Pomaga ostry reset tzn. wyjęcie wtyczki zasilania. I znowu pięknie mruga przez kilkanaście godzin do kolejnego zwisu. Co jest do cholery. Układ przez miesiąc na stole nie wysypał ani razu a tu na wejściu taki obciach. Jak w akademickim dowcipie. Wiem, że teoretycznie wszystko jest OK a nie działa - w praktyce na stole działa wzorcowo i nie wiem dlaczego - połączenie teorii z praktyką w układzie dla odbiorcy dało wynik oczywisty - nie działa i nie wiem dlaczego!

Projekt nr 2 - sterowanie bramą wjazdową i garażową z Arduino - cz 2

Produkcja

Pomysł na zasilanie całości sterownika poprzez USB chybiony. Delikatne gniazdo miniUSB wyłamie się szybciej niż zdążę pomyśleć. Zamiana - zasilanie z zasilacza 5V bezpośrednio na płytkę NANO i równolegle na osobną przetwornicę DC/DC step-up by na wyjściu 12V zasilić pilota (nie uwzględnione na schemacie. Koszt części rośnie do około 100 zł.
Dodam też ekstrasa - pomiar temperatury czujnikiem 18B20 (5 zł z dostawą) - ładnie pasuje do otworu po antenie czujnika.

Projekt nr 2 - sterowanie bramą wjazdową i garażową z Arduino - cz 1

Arduino - po co?

Wymyślanie, na siłę, tematów do rozwiązania przez Arduino z mojego doświadczenia zawsze kończy się źle (a tak bardzo chciałoby się coś zrobić!). Usprawnianie działającej rzeczy mnoży kłopoty i wkurza otoczenie. Co innego gdy trzeba rozwiązać istniejący problem z zakresu sterowania lub monitoringu. Najlepiej zgłaszany przez sceptyka naszych fascynacji mikrokontrolerami. Tu możemy pokazać całą wyższość podejścia DIY (do it yourself).

Arduino biblioteki - pierwsze doświadczenia

Cena wolności

Przyjemność i prostotę obsługi Arduino zawdzięczamy bibliotekom. Setkom, tysiącom bibliotek dostępnych wszędzie. Wolność i szybkość kreowania programu przy ich pomocy jest ogromna. Ale jak to z wolnością bywa czasami może nam się nieźle dopiec.
Wolność to zgoda na ograniczenie bezpieczeństwa, pewności. To zwiększone ryzyko. Wykorzystując biblioteki muszę być na to jakoś przygotowany

Automatyka obiegu ciepłej wody z Arduino - sezon 2 odcinek 2

Czas na próbę działania teorii w praktyce

Automatyka obiegu ciepłej wody z Arduino - sezon 2 odcinek 1

To samo - inaczej

Bezprzewodowa czujka PIR  doszła, BLYNK opanowany, ESP-01działa można więc wrócić do tematu sterowania pompy obiegowej ciepłej wody z wykorzystaniem Arduino. Miałem to zrobić z płytką Ethernet W5100 ale tak mi się spodobała praca z ESP-01, że sobie daruję.

Arduino z ESP8266 - trzecie podejście

ESP-01

Mam 2 sztuki a w necie krytyka modułu ESP-0,1 że podatny na zakłócenia z powodu barku obudowy, niestabilny . Spróbuję go jednak użyć jako modułu w konfiguracji BLYNK <> ESP-01 <> Arduino <> RF433 by zestawić  drugą ścieżkę łączności Blynk'a z domowym systemem IoT tym razem bezprzewodowo.

Arduino z ESP8266 - drugie podejście

Taak.
Po ostatniej porażce prędko dokupiłem dwa nowe moduły  ESP-01 te po 10 zł z Allegro. Tym razem  mocny standard - większość aplikacji w necie bazuje właśnie na tym module. Do tego przejściówkę USB-RS232 TTL z opcją 3,3V by nie bawić się w translacje sygnału.

Arduino z ESP8266 - pierwsze podejście

Czas na łączność bez drutu

Płytki Ethernet W5100 po ostatnich przeróbkach sprawują się przyzwoicie. Ciągła i bezawaryjna komunikacja z BLYNK serwerem i szybkie logowanie się do systemu po zaniku zasilania. No ale to kabel i kontrolery można umieścić co najwyżej w 4-5 miejscach gdzie są gniazda sieciowe. Praca w warunkach polowych odpada.  Nie da się tego porozrzucać po terenie jako czujniki czy elementy wykonawcze. No i cena 30 zet + koszta przesyłki.
Pora więc na kabel bez drutu - WiFi.

Na kłopoty - BLYNK

Gdzie diabeł nie może.....

Po dwóch dniach walki Ethernet Shield pokonał mnie całkowicie. Niby coś działa ale bez żadnej gwarancji  i pewności. Budowanie na czymś takim komunikacji to proszenie się o wieczne kłopoty.

Arduino + Internet czyli W5100 w akcji

UNO w sieci

Czym jest komputer bez Internetu? Dla większości z nas złomem. No może jeszcze liczydłem, maszyną do pisania lub udoskonalonym ZX Spektrum z fajnymi grami. A jednak przez długi czas samotny PCet królował na wielu uczelnianych i firmowych biurkach. Potem z pewną nieśmiałością łączyło się toto koncentrykiem z drugim PCetem lub modem z BBS z prędkością 2400 lub 9600.
Piękne czasy.....
Dziś bez Internetu życie dla wielu z nas nie istnieje.

Arduino UNO + RF433 = automatyka obiegu ciepłej wody

Początek systemu

Wykorzystanie Arduino do budowy automatyki obiegu ciepłej wody bez znajomości Atmela i języka C wydaje się mało logiczne. Ale ma jedną zaletę. Przy okazji budowy takiego systemu można się wiele nauczyć.
Więc do dzieła.

Automatyka obiegu ciepłej wody - sezon 1 odc 1

Automatyka obiegu ciepłej wody.

Jest problem - Włączyć pompę obiegową CWU (ciepłej wody) wtedy kiedy potrzeba tzn. w czasie pobytu w łazience. A potem STOP do następnej wizyty.

Nauka Arduino

W poprzednim poście wymieniłem rzeczy moim zdaniem wystarczające do rozpoczęcia przygody z Arduino. Zapomniałem dodać jednej - 1m2 wolnego biurka do swobodnego rozłożenia się z elektronicznym majdanem. Móc wrócić do projektu w każdej wolnej chwili lub w przypływie nagłego olśnienia jest sprawą absolutnie kluczową.

No to zaczynamy

Wybór platformy.

Ten w zasadzie dokonał się sam. Wcześniejsze próby z PICami, Malinami czy LAN-Kontolerami w zasadzie potwierdzały opinię - to nie dla mnie. Dopiero niewielka płytka  UNO do uruchomienia, której wystarczył kabel USB i nieprzebrane zasoby darmowych dostępnych wszędzie programów i projektów zachęciły do poważniejszego zainteresowania tematem. O wkurzającym dziesięciolatku nie wspominając.

Powrót do przyszłości

Trochę historii

Powroty bywają trudne. Bardzo. Po 20-30 latach nie istnieje już świat, do którego chciałbyś wrócić. Świat bliski zrozumiały i przyjazny. Wszystko co spotykasz jest całkiem nowe i inne niż pamiętasz. Nawet rzeczy wyglądające z pozoru na znajome,, mające znajome nazwy czy kształty po bliższym przyjrzeniu zmieniają się w obce dziwadła nie do opanowania zmęczonym rozumem.