Od jakiegoś czasu rośnie popularność zapasowych/awaryjnych źródeł zasilania dla naszych telefonów i innych gadżetów. Kiedyś sytuacja była prosta - bateria w telefonie starczała na tydzień bądź dwa tygodnie użytkowania, a jak ktoś miał naprawdę duże wymagania to kupował sobie zapasowy akumulator, który w razie potrzeby wymieniał w telefonie. Pewnie mało kto już pamięta tamte czasy. Potem telefony zaczęły robić się coraz mniejsze, podobnie jak baterie, a użytkownicy przyzwyczaili się do częstszego ładowania swoich gadżetów. Gdy już doszliśmy do etapu miniaturyzacji, przy którym użytkowanie aparatu stawało się niewygodne ze względu na zbyt mały rozmiar i możliwość łatwego zgubienia, trend się odwrócił. Pojawiły się smartfony, które zaczęły rosnąć do rozmiarów, które części osób kojarzą się z początkami ery GSM w Polsce w połowie lat 90. poprzedniego wieku. Czas pracy na jednym ładowaniu jednak nie wrócił do “starych, dobrych czasów”. Duże, jasne ekrany, wymagania wydajnościowe i funkcjonalne sprawiają, że mimo pewnego rozwoju w branży akumulatorów, czas pracy smartfonów na jednym ładowaniu zwykle nie jest imponujący. Bywają oczywiście wyjątki, natomiast 2 dni od odłączenia ładowarki do ponownego podłączenia do gniazdka elektrycznego nie jest złym wynikiem.

Pisałem ostatnio o połączeniu Raspberry Pi z Integrą produkcji Satela z użyciem interfejsu szeregowego. Przyszła pora, żeby napisać coś więcej o tym przedsięwzięciu od strony programowania - zarówno samej centrali alarmowej, jak i Raspberry Pi - w Node.js, bo jego używa obecnie główna część mojego “inteligentnego domu”. Node.js świetnie nadaje się do obsługi systemu opartego na zdarzeniach, ale oczywiście każdy może przełożyć zamieszczony tu kod na swój ulubiony język.

Tytuł wpisu wyraźnie wskazuje na to, że będziemy monitorować także wejścia, tymczasem opis protokołu opublikowany przez Satela wskazuje, że łatwo możemy dostać się wyłącznie do stanu wyjść (przez komendę 0x17). Oczywiście to żaden problem, ponieważ centrala pozwala definiować wirtualne wyjścia, których stan zależy od stanu wejść (czyli np. czujek ruchu). Możemy więc na bieżąco mieć podgląd wszystkich czujek (w końcu system automatyki domowej ma swoje “oczy”), ale też sprawdzać wiele więcej - stan zasilania, akumulatora, uzbrojenia i wywołania alarmu, sabotażu, przyciśnięci przycisków w pilotach ABAX, rozpoczęcie odliczania czasu na wyjście, alarmy wstępne, itp.

Minęło trochę czasu od ostatniego wpisu, wiele też nowych urządzeń powstało w mojej (i nie tylko) instalacji inteligentnego domu - sterowanie roletami, światłami i bramami, nawadnianie z analizą prognozy pogody i kilka innych drobiazgów. To co najbardziej cieszy, to że wszystko działa w pełni stabilnie i bezawaryjnie - zarówno urządzenia oparte o Arduino, jak też o ESP8266. Także system nadrzędny na Raspberry Pi funkcjonuje nieprzerwanie. To wszystko jednak w jakimś stopniu było już opisywane na blogu (choć są oczywiście aspekty, które jeszcze opiszę). Dzisiaj natomiast chciałbym poruszyć temat zupełnie nowy - integrację z systemem alarmowym Satel Integra.

Jaki jest cel integracji? System automatyki domowej potrzebuje zmysłów - czujników, a tymi dysponuje już system alarmowy. Do czego może się to przydać? Do zapalenia światła, gdy zostanie wykryty ruch, to zamknięcia rolet, gdy zostanie uzbrojony alarm, do przesłania mailem zdjęcia gdy ktoś pojawi się w ogrodzie przy uzbrojonym alarmie, do wysłania informacji o wyłączeniu zasilania. Zastosowania ogranicza wyłącznie wyobraźnia i umiejętności implementacji. Oczywiście wiele z tych funkcji mógłby realizować odpowiednio złożony system alarmowy, jednak skoro mamy już “inteligentny dom”, to on powinien sterować tymi zadaniami - szczególnie, że jest bardziej elastyczny i łatwiejszy w programowaniu.

Pierwsze zabawy z ESP8266 już za mną, pora zrobić coś pożytecznego. Na pierwszy ogień pójdzie współpraca z czujnikiem wilgotności i temperatury - DHT22, a dokładniej - jego obudowaną wersją - AM2301. ESP będzie pracował pod kontrolą firmware NodeMcu , co oznacza, że program będziemy tworzyć w języku Lua.

Dzisiaj świat obiegła radosna nowina. W końcu w sprzedaży pojawił się następca Raspberry Pi B+. Dostaniemy 4 rdzenie (Cortex-A7), 1GB RAM i 4USB. Cena nie ulegnie zmianie, stracimy trochę na większym poborze prądu. Pewnie można się spodziewać wysypu nowych zastosowań Maliny.

Moim zdaniem dopiero teraz warto myśleć o podłączeniu RPi do telewizora. Oczywiście już wcześniej radziło sobie nieźle XBMC, ale czuję, że teraz nadchodzi jego czas na tym polu. Co nie zmienia faktu, że i domowy mini-serwerek z większą mocą będzie mile widziany. Szkoda tylko, że twórcy nie zdecydowali się na gigabit ethernet i USB 3.0. Pewnie i tego doczekamy się w jakiejś wersji 2+.

