[042] Zdalne sterowanie przekaźnikami - wstęp

O chmurze Arduino pisałem niedawno i nawet stworzyliśmy sobie prosty program, w którym Arduino było sterowane przez smartfon. Czas na coś bardziej praktycznego, postanowiłem jednak raz jeszcze krok po kroku ukazać wszystkie etapy poruszania się po środowisku, gdyż nie jest to takie oczywiste i rzekłbym – mimo że tworzy je społeczność międzynarodowa – napisane jest w duchu włoskiej finezji, czyli nie do końca czytelnej na pierwszy rzut oka.

Chmurowe zabawy zwalniają nas z obowiązku ściągania Arduino IDE i dbania o wszelkie aktualizacje, ale jest to okupione podstawową wadą: powolnością. Zarówno poruszanie się po elementach środowiska jak i weryfikacja i kompilacja szkiców, trwa znacznie dłużej. Dlatego osobiście polecam środowisko wirtualne ograniczać tylko do działań korzystających z chmury, czyli serwerów łączących smartfony i komputery z płytką Arduino. Szkice pracujące lokalnie czy generalnie niekorzystające z możliwości kontroli zdalnej, lepiej będzie ogarniać również lokalnie.

Istotne są tutaj także koszty, za darmo trafimy na szereg ograniczeń. Największym jest możliwość pracy tylko nad dwoma projektami. Pozostałe ograniczenia, w tym wyjątkowo uciążliwe – do 25 kompilacji dziennie – na szczęście są obecnie nieaktywne, ale czy aby tak będzie zawsze? Nie wiadomo. Najtańszy sensowny plan, obejmujący 10 projektów, to wydatek prawie 24 dolarów rocznie, natomiast jeśli będziemy chcieli się dzielić projektami, trzeba będzie zapłacić więcej.

Wracajmy do pracy. Postanowiłem połączyć dwa zagadnienia, które niedawno omawiałem, a więc chmurę oraz płytkę z przekaźnikami. Oba elementy zostały już omówione dokładnie, więc zapraszam do wspomnianych artykułów. Przypomnę, że ze względu na chmurę potrzebna będzie płytka, która z nią współpracuje. Wybrałem nowe Arduino Uno R4 i osadzę je na płytce edukacyjnej TME EDU ARD 2 wraz z shieldem z przekaźnikami.

Wchodzimy na stronę arduino.cc i logujemy się. W moim przypadku siedział tam projekt z poprzedniego artykułu i dla lepszej czytelności opracowania, usunąłem zarówno szkic (Sketch) jak i projekt pulpitu smartfona (Dashboards). Pozostawiłem jednak płytkę (Devices), którą nawałem kiedyś TowaryPraktyczne, która została zarejestrowana w systemie i tego, jak to zrobić, powtarzać nie będę.

Chmurowe projekty, zresztą nie tylko one, mają tę cechę, że w większości wypadków lepiej będzie odwiedzić bibliotekę pomysłów (IoT Templates) i modyfikować znalezione tam przykłady zgodnie z własnymi potrzebami niż tworzyć całość od zera. Po pierwsze: tak będzie szybciej. Po drugie: wyjdziemy na pewno od projektu działającego, więc jeśli coś pokręcimy, wystarczy się cofnąć do ostatniego sprawnego stanu projektu i szukać przyczyny niepowodzenia.

Zatem przejdźmy do zakładki IoT Templates i wybierzmy pierwszy z brzegu, czyli niesławne Cloud Blink. Na wstępie dowiemy się, że do zabawy wystarczy jedna z wybranych płytek i przewód USB. Dlaczego wybrałem akurat projekt do mrugania diodą, mając płytkę z przekaźnikami? O tym za chwilę. Uruchommy ten projekt.

Zacząć należy oczywiście od podłączenia płytki do komputera, na którym znajduje się agent współpracy płytki z chmurą. O agencie (Cloud agent) także mówiłem, instaluje się go przy okazji rejestrowania pierwszej płytki w systemie, a jeśli go brakuje, otrzymamy teraz link do pobrania. Agent jednak był i odnalazł Arduino Uno R4 na wirtualnym porcie COM8, więc połączenie na pewno działa. Po chwili będziemy mogli przypisać płytkę do projektu, nad którym właśnie usiedliśmy.

Będziemy teraz proszeni o podanie nazwy sieci WiFi, w której płytka będzie pracować, hasła do sieci i klucza związanego z tą konkretną płytką Arduino. Został on wygenerowany podczas rejestracji płytki. Jeśli nie zapisaliśmy go wtedy, trzeba będzie proces rejestracji płytki przeprowadzić ponownie od początku.

