Zaczynając serial o ESP8266 odgrażałem się, że będę robił na nim nową wersję automatyki domowej, bowiem moja obecna, której fragmenty są opublikowane w „Moje projekty” technologicznie jest zabytkiem kwalifikującym go do muzeum techniki. Powstała co prawda nie tak znów dawno temu, ale już wtedy była oparta o dość przestarzałą technologię i przede wszystkim jej ograniczeniem jest język programowania, w którym się specjalizowałem, a w którym, niestety, niewiele można. Jednakże obecna automatyka jest, działa, sprawdzona, niezawodna, po co ruszać? A po co fani motoryzacji marzą o nowym, lepszym aucie mimo, że stare jest cały czas dobre? Po co wędkarzowi nowa superduperwędka z nanorurkowych włókien opracowanych specjalnie dla stacji kosmicznych, skoro dokładnie taką samą rybę można złapać na starego bambusa? Po co audiofilowi nowe marmurowe podstawki pod przewody zasilające (z dodatkową gąbką [naturalną!] tłumiąca wibracje, dzięki czemu od przewodów zasilających wibrujących w polu magnetycznym ziemi nie przenikają nam zakłócenia), skoro ledwo skończył spłacać kredyt po zakupie specjalnych przewodów całkowicie odpornych na przenikanie jakichkolwiek zakłóceń (15000zł/szt. w promocji)?

Ano właśnie…

No dobra, skoro już ustaliliśmy, że generalnie chodzi o niezbyt szkodliwego świra, możemy przejść do rzeczy 🙂 Obecna moja automatyka jest mało rozwojowa. Nie daje się sterować zdalnie, ciężko się zarządza, jakiekolwiek zmiany działania wymagają modyfikowania kodu i jego ponownego załadowania do urządzenia (znajdującego się niekoniecznie w ogólnodostępnym miejscu), poza tym rozrosła się na tyle, że wykorzystywany w niej do komunikacji między modułami interfejs RS485 zaczął już mi sprawiać problemy (jeden dość odległy moduł nie chce „gadać” z resztą). Zamarzyło mi się więc coś nowoczesnego, zwłaszcza, że obecnie można to osiągnąć naprawdę małym kosztem. 
W ostatnim wpisie n/t ESP8266 pojawił się komentarz kolegi Barta, w którym pada teza, że po co odkrywać koło od nowa, skoro są gotowe rozwiązania z projektami typu Open. No są. Domoticz, Supla, mnóstwo rozwiązań amatorskich… Co mi więc w nich nie pasuje, że chcę robić swoje własne? Czemu nie skorzystać z gotowych rozwiązań, przetestowanych przez setki użytkowników?
Po pierwsze – to nie tak, że nie chcę. Oczywiście, nie ma sensu robić od nowa czegoś, co już istnieje i ma się dobrze, dlatego też moja nowa automatyka ma z założenia opierać się o Domoticza. Bo go już odrobinę znam, bo świetnie działa jako sterownik nawadniania naszego ogrodu, bo jest na tyle popularny, że nie ma problemu z przykładami, implementacjami i jest się na czym wzorować i wreszcie: bo ma fajny GUI 🙂
Po drugie: chcę tego Domoticza, ale jednocześnie nie chcę. O ile sam Domoticz mi się bardzo podoba, tak w ogóle mi się nie podobają typowe projektowane pod niego moduły wykonawcze. W Domoticzu i w Supli o ile dobrze się zorientowałem, także serwer odpowiada za wszystko, za każdą aktywność. Wcisnąłem przycisk włącznika światła? Moduł wykonawczy wysyła informację o tym do serwera i to serwer domoticza zapala światło. Albo gasi. I super, takie podejście wiele rzeczy upraszcza i umożliwia bardzo wygodne sterowanie tym wszystkim. Co jednak, gdy serwer nam z jakichkolwiek przyczyn zdechnie? Gdy akurat zmuli się wifi? Gdy zadzieje się w naszej instalacji cokolwiek, co spowoduje, że przestanie ona funkcjonować? 
Po trzecie wreszcie – tu piszę głównie o Domoticzu, bo Supli nie znam – nie podoba mi się, że mimo mnogości dostępnych rozwiązań, próżno w nim szukać wydawać by się mogło oczywistych rozwiązań. Najlepszy przykład: włącznik typu timer, włączający coś na zadany czas, ale z możliwością włączenia na stałe. Jest to jedna z podstawowych funkcjonalności mojej obecnej automatyki: w pomieszczeniach typu garaż, czy schody, wszędzie tam, gdzie światło zapala się zwykle „na chwilę”, a potem bywa, że zapomina zgasić fajnie jest mieć światło, które zapalone, zgaśnie samo po zadanym czasie. Jednocześnie, ponieważ w każdym z takich miejsc czasem jest potrzeba zapalenia światła na dłużej, wciśnięcie i przytrzymanie przycisku przez krótką chwilę (1,5s) powoduje włączenie światła na stałe, aż do jego manualnego zgaszenia. W domoticzu dla wyłącznika można zdefiniować timer, ale bez opcji zapalenia na stałe. Jeśli chcemy włączać coś czasowo z możliwością uruchomienia na stałe, musimy mieć dodatkowy wirtualny przycisk. Typowe implementacje w ogóle nie rozróżniają tego, w jaki sposób ktoś wcisnął wyłącznik, nie wspiera tego też w żaden sposób sam Domoticz, więc oficjalnie nici z rozróżniania czasu trzymania wciśniętego przycisku.
I na samym końcu, jako „po czwarte” wymienię sobie wcale nie najmniej ważny argument: własne dobre samopoczucie, że się zrobiło coś samemu, a nie wzięło gotowca 🙂

