Skocz do zawartości
sadziu

Początki automatyki w mieszkaniu

Pomocna odpowiedź

Napisano (edytowany)

Witam,

Chciałem opisać mój projekt automatyzacji, który zrealizowałem w mieszkaniu. Moje podejście jest zgoła inne od  wszechobecnego ESP8266 + WiFi. Całą sieć oparłem o magistralę CAN (tę stosowaną w samochodach). Wymaga to oczywiście trochę "przeróbek" w domu ale traktuję to niejako pole doświadczalne przed budową domu w przyszłości. Część elementów wykonałem we własnym zakresie, część to gotowe moduły. Pewnie większość z Was pomyśli "po co wymyślać koło od nowa" ale dla mnie budowa "od zera" jest niesamowitą frajdą. Ale zacznijmy od początku ...

Od jakiegoś czasu nosiłem się z zamiarem dołożenia inteligentnych świateł w mieszkaniu + pomiar temperatury/wilgotoności. Zaczęło się jednej płytki z STM32F103 z podłączonymi czujnikami SHT21. Pierwsze pomiary były zbierane przez przejściówkę UART -> USB podłaczoną bezpośrednio do komputera. Po kilku dniach uznałem, że warto dołożyć sterowanie żarówkami (230V). Kilka dni na przemyślenie tematu i powstały projekty pierwszej wersji HomeCAN. W założeniu ma być to modułowy system pozwlający na złożenie z klocków potrzebnej kombinacji i umieszczenie jej w puszce podtynkowej (trochę głębszej niż standardowa). Obecnie pod kontrolą systemu pracuje oświetlenie w całym mieszkaniu (żarówki 230V, taśmy LED 12V oraz WS2812B), czujniki temperatury, wilgotności oraz czujnik pyłu, SDS011. Sercem całej instalacji jest Home Assistant. Komunikacja między elementami systemu a Home Assistant działającym na moim małym serwerze realizowana jest za pomocą układu MCP2515 podpiętego do RaspberryPi + mały skrypt tłumaczący ramki CAN na wiadomości MQTT i odwrotnie.

Pora na dokładniejszy opis elementów systemu. Podstawową jest moduł z mikrokontrolerem pozwlający na sterowanie podłączonymi modułami i komunikację z innymi. mcu_top.thumb.jpg.2a9cc54f71d3bd1c6d3ec916272700ba.jpgmcu_bottom.thumb.jpg.348d3d57787276e83f9269cb9d914d0e.jpg

Jako nośnik dla sieci CAN wykorzystuję zwykłą skrętkę. Każdy moduł jest wyposażony w izolację galwaniczną z wykorzystaniem ADUM1201 i MCP2551. Zasilanie dla MCP2551 jest dostarczan również w skrętce (12V). Poniżej moduł MCU podłączony do testów.

mcu_node_during_tests.thumb.jpg.02a65fa0ea6cd65f72e7c915f0374ec5.jpg

Sam moduł z procesorem, MCU, nie potrafi zbyt wiele. Do pełnego wykorzystania potrzebne są inne moduły: do sterowania żarówkami 230V (+małymi silnikami typu wiatrak, małymi urządzeniami typu włącz/wyłącz), do sterowania taśmami LED 12V (z wykorzystaniem PCA9633/PCA9634).

ac_switch_bottom.thumb.jpg.5f23af07a2a214706a81f7a82ccd7bda.jpgac_switch_top.thumb.jpg.a841d6cdbd05b73c2f41caf9b68fd37b.jpgpca9633.thumb.jpg.2951f180a4fb28d194abc81f3e426909.jpgstacked_pca9634.thumb.jpg.fb80e3d164548868619b17810a841934.jpg

Bezpośrednio z modułu MCU można wysterować taśmy WS2812B (z osobnym zasilaniem) oraz podłączyć czujniki temperatury/wilgotności/oświetlenia działające na I2C lub SDS011 (poprzez UART lub PWM, na zdjęciu zamontowany pod kwiatkiem):