Import projektu został zakończony, co więcej – także weryfikacja i kompilacja. Innymi słowy, droga tędy, przez import gotowców, skraca ścieżkę działań, oszczędzając nam kroków, które będziemy wykonywać, chcąc tworzyć własne projekty.

Możemy teraz przejść w zakładkę Dashboard i poklikać sobie w przełącznik, patrząc na efekty, czyli mrugającą diodę na płytce testowej. Po zainstalowaniu apki na telefon i zalogowaniu się na konto, dostaniemy to samo, ale na ekranie smartfona. Fakt, nie jest nadzwyczaj fascynujące, więc przejdźmy do projektu właściwego.

Zacznijmy od porządków, czyli zmiany nazw elementów składowych nowego projektu. Najpierw panel sterujący, czyli to, co widać na ekranie smartfona. Użyję nazwy Shield, bo takiej użyłem w projekcie urządzenia z przekaźnikami pracującego offline. Następnie zmienię nazwę projektu, czyli Things, także na Shield i na końcu nazwę szkicu. To nie jest obowiązkowe, ale poruszanie się wśród blinków, gdy chodzi o płytkę z przekaźnikami, jest trochę niekonsekwentne.

Przejdźmy teraz do szkicu (Sketch). Te, które współpracują z chmurą, mają nieco inną budowę od znanych nam dotąd. Składają się nie z jednego, a trzech plików. Pierwszy zawiera to, co już znamy, czyli treść programu.

W tym wypadku oczywiście będzie to program do migania diodą, bo taki zaimportowaliśmy. Drugi zawiera elementy związane ze zdalnym dostępem, a więc parametry połączenia sieciowego i zestaw zdarzeń, które będą mieć miejsce pomiędzy ekranem smartfona, a płytką. W trzeciej zakładce znajdują się dane sieci WiFi i klucz, przypisany do tej konkretnej płytki. Rzućmy okiem w szczegóły i zacznijmy od pierwszego pliku, czyli Shield.ino

#include "thingProperties.h"

Tutaj mamy informację o nazwie drugiego pliku, czyli thingProperties.h Można go zmienić, acz odradzam.

Serial.begin(9600);
delay(1500);

Program domyślnie inicjuje wysyłanie tekstów przez złącze szeregowe, które możemy odbierać wbudowanym terminalem. Przydaje się to podczas uruchamiania większych projektów, gdy dodatkowe linie z komendami obrazującymi stany urządzenia pozwalają na ocenę tego, co aktualnie się z nim dzieje. Gdyby to nie było potrzebne, możemy usunąć ten zapis.

InitProperties();
ArduinoCloud.begin(ArduinoIoTPreferredConnection);

Tutaj zaczytujemy parametry związane z siecią i inicjujemy te elementy.

setDebugMessageLevel(2);
ArduinoCloud.printDebugInfo();

Te dwie linie pozwalają poznać szczegóły połączenia, wysyłane na terminal – jeśli nas to interesuje. Cyferkami od zera do czterech określamy ilość informacji. W zasadzie jest to potrzebne głównie podczas uruchamiania urządzenia i później możemy to usunąć.

pinMode(LED_BUILTIN, OUTPUT);

Program Blink wymaga ustawienia portu z diodą i jest to tutaj czynione.

void loop() {
  ArduinoCloud.update();
  digitalWrite(LED_BUILTIN, led);
}

W pętli głównej odwiedzamy chmurę, po czym wystawiamy na port diody poziom wynikający z jego ustawienia na panelu smartfona. I to już cały program. Choć nie do końca, bo na końcu znajduje się jeszcze podprogram onLedChange, wykonujący się zaraz po tym, gdy chmura zwróci zmieniony status – w tym wypadku jedynego przełącznika sterującego diodą. Zamieszczono tam instrukcję wysyłającą na terminal informację o tym, że dioda zmieniła stan. Ten element także jest opcjonalny i może być użyty na przykład do pikania bądź mrugania po wykryciu zmiany statusu. Ponieważ przekaźniki mają własne diody świecące jak również słychać jak się zmienia ich stan, element ten nie będzie mi potrzebny i usunę go.

Rzućmy sobie tylko okiem na drugi plik, czyli hingProperties.h Tutaj siedzą dane dotyczące sieci i płytki Arduino, która ma współpracować z projektem. Zauważmy zatem, że płytka ta będzie działać tylko w jednej sieci i tylko ta. Jeśli będziemy chcieli ją wymienić albo podłączyć się do innej sieci, musimy zmienić dane. Ale nie tutaj, o czym oznajmia napis na górze, lecz w trzeciej zakładce: Sectret Tab