Podsumujmy zatem wstępne założenia automatyki V2:

1.  autonomiczne moduły wykonawcze potrafiące samodzielnie realizować przypisane im funkcje, choć w podstawowym zakresie. Jeśli moduł ma sterować oświetleniem salonu, to ja mam mieć możliwość zapalania i gaszenia światła w tymże salonie bez względu na dostępność internetu, wifi, kondycję serwera czy fakt,  że oboje moich dzieci akurat po gigabajcie danych z internetu ściąga, a małżonka w tym czasie film HD wprost z sieci ogląda (światłowód mamy, a co!). Choćby salon ostatnim miejscem na Ziemi miał się ostać, to jeśli tylko będzie w nim zasilanie, salonowy sterownik świateł ma działać! Amen!
2. Współpraca z domoticzem, ale „równoległa”, bez nadrzędnej roli tegoż. Włączyłem coś – informacja do domoticza, że zmienił się stan, niech to będzie widoczne na pulpicie. Chcę to teraz wyłączyć z pulpitu – informacja do sterownika z żądaniem wyłączenia.
3. Modułowość. Koniec z urządzeniami na miarę, robionymi pod konkretne zastosowanie. Teraz ma być automatyka budowana z klocków: klocek z CPU i dopinane do niego moduły wejść/wyjść, dopina się tyle, ile potrzeba, CPU ma je samo rozpoznać i pozwolić nimi sterować. Komunikacja między modułami: szyna I2C
4. Moduł CPU zbudowany w oparciu o ESP8266, nad którym moje zachwyty obecnie nie mają końca, więc oczywistym jest, że wybór padł właśnie na niego.

I to właściwie tyle. Tak to ma wyglądać:

Całość do montażu w rozdzielni, na szynie DIN, moduł CPU jest jednocześnie zasilaczem dla modułów IO i ich jednostką sterującą. Typowy moduł IO zaś (i póki co jedyny, którego projekt mam ukończony) to zespół czterech wejść i czterech wyjść zbudowany w oparciu o ekspander I2C PFC8574:

Układowo jest to tak proste, że ciężko właściwie coś więcej o tym napisać: sprawdzone w dotychczasowych projektach układy wejściowe z zabezpieczeniem przed zakłóceniami, wyjścia na triakach, sercem urządzenia jest ekspander I2C PCF8574. Tak to wygląda na PCB:

Dwie płytki, jedna wtykana w drugą, całość dopasowana do typowej obudowy Kradex Z107:

Płytka z ekspanderem jest ustawiona pionowo, dzięki czemu po otwarciu samego wierzchu obudowy, bez konieczności jej rozkręcania jest możliwy dostęp do dip-switcha umożliwiającego ustawienie adresu modułu. To, co pokazuję to jeszcze nie jest wersja ostateczna, być może coś tu jeszcze ulegnie zmianie, niemniej tak, jak jest, już by w zasadzie mogło być. Tego typu moduły IO pokryłyby właściwie ogromną większość typowych zastosowań automatyki, ale bazując na tym projekcie można bezproblemowo wykonać też moduł z ośmioma wejściami, jeśli komuś tychże byłoby za mało.