Openwrt

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ć.

Pisałem niedawno o pracach, które prowadziłem w garażu . Przypomnę, że zmiany miały związek z instalacją napędów firmy Life do bramy wjazdowej i bramy garażowej. Wypadałoby trochę ulepszyć to co wyprodukowała fabryka i podłączyć siłowniki do systemu automatyki domowej. Nie będzie to trudne.

Najstarsi czytelnicy bloga być może pamiętają, że dawno, dawno temu przygotowałem sterowanie bramą z napędem Somfy przez telefon. Opierało się ono na oprogramowaniu z projektu Domotic Home i wydawaniu komend przez pilota podłączonego do karty przekaźnikowej routera . Teraz będzie prościej i tak jak chciałem od początku. Przy starym napędzie zasilanie z garażu było poprowadzone do centralki przy bramie wjazdowej, natomiast ona sterowała oświetleniem przed garażem - były więc poprowadzone przewody spowrotem do garażu. Teraz oświetleniem będzie sterować bezpośrednio Arduino, więc pozostąły 3 wolne przewody idące do bramy - w sam raz do sterowania ruchem skrzydeł.

Uruchomiłem już “internetowy domofon”. Za każdym razem gdy ktoś przy furtce wciśnie przycisk domofonu, dostaję powiadomienie e-mailowe z linkiem do zdjęcia drogiego gościa. Ponieważ w telefonie używam K-9 mail z obsługą IMAP IDLE, jako programu pocztowego, więc mail dociera do mnie w ciągu kilku sekund. Dzięki temu wiem, kiedy ktoś mnie odwiedza a nie ma mnie w domu. Gdy przyjdzie ktoś znajomy, mogę zadzwonić i powiedzieć, żeby poczekał, bo właśnie wracam do domu. Wkrótce będę mógł też otworzyć z telefonu furtkę i wpuścić gościa na posesję. Podobnie w przypadku śmieciarzy, gdy przyjadą odebrać śmieci, a furtka będzie zamknięta. Gdyby natmiast ktoś chciał się włamać, to istnieje pewne prawdopodobieństwo, że zadzwoni wpierw domofonem, żeby upewnić się, że nikogo nie ma w domu - wtedy jego zdjęcia trafią bezpiecznie na serwer internetowy poza domem.

Dzisiejszy wpis będzie nietypowy. Poza opisem instalacji automatyki domowej, będzie obejmował także przemyślenia dotyczące ogrzewania domu . Obserwacji trochę już mam, jako, że instalacja w kotłowni ma już trzy sezony grzewcze. Trzeba jednak wyraźnie zaznaczyć, że nie jestem hydraulikiem i mój opis może nie być w 100% fachowy, choć myślę, że jednak dość trafny. Nie zabraknie oczywiście informacji o monitorowaniu pracy kotła, sterowaniu ogrzewaniem przez OpenWRT i Arduino, cyrkulacji ciepłej wody użytkowej zgodnie ze zwyczajami domowników czy liczeniu zużycia węgla. Z rozmów z właścicielami kotłów na ekogroszek można wysnuć wniosek, że obserwują i eksperymentują z ustawieniami wszyscy, natomiast niektórzy robią to spędzając czas w kotłowni, a inni, jak ja, przez ekranem monitora, przeglądając wykresy. Czasem mam wręcz wrażenie, że spalanie ekogroszku, to rodzaj hobby ;-)

Sercem mojej kotłowni jest Klimosz Ling 15kW ze sterownikiem RecalArt Premium. Gdy wybierałem kocioł, brałem pod uwagę także to, jaki jest zamontowany sterownik, natomiast zupełnie nie analizowałem możliwości sterowania nim “z zewnątrz”, a są niestety słabe, co nie znaczy, że żadne. Gdybym miał wskazać lidera sterowania piecami na paliwo stałe, to byłby nim z pewnością Bruli wraz z platformą eSterownik.pl - pozwalający zarówno monitorować, jak i zmieniać dowolne parametry ogrzewania przez Internet. Całość świetnie przemyślana i estetycznie wykonana przez ludzi bardzo mocno zaangażowanych w temat, dla których to co robią jest pasją - to się daje wyczuć podczas rozmowy telefonicznej. Niestety eSterowniki nie obsługują zaworów mieszających, które ja bardzo wysoko cenię w instalacji.