Tu można podmienić wymienione elementy, gdyby zaistniała taka potrzeba. I tylko te, bo login jest dostarczany przez system i nie można go zmieniać samemu. Podobnie jak zmienne związane ze zdarzeniami kontrolowanymi zdalnie, to dodajemy i usuwamy gdzie indziej i zaraz pokażę gdzie.

Przejdźmy sobie do zakładki projektów Thing, kliknijmy w Shield – bo tak nazwaliśmy były już projekt do mrugania diodą i zmieńmy nazwę zmiennej led na przelacznik1 – bo tak nazwaliśmy zmienną odpowiedzialną za pamiętanie stanu przekaźnika w projekcie sterującej nimi w wersji offline’owej, a chcę by oba te projekty były spójne i miały te same nazwy składników. Po wejściu w edycję tej zmiennej możemy zmienić zarówno jej nazwę jak i typ oraz dwa parametry: możliwość aktualizacji zmiennej (Variable Permission) w dwie strony (Read & Write) albo tylko z urządzenia do chmury (Read Only). Drugi parametr (Variable Update Policy) decyduje o tym, czy aktualizacje będą przeprowadzane wyłącznie po zmianach stanów (On Change), czy wysyłane cyklicznie (Periodically). Ten parametr ma znaczenie dla obciążenia sieci i tylko w uzasadnionych przypadkach powinien być ustawiony w trybie ciągłym. Po zmianie samej tylko nazwy, bo reszta nam tutaj pasuje i niczego zmieniać nie będziemy, możemy wrócić do szkicu.

#include "thingProperties.h" // Dołącz plik z definicjami.
const byte przekaznik1 = 4;  // Port przekaźników.

void setup() {
  initProperties();                                  // Zaczytaj definicje z pliku thingProperties.h
  ArduinoCloud.begin(ArduinoIoTPreferredConnection); // Inicjuj połączenie z chmurą Arduino IoT Cloud
  pinMode(przekaznik1, OUTPUT);                      // Deklaruj porty przekaźników jako wyjścia.
}

void loop() {
  ArduinoCloud.update();
  digitalWrite(przekaznik1, przelacznik1); // Ustaw przekaźnik zgodnie ze stanem przełącznika.
}

Zrobimy tutaj spore porządki, zostawiając tylko to, co niezbędne. A więc: określamy adres pierwszego przekaźnika, który producent ustalił na stałe, przydzielając mu port czwarty. Deklarujemy go jako wyjściowy. Pozbyłem się wszelkich elementów związanych z komunikacją za pomocą portu szeregowego. W pętli głównej, gdy użytkownik smartfona kliknie w przełącznik, nastąpi przepisanie pozyskanego z chmury stanu przełącznika na port przekaźnika i to już wszystko.

#include <ArduinoIoTCloud.h>
#include <Arduino_ConnectionHandler.h>
const char DEVICE_LOGIN_NAME[] = "";
const char SSID[] = SECRET_SSID;
const char PASS[] = SECRET_OPTIONAL_PASS;
const char DEVICE_KEY[] = SECRET_DEVICE_KEY;

bool przelacznik1;

void initProperties() {
  ArduinoCloud.setBoardId(DEVICE_LOGIN_NAME);
  ArduinoCloud.setSecretDeviceKey(DEVICE_KEY);
  ArduinoCloud.addProperty(przelacznik1, READWRITE, ON_CHANGE);
}

WiFiConnectionHandler ArduinoIoTPreferredConnection(SSID, PASS);

Jak widać, w drugiej zakładce sama już zaktualizowała się nazwa zmiennej z led na przelacznik1. Ponieważ nie potrzebuję w szkicu podprogramów, które wykonują się zaraz po zaistnieniu zdarzenia, zmodyfikowałem tę linię, ale nie jest to konieczne, a poza tym ten plik aktualizuje się podczas gmerania w zmiennych i zapis ów i tak wróci na miejsce.

Ostatnim etapem będzie modyfikacja panelu sterującego w zakładce Dashboard. Wyrzucimy kafelek z diodą świecącą, ponieważ ten z przełącznikiem ma już funkcjonalność wskaźnika stanu – zmienia mu się kolor i napis. Odpowiada za to „ptaszek” przy opisie Show ON/OFF labels. Nazwę Przekaźnik 1, która widnieje na ikonce, wybrałem, ponieważ jest najbardziej intuicyjna. Powiązanie stanu tego pstryczka ze zmienną przełącznik1 należy zrealizować, klikając w ikonkę Change pod napisem Linked Variable.

I to już wszystko. Mamy teraz możliwość sterowania przekaźnikiem, ale tylko jednym i tylko z telefonu albo komputera. Jak to zmienić – o tym opowiem w następnym artykule.