Automatyka Domowa V2 – wstęp

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

Document1_-_Microsoft_Word_2017-03-17_10-49-14

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:

2_Schematic_-_DMy_DocumentsPrywatneProjektyAu_2017-03-17_11-23-43

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:

1_Board_-_DMy_DocumentsPrywatneProjektyAutoma_2017-03-17_11-25-19

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

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. 

This entry was posted in , , . Bookmark: permalink.

6 Responses to Automatyka Domowa V2 – wstęp

marek
Commented:  18 marca 2017 at 09:02

Cześć,jaką max mocą można obciążyć takie wyjście na triaku, takim triaku za małe pieniądze? 🙂

    wszystko zależy od tego, jakiego triaka dasz. Używane przeze mnie BTA10-600 (2,50zł w PL, oraz około 80gr na aliexpress) mają maksymalny ciągły prąd 10A, czyli teoretycznie taki prąd mogłyby przenosić. Oczywiście jazda na maksymalnych parametrach to zwykle jest krótka jazda, ale i nie ma potrzeby takich skrajnych wartości wykorzystywać. By mieć bezpieczny zapas od góry zakładam sobie do 600W na kanał, a ponieważ i tak duża większość aktualnie używanych żarówek to ledy i energooszczędne, realnie rzadko kiedy osiągam nawet połowę tej wartości.

    Prócz triaków rzeczą ograniczającą moc jest również szerokość ścieżek na PCB – nietrudno zauważyć, że ścieżka zasilająca triaki nie jest zbyt szeroka, ma 1mm szerokości, co się przekłada na 1-2A maksymalnego prądu (czyli może z 200W na wszystkie cztery kanały łącznie by było). Szerszej ścieżki dać nie mogłem, bo między nogami triaka by nie przeszła, to ograniczenie więc omijam prosto: w czasie montażu na ścieżki przenoszące moc nalutowywuję drut fi0,8

marek
Commented:  19 marca 2017 at 09:54

Dziękuję za obszerną odpowiedź, śledzę temat i być może pokuszę się o złożenie czegoś podobnego 🙂
Pozdrowienia i sukcesów życzę 🙂

Bart
Commented:  21 marca 2017 at 08:59

Czy moduły które konstruujesz będą kompatybilne z domoticzem czy będzie też trzeba dograć jakieś pluginy do niego/pomajstrować coś?
Jak już na triakach sterujemy światłem to można by się pokusić o detekcję zera i mamy możliwość fazowego sterowania jasnością (albo prędkością tłoczenia jakiejś pompy itp). Oczywiście nie wszystkie źródła światła będą kompatybilne ale najprostsze żarówki owszem.

    Cóż… i tak i nie. Znaczy, powinny być kompatybilne, ale z uwagi na dodatkowe funkcjonalności, jak choćby rozróżnianie „krótkiego” i „długiego” przyciśnięcia włącznika zapewne skończy się na konieczności dogrania czegoś do domoticza. Ale nawet bez przeróbek powinno to współpracować poprzez proste odwołania do elementów kreowanych w domoticzu jako wirtualne.
    Cały projekt przerodził się w spółkę Joint-Venture z kolegą, który co tu dużo mówić, kodowaniem w C++ zajmuje się profesjonalnie (a nie dopiero uczy, jak niżej podpisany), więc ta część zagadnienia to zasadniczo jego działka będzie 🙂

    Triaki z regulacją fazową – bardzo ciekawy pomysł i chyba wart rozpatrzenia, pomyślę nad tym jako nad osobnym modułem.

trash_bin
Commented:  23 marca 2017 at 19:00

Pozwolę się dołączyć, jako ów kolega zajmujący się kodowaniem. Na razie planujemy, jak napisał Jarek.P, dodać integrację z domoticzem na podstawowym poziomie. Na początek spróbujemy zrobić obsługę długich wciśnięć przy użyciu osobnego widgetu: jeden widget będzie odpowiadał za przyciśnięcie krótkie, drugi – za długie. Jak doprowadzimy prace nad kodem do stanu używalności i okaże się, że takie rozłożenie na osobne widgety jest mało wygodne, to postaramy się stworzyć wtyczkę do domoticza z obsługą wykrywania długich wciśnięć. Mamy co prawda wątpliwości, czy będzie to używalne na ekranach dotykowych, ale czas pokaże. Może na ekranach dotykowych zamiast wykrywania krótkiego i długiego wciśnięcia będzie reakcja na przyciśnięcie i (powiedzmy) przesunięcie? Albo od razu przesuwanie w dwie strony, np. w lewo – którko, w prawo – długo? „Się zobaczy” 🙂

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Archiwum

  • 2021 (3)
  • 2020 (2)
  • 2019 (8)
  • 2018 (9)
  • 2017 (24)
  • 2016 (66)
  • 2015 (39)

Wyszukiwanie

Licznik odwiedzin

0354620
Visit Today : 42
Hits Today : 51
Total Hits : 1158963
Who's Online : 2