Zgodnie z koncepcją , przygotowałem część sprzętową mojego systemu odpowiedzielnego za podlewanie ogródka i parę innych rzeczy. Obiecałem, że wkrótce napiszę, jak to wszystko oprogramować. Wcześniej jednak należałoby zaprojektować komunikację różnych elementów systemu - nie tylko części odpowiedzialnej za podlewanie, ale urządzeń związanych z automatyką domową w szczególności.

Jak już wiecie z koncepcji systemu , “mózgiem” będą routery (jeden główny, drugi zapasowy) z oprogramowaniem w php. Oczywiście nie muszą to być routery - w szczególności mogą to być serwery, komputery, cienkie klienty lub inne urządzenia, na których można uruchomić Linuksa. Router (z zainstalowym OpenWRT ) jest o tyle dobrym wyborem, że jest energooszczędny a dodatkowo i tak działa cały czas pełniąc inne funkcje.

Gdy dwa lata temu tworzyłem poprzedni system podlewania ogródka, który opisałem gościnnie na Nibyblogu, wiedziałem, że musi być sterowany “przez Internet”, z możliwością autonomicznego działania. Nie znałem jeszcze wtedy Arduino , a rozwiązanie zostało oparte o kartę przekaźnikową podłączoną przez USB do routera. Nie powiem, żeby źle działało, ale pora w zabawie pójść dalej. Pretekstem ku temu jest chęć rozbudowy mojego systemu inteligentnego domu z użyciem Arduino . System podlewania ma być swego rodzaju poligonem doświadczalnym - na nim będę testował stabilność rozwiązania i tworzył pierwsze wersje oprogramowania, którego kawałki potem użyję potem w głównym module.

Nadal zakładam, że nadrzędnym elementem w systemie będzie router z OpenWRT z oprogramowaniem głównie w php. Arduino za to będzie posiadać większą autonomię. Nie będzie, jak karta przekaźnikowa, dostawać prostych poleceń - włącz, wyłącz, przełącz, tylko bardziej złożone, w rodzaju - podlewaj trawę przez 20 minut a pozostałe przez 15. Arduino będzie wykonywać te polecenia i raportować do routera. Co na tym zyskuję? Jeżeli podczas podlewania zawiesi się router, wystąpią problemy z programem w php (np. padnie system plików, pendrive albo hub usb), to czynność zostanie dokończona, a przede wszystkim zatrzymana zgodnie z planem. Jeżeli natomiast popsułoby się Arduino, to router mnie o tym poinformuje i będę miał szansę interweniować.

Co więcej, zyskuję możliwość wprowadzenia, przynajmniej częściowej, odporności na awarię głównego routera sterującego. W przypadku gdy przestanie on działać lub program sterujący nie będzie odpowiadać, chciałbym, żeby jego funkcję przejęło inne urządzenie. Wszak w domu są 3 routery z OpenWRT, więc możliwości jest sporo i zakładam, że przynajmniej część funkcji mogą realizować wymiennie. Co prawda innym założeniem jest, że system nie ma być używany do zastosowań “krytycznych”, czyli takich, których niewykonanie lub złe wykonanie mogłoby czymś poważnym zgrażać, ale czemu ma wyschnąć trawnik przez awarię routera, gdy można się przed tym zabezpieczyć? Będzie więc mój system podlewania pracował w “klastrze niezawodnościowym”… A co? Trzeba mieć fantazję. Oczywiście nie zabezpieczy to przed awarią Arduino, ale o tym zostałbym powiadomiony.

Minęło już trochę czasu odkąd testuję Arduino Uno R3 , więc pewnie pora zbudować koncepcję rozbudowy mojej niskobużetowej, amatorskiej instalacji inteligentnego domu , o której pisałem wcześniej. Chciałbym dołożyć dodatkowe funkcjonalności, a przy okazji pozbyć się jednej z kart przekaźnikowych na rzecz Arduino (skoro już jest, nie ma potrzeby mnożyć bytów). Nie chcę oczywiście odcinać się od routerów z OpenWRT i tego, co już osiągnąłem. Pora podsumować cały projekt, stan obecny i wizję przyszłości.

Stan obecny

Na początek małe podsumowanie (w skrócie) tego, jak system wygląda bez Arduino. Centralnym urządzeniem w środowisku automatyki domowej jest router TPlink TL-WR1043ND z zainstalowanym systemem OpenWRT. Dostarcza on Internet (sieć w ogólności) przewodowo do różnych punktów w domu i bezprzewodowo. Zlokalizowany jest w garażu, skąd rozchodzi się gwiaździście okablowanie do dużej części pomieszczeń w domu. Do routera podłączony jest dysk USB, który w przeszłości był źródłem dla odtwarzacza multimediów podłączonego do telewizora w salonie. W tej chwili z tej funkcji router został odciążony przez Iomega iConnect , stanowiący centrum składowania i serwowania danych. Do routera podłączona jest za to magistrala one-wire i kilkanaście termometrów w całym domu (w tym wiele w kotłowni do monitorowania kotła). Router gromadzi dane, rysuje wykresy i je udostępnia. Analizuje też temperatury z kotłowni i powiadamia smsem o różnych zdarzeniach, np. wygaśnięciu pieca. Router otwiera też bramę wjazdową, co opisywałem ostatnio i steruje ogrzewaniem (przełącza kocioł na ekogroszek w coś w rodzaju trybu bardzo oszczędnego).

Od jakiegoś czasu “bawię się” Arduino, a swoje doświadczenia staram się tu opisywać. Pisałem też kiedyś o mojej koncepcji inteligentnego domu (lub jak kto woli domowej automatyki) w oparciu o OpenWRT. Do rozpoczęcia przygody z Arduino skłoniła mnie właśnie chęć rozbudowy tego systemu.

OpenWRT zainstalowany w routerze jest świetny, elastyczny, linuksowy, jednak trochę brakuje mu możliwości z realnym światem. Problem w dużej części rozwiązał zakup karty przekaźnikowej wyposażonej dodatkowo w wejścia, jednak cały czas mi czegoś brakowało.

Jakiś czas temu opisywałem prosty system monitoringu oparty o kamerę Edimax IC3030 . Do tej pory zapisywałem (i wysyłałem dalej) obraz z kamery wyłącznie po wykryciu ruchu. Z czasem zacząłem się zastanawiać, czy nie rozszerzyć monitoringu o ciągłą rejestrację. Założyłem, że dobrze byłoby zapisywać obrazy z kamery co kilka sekund i gromadzić je na ukrytym nośniku w domu (oczywiście obsługiwanym przez router z OpenWRT). Tutaj w szczegóły nie będę się wdawał z wiadomych względów.

Po co sterować bramą wjazdową inaczej niż standardowym pilotem? Powodów jest kilka. Po pierwsze można otworzyć bramę jadąc do domu, kilkaset metrów wcześniej, żeby nie czekać aż się otworzy. Po drugie gdy trzeba zamknąć bramę (a nie zrobiło się tego będąc w samochodzie), to nie trzeba szukać drugiego pilota, który leży gdzieś w domu. Po trzecie, będąc na nartach nie trzeba prosić nikogo, żeby w dzień zabierania śmieci podjechał z kluczem uchylić furtkę, żeby śmieciarze opróżnili kosz (bo jak nie opróżnią to przez kolejny tydzień nie będzie gdzie wyrzucać śmieci i popiołu z pieca). Można zamiast tego rano otworzyć bramę przez Internet (o furtce też można pomyśleć, ale to kiedy indziej). Oczywiście ostatni przypadek może wydać się wyimaginowany, bo przecież można zrobić osobną furtkę tylko do koszy. Oczywiście, tylko trzeba ją mieć. A jak się nie ma, to można w 15 minut zrobić zdalne otwieranie bramy (z programowaniem w trochę ponad pół godziny).