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.
Tu z kolei dochodzimy do odpowiedzi na pytanie – dlaczego Arduino Uno, a nie konstrukcja własnych układów. Sprzęt ma być jak najbardziej standardowy i łatwy do zastąpienia sprawnym, w razie awarii. Coś się popsuje – wyjmujemy, ewentualnie wykręcamy, być może programujemy od nowa, podłączamy i znowu działa. Dlatego konstrukcja musi być oparta o proste klocki, z łatwą dokumentacją, żeby można było bez bólu do tego wrócić po dłuższym czasie. Ma to wyeliminować jedną z wad systemów autorskich – bez autora nie da się ich sensownie serwisować w razie awarii. Ma jednak pozostać względnie tanie i bardzo elastyczne w rozbudowie.
To ogólna koncepcja architektury systemu. Pora przejść do planowanych funkcjonalności. Nie ma być mniej funkcjonalnie niż było, wręcz przeciwnie. Ma być bardziej interaktywnie, szybciej i bardziej niezawodnie niż wcześniej. Trzeba jednak zacząć od odtworzenia funkcji wcześniejszego systemu, z ewentualnym poprawieniem ich działania.
Przede wszystkim pisanie o systemie nawadniania, zawiera w sobie niedopowiedzenie. Ma to być system nawadniania połączony z czymś w rodzaju alarmu czy monitoringu domu. Poza sterowaniem podlewaniem, zbieraniem informacji o opadach (w celu ustalenia koniecznej częstotliwości nawadniania), system ma także pilnować otwarcia drzwi do ogrodu, drzwi w piwnicy oraz informować gdy w pomieszczeniu pod tarasem pojawi się woda.
Informacje mają być zbierane przez Arduino, przekazywane do centralnego routera (a także do innych miejsc w przypadku jego awarii). O konieczności podjęcia dalszych akcji zadecyduje już router, który będzie wiedział co trzeba zrobić z informacją. Jeżeli przykładowo zalane zostanie pomieszczenie, to powiadomi mnie smsem, niezależnie od pory (odpowiednia treść wywoła głośny alarm w telefonie). Jeżeli zostaną otwarte drzwi od ogrodu przy założeniu, że „alarm jest uzbrojony”, będzie miała miejsce podobna akcja. Po 22 to router odpyta Arduino czy drzwi są otwarte i w razie czego przypomni mi, że ktoś ich nie zamknął na noc. Po godzinie przypomni się głośniej. Gdy spadnie deszcz Ardiuno także o tym poinformuje system nadrzędny, który przecież będzie decydował kiedy należy podlewać. W chwili gdy zajdzie taka potrzeba, to router wyśle informację, że należy zacząć nawadnianie oraz jak długo ma to trwać.
Takie są założenia. Co będzie do tego potrzebne? Jak już pisałem Arduino Uno, opisywany ostatnio Ethernet Shield, moduł przekaźnikowy, dwa czujniki zalania (jeden do pomieszczenia, drugi do czujnika deszczu), oraz dwa kontaktrony zamontowane przy drzwiach. Do sieci Arduino z powłoką ethernetową połączy się bezprzewodowo dzięki małemu routerowi w trybie bridge.
Co już mamy? Rozprowadzone wszystkie rury w ogródku, elektrozawory z doprowadzonym okablowaniem i inne oprzyrządowanie, które opisywałem na Nibyblogu. Jest też skrzynka elektryczna z transpormatorem 230/24V, czujnikami zalania i podłączonym okablowaniem – przez łączówkę LSA – dla łatwego łączenia, rozłączania i przejrzystości dokumentowania. Poprzednio była tam karta przekaźnikowa, wkrótce pojawi się Arduino.
Nie wygląda na skomplikowane, prawda? Bo nie jest. Pora przejść od słów do czynów, skoro mamy już wszystkie klocki do złożenia tej układanki i dobry plan.