sds011_below_flower.thumb.jpg.d787d0cb65fb9bf36ffddd0ea9632945.jpg

W pierwszej iteracji zewnętrzych czujników temperatury/wilgotności/oświetlenia okazało się, że umieszczenie ich zbyt blisko parapetu całkowicie zniekształaca odczyty. W drugiej iteracji czujniki zostały odsunięte od parapetu na około 50 cm co wystarczyło do wyeliminowania problemu. Jedyne zakłocenia jakie teraz widać to zimowe wietrzenie mieszkania przez sąsiada z dołu.

external_sensors.thumb.jpg.58d4b383fb502f45124a47df27b4b28b.jpgexternal_sensors_2.thumb.jpg.1e7a882a0690b3283bfec14936117ebf.jpg

Łóżka dzieci zostały wyposażone w taśmy LED i małe klawiaturki membranowe, pozwlające na wybranie predefiniowanych efektów świetlnych. Panel Home Assistant pozwla ponadto ustawić dowolny kolor każdej z kilku taśm.

Moduły MCU wykorzystują mikrokontroler STM32F103. Korzystam z systemu ChibiOS a wszystkie kody do obsługi modułów zostały zebrane w małą biblioteczkę HomeCAN. Dzięki temu dodając kolejny moduł MCU do sieci wystarczy przygotować niewielką configurację żeby skonfigurować cały moduł:

static hc_node_t node = {
    //
    .can_drv                   = &ITHACA_HOME_CAN_DRIVER,
    //
    .env_sensors               = env_sensors,
    .env_sensors_poll_period   = 30,
    //
    .analog_inputs             = analog_inputs,
    .analog_inputs_poll_period = 30,
    //
    .sds011                    = &sds011,
    .sds011_measure_period     = 30,
    .sds011_poll_period        = 300,
};

A następnie na początku wywołać inicjalizację całej biblioteki podając tylko identyfikator z jakim będą wysyłane ramki CAN:

    // init HomeCan node
    hcInit(&node, HC_NID_LIVING_ROOM_WALL);

Jeśli do modułu MCU podpięty jest przycisk lub klawiatura (lub w przyszłości czujnik ruchu/gestów) dane o wciśniętych przyciskach będą wysyłane przez szynę CAN lub obsługiwane lokalnie (jeśli zostało to zdefiniowane w konfiguracji). Lokalna obsługa zdarzeń została dodana gdyż w pierwszej fazie testów często zdarzało się, że cześć sterująca (najczęściej RaspberryPi z bridgem CAN<->MQTT) z jakiegoś powodu była niedostępna i co za tym idzie ciężko wtedy sterować czymkolwiek. Pozostałe zdarzenia są odbierane przez Home Assistanta gdzie mogą być dowolnie przetwarzane (jako triggery do innych akcji, grupowe sterowanie światłami, itp.)

Obecnie testuję również czujnik wilgotności ziemi (do badania wilgotności w doniczkach) oraz mierniki energii PZEM-004T. Przygotowuję również kolejny moduł do umożliwiający płynne sterowanie żarówkami 230V (dimmer). W planach jest również dołożenie kolejnego czujnika pyłu, tym razem mierzącego pył na zewnątrz (obecnie mierzę powietrze w pokoju).

Wszystkie pomiary są zbierane przez Home Assistanta i zapisywane w InfluxDB. Dane można łatwo przejrzeć korzystając z Grafany.

ha.thumb.png.000bcdb0fd78e19beab1de365b211a4b.pnggrafana_charts.thumb.png.a9301993f614663152de15b0eee35539.pnggrafana_summary.thumb.png.bb8580577425b66c7e1760a8778834a0.png

Edytowano przez sadziu
  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites

Podoba Ci się ten projekt? Zostaw pozytywny komentarz i daj znać autorowi, że zbudował coś fajnego!

Masz uwagi? Napisz kulturalnie co warto zmienić. Doceń pracę autora nad konstrukcją oraz opisem.

@sadziu, witam na forum 😉 Widzę, że to Twoje pierwsze kroki na Forbocie, oto najważniejsze informacje na start:

  • Chcesz przywitać się z innymi członkami naszej społeczności? Skorzystaj z tematu powitania użytkowników.
  • Opis najciekawszych funkcji, które ułatwiają korzystanie z forum znajdziesz w temacie instrukcja korzystania z forum - co warto wiedzieć?
  • Poszczególne posty możesz oceniać (pozytywnie i negatywnie) za pomocą reakcji - ikona serca w prawym dolnym rogu każdej wiadomości.

Dnia 17.01.2019 o 21:59, sadziu napisał:

Chciałem opisać mój projekt automatyzacji, który zrealizowałem w mieszkaniu. Moje podejście jest zgoła inne od  wszechobecnego ESP8266 + WiFi. Całą sieć oparłem o magistralę CAN (tę stosowaną w samochodach). Wymaga to oczywiście trochę "przeróbek" w domu ale traktuję to niejako pole doświadczalne przed budową domu w przyszłości[...]

Właśnie zaakceptowałem opis. Dziękuję za przedstawienie ciekawego projektu, zachęcam do prezentowania kolejnych DIY oraz aktywności na naszym forum 😉

Udostępnij ten post


Link to post
Share on other sites

Ciekawe rozwiązanie, też stawiam dokładnie na takie połączenie CAN + HA. Mam rozprowadzone okablowanie więc jest baza, no i CAN pozwala uniknąć problemu 'single point of failure' gdzie pada nam RPI i nawet światła nie włączymy w łazience 😉 Możesz opisać trochę jak zorganizowałeś protokół komunikacyjny po CAN-ie? No i bajką by było jakbyś podzielił się skryptem CAN <->MQTT,  albo chociaż jego opisem 🙂

  • Lubię! 1

Udostępnij ten post


Link to post
Share on other sites
(edytowany)

Protokół po CAN mam po swojemu. Używam CAN EID do adresowania nodów, urządzeń w ramach jednego node-a, typu wiadomości i operacji:

* bity 0-7 -- device number (numer czujnika, etc)
* bity 8-17 -- adres node-a (0-1023)
* bity 18-20 -- typ operacji - coś w stylu get/set/query/etc
* bity 21-28 -- type wiadomości -- czujnik temperatury, wykrycie ruchu, etc.

Zostaje więc do 8 bajtów do przesłania danych (temperatura/kolor diody RGB, etc). Dlaczego tak? W CAN najwyższe id ramki ma najwyższy priorytet - więc w przypadku kolizji najpierw powinny być wysłane informacje o zdarzeniach typu wykrycie ruchu, etc. (nie spodziewam się tylu zdarzeń i tak krytycznych ale jakoś trzeba było to zorganizować).

Jestem w trakcie przepisywania mojego skrypciku can2mqtt.py na ładniejszą i bardziej uporządkowaną wersję. Umieściłem jego aktualną wersję (nie do końca gotową) na github-ie: https://github.com/sadziu82/can2mqtt.

Jeśli zaś chodzi o problem 'włączania światła w łazience' przy padzie RPi to u mnie działa to w ten sposób, że każdy node posiada swoje własne/lokalne zdarzenia. Więc jeśli nawet cała szyna CAN nie działa to każdy node zachowuje swoją podstawową funkcjonalność (typu włączenie/wyłączenie lokalnego światła po naciśnięciu przycisku) - informacje o zdarzeniach lokalnych są wysyłane do sieci CAN więc jeśli wszystko działa HA zauważy, że ktoś nacisnął przycisk i wlączyło się światło i uaktualni stan przełącznika.

Edytowano przez sadziu
  • Lubię! 2

Udostępnij ten post


Link to post
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Gość
Napisz odpowiedź...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.


×
×
  • Utwórz nowe...