Ostatnio pisałem o ESP8266 , dzisiaj pora rozszerzyć temat. Wiemy już jak podłączyć układ do komputera oraz jak wgrać firmware NodeMCU. Nasz ESP łączy się też automatycznie z domową siecią wifi. Pora zabrać się za programowie w Lua. Na razie trochę dla testu, trochę dla zabawy, trochę żeby poznać możliwości samodzielnej pracy układu, jak i jego stabilność.

Połączmy się więc z ESP8266 przez port szeregowy, jak dotychczas. Ostatnio robiłem to z użyciem oprogramowania Arduino, ale na dłuższą metę to mało wygodne. Pod Linuksem dużo prościej użyć screena, np. wydając komendę screen /dev/ttyUSB0 9600. Pod windows można użyć dowolnego teminala, jak choćby putty , który poza tym, że jest klientem ssh, to może działać jako terminal. Po połączeniu otrzymujemy znak zachęty interpretera Lua/NodeMCU.

Hit! Czegoś takiego mi było trzeba. W bardzo umiarkowanej cenie można kupić niewielki układ, który nie tylko połączy Arduino z siecią bezprzewodową (także w standardzie “n”), ale także w wielu przypadkach będzie pracować bez Arduino. Poznajcie ESP8266, układ który wprowadzi sporo zamieszania w “Interncie rzeczy”.

Parametry układu imponują (jak za tę cenę i na tę wielkość). Co więc przydatnego dostajemy? Na początek - całkiem szybki procesor (RISC, 80MHz) i wcale niemało pamięci. Przede wszystkim jednak wsparcie dla WiFi, a konkretnie dla protokołów 802.11 b/g/n, w tym zarówno dla łączenia się do sieci, jak i tworzenia Access Pointa, przy czy obługiwany jest zarówno WEP, jak i WPA, WPA2 i WPS. Do tego mamy port szeregowy, przez który będziemy się komunikować z Arduino i zestaw prostych komend AT, które pozwolą nam zrobić co chcemy nie obciążając za bardzo układu nadrzędnego. I to wszystko co do szczęścia trzeba, żeby wykorzystać ESP8266 do komunikacji Arduino ze światem przez Wifi. Nie wszystko jednak, co dostajemy od tegoż układu.

Jak już kiedyś pisałem , w domu mam kilkanaście termometrów, podłączonych do systemu autmatyki domowej. Połączone są one równolegle przez magistralę dwuprzewodową do konwertera 1-wire, który z kolei współpracuje z routerem. A raczej tak było. Ponieważ teraz zmieniam nieco architekturę systemu, a dane zbierać ma Raspberry Pi, znajdujący się w innym niż router miejscu, postanowiłem zmienić też sposób zbierania temperatur. W ten sposób powstało urządzenie, oparte o Arduino, które odczytuje dane z termometrów DS28B20 i regularnie raportuje odczyty przez ethernet do serwera www. Jest to przy okazji test długodystansowy urządzenia, które praktycznie można zastosować w wielu małych kotłowniach.

Dzisiaj chciałem zaprezentować projekt, który nie jest ściśle związany z automatyką domową, ale Arduino zostało zastosowane w dość ciekawym miejscu. Uczestniczy w obsłudze plotera drukującego, choć nie wprost i nie tylko.

Ploter to taka duża drukarka. Wydruki do niego wysyła komputer, więc po co to komplikować? Dla wygody i oszczędności czasu. Przygotowanie 8 metrów kwadratowych wydruku przez dość młody komputer zajmuje kilkadziesiąt minut (przy dużym projekcie około 1GB pliku wyjściowego) - potem zaczyna się drukowanie. Oczywiście nic nie stoi na przeszkodzie, żeby plik do wydruku (prn) wygenerować raz, a potem tylko kopiować go na port drukarki/plotera. Jednak podczas wysyłania wydruku komputer musi być włączony. A bywa, że te same wydruki uruchamia się jeden po drugim przez parę godzin albo nawet dni. Co byłoby najwygodniejsze do obsługi plotera? Włącznik “drukuj” załączany rano i wyłączany gdy kończy się rolka papieru. Bez uruchamiania komputera. Do tego będziemy dążyć.

Użytkuję Arduino już od dłuszego czasu. Szybki przegląd archiwum bloga, podpowiada mi, że od dwóch lat. Muszę przyznać, że jestem bardzo zadowolony z automatyki zbudowanej na jego bazie. Koncepcja i środowisko od początku bardzo mi się podobały, natomiast zaskoczyła mnie bardzo pozytywnie stabilność rozwiązania. Nic się nie zawiesza, jest bezobsługowe. “Produkcyjnie” w systemie automatyki domowej używam Arduino Mega (obsługujące głównie garaż, domofon i kotłownię) oraz Arduino Uno (do systemu nawadniania i kontroli części pomieszczeń w piwnicy). Oba wyposażone są w Ethernet Shield oparty na układzie w5100, który jest bardzo prosty w osbłudzie i niezawodny. Jednym słowem - rewelacja.

Zawsze nadchodzi jednak czas, gdy trzeba coś zmeinić. Główną wadą “pełnowymiarowych” Arduino, poza ceną, jest wielkość. Są projekty, przy których rozmiar urządzenia ma znaczenie. Oczywiście pewną drogą do miniaturyzacji i optymalizacji kosztowej jest wykorzystanie samych mikrokontrolerów Atmel i potrzebnych elementów elektronicznych do budowy układów pod konkretne potrzeby. Ja jednak wybrałem inną możliwość - Arduino Pro Mini i jego klony.