Tata stwierdził, że woda deszczowa jest świetna do pralki, bo jest miękka, ale „nie ma jak tu podłączyć, bo pralka jest na górze”. Na początku zgodziłem się z jego stwierdzeniem, zwłaszcza że w grę wchodzi WAF, czyli Wife Approval Factor. Nie może po prostu puścić rury przez środek łazienki.

24 godziny później, przez przypadek, podczas opowiadania o oryginalnym zakresie projektu wymyśliłem, jak ten problem obejść:

• dajmy na strych zbiornik z wodą (30 litrów),
• pompujemy do niego wodę ze zbiornika na deszczówkę,
• do pralki spływa grawitacyjnie,
• przy pralce dajemy znowu zawór, żeby w razie braku deszczówki przełączało się na normalną wodę.

Patrząc na układ domu, da się to zrobić, zachowując 100% WAF: żadnych widocznych rur.

W tym momencie poziom skomplikowania projektu wzrósł o 400%, głównie ze względu na wymagane systemy bezpieczeństwa. Niewyłączona pompa to zalanie domu, zaczynając od strychu, bo zbiornik na strychu nie jest pod ciśnieniem i ma otwartą górę.

Krytyczne systemy bezpieczeństwa

Po długich debatach doszliśmy do wniosku: woda nie może się przelać. W zbiorniku na górze będą 2 takie same pływaki, określające stan “zbiornik pełny”. PLC będzie wymagało, aby stan pływaków zawsze się zgadzał. Niezgodność przez dłużej niż sekundę ma spowodować awaryjne wyłączenie pompy i zablokowanie jej do czasu ręcznego resetu.

Pływaki będą skonfigurowane w układzie NC (normally closed, czyli normalnie zamkniętym), co oznacza, że obwód jest zamknięty, gdy zbiornik nie jest pełny, i otwiera się, gdy jest pełny. Dzięki temu przerwanie kabla automatycznie sygnalizuje do PLC “zbiornik pełny”.

Dużo czujników

Przede wszystkim w zbiorniku wody deszczowej będzie znajdował się hydrostatyczny czujnik poziomu wody (mierzy ciśnienie słupa wody nad sobą i z niego wylicza poziom). Dzięki temu na wizualizacji (czytaj: w Home Assistancie, otwartym systemie do automatyki domowej) będzie wyświetlać się “obecny poziom: 800 litrów” i wykres z ostatniego miesiąca. Dodatkowo ten czujnik pozwala wykryć, kiedy woda się skończyła, aby nie załączać pompy na sucho.

W zbiorniku na górze, oprócz wspomnianych wcześniej 2 redundantnych pływaków, będzie znajdował się czujnik poziomu niskiego (sygnalizujący “załącz pompę, jeżeli jest woda”) oraz czujnik poziomu krytycznego (“brakuje wody w zbiorniku, przełącz pralkę na kranową”).

Dodatkowo przed pralką będzie kolejny przepływomierz, w celu wyświetlania “tyle wody zaoszczędziliśmy. Przepływomierz przed toaletą, oprócz wykrywania “spłuczka zamknęła zawór, wyłącz pompę”, ma również za zadanie liczyć, ile wody się przelało.

Pompa pomidorowa

Wspominałem już, że tata podlewa pomidorki. I inne warzywa. W zbiorniku znajduje się kolejna pompa, która ma za zadanie wypchać wodę na balkon, do konewki.

Obecnie ta pompa jest sterowana przez ESP32 z ESPHome (oprogramowaniem, które z mikrokontrolera robi gotowe urządzenie dla Home Assistanta) i przez samego Home Assistanta. Docelowo będzie sterowana przez PLC. Tutaj działanie jest proste: wciśnięcie przycisku przełącza stan pompy, a dodatkowo po 15 minutach pompa jest wyłączana automatycznie, gdyby tata się rozproszył i zapomniał. 15 minut dlatego, że czasami zamiast lać do konewki, do pompy podpięty jest wąż ogrodowy.

Nie wiem, czy będę o tym wspominać więcej, bo to w sumie nie jest nic odkrywczego ani skomplikowanego, ale jeżeli tak, będzie to określane jako pompa pomidorowa. Mimo tego, że nie pompuje pomidorów.

Wizualizacja i integracja z Home Assistantem

Cały system ma być kompletnie stand-alone: ma działać bez sieci, bez Home Assistanta, bez serwera, ma wystarczyć tylko prąd do zasilania pomp i PLC.

Wykorzystując jednak fakt, że LOGO! 9 ma wbudowany Ethernet i obsługę MQTT (lekkiego protokołu do przesyłania wiadomości między urządzeniami), aż głupio z tej opcji nie skorzystać. O samym MQTT pisałem więcej we wpisie o aktualizacjach OTA.

Po MQTT będzie przesyłana wartość czujnika w zbiorniku, jako zwykły sensor, oraz liczniki, które PLC będzie resetować codziennie:

• woda zużyta przez pralkę,
• woda zużyta do toalety,
• ilość cykli (uruchomień) pompy na strych,
• ilość cykli (uruchomień) pompy do toalety.

Dodatkowo node-red (narzędzie do łączenia takich danych w proste przepływy, bez pisania kodu) będzie użyty do zliczenia łącznych wartości tych liczników.

LOGO! samo nie może prowadzić tych liczników bez resetu, bo:

licznik wody zużytej przepełni się po około 2000 do 3000 litrów, w zależności od czujnika. Licznik w sterowniku ma maksymalną wartość 999999, a czujnik daje około 450 impulsów na litr,
programowanie LOGO! resetuje liczniki, nawet jeżeli są ustawione jako retentive (mają przetrwać zanik zasilania).
Jako że LOGO! 9 ma wbudowany wyświetlacz, te informacje również będą na nim prezentowane, obok przycisku „tryb konserwacji, przełącz wszystkie zawory na wodę kranową”.

Pora wziąć się do pracy

Po kupieniu wszystkiego (plot twist: okazało się, że to nie było wszystko), razem z tatą zaczęliśmy wszystko zakładać. Przede wszystkim trzeba było przeciągnąć kabel sterowniczy, kabel do siłownika zaworu (silniczka, który obraca zawór) i węża z kotłowni na strych.

Drugi koniec węża z kotłowni wychodzi na zewnątrz pod zadaszenie, korzystając z dziury, która była dawno temu potrzebna do starego pieca gazowego. Tam będzie podpięty do filtra, podpiętego do pompy.

Będąc w kotłowni, zacząłem podpinać kolejne elementy do LOGO. Obecnie podpięty jest czujnik poziomu wody w zbiorniku, w teorii skalibrowany, w praktyce jeszcze nie wiem, na ile dokładnie. Oprócz tego podpięty jest pływak w spłuczce do wykrywania jej użycia. I czujnik przepływu do toalety, chociaż podpięty jest tylko elektrycznie, nie hydraulicznie. W sumie w tym momencie wszystko jest podpięte tylko elektrycznie.

Dotarłem jeszcze do jednego pomysłu: przeniesienie zbiornika ze strychu do łazienki, do szafki nad pralką (gdzie obecnie są ręczniki), znacznie zminimalizuje konsekwencje potencjalnego wycieku. Z tego powodu ta opcja została wybrana.

Powoli też dodaję czujniki do Home Assistanta, w miarę jak są podłączane. Obecnie mam przede wszystkim czujnik poziomu wody w zbiorniku. Na szczęście da się te dane odczytywać prosto przez MQTT, bez wykorzystania node-red jako pośrednika do zmiany formatu wiadomości.

Po założeniu w łazience zbiornika nadszedł czas na podpięcie wszystkich 5 sygnałów z łazienki do LOGO!. Są to:

• czujnik przepływu,
• czujnik pełnego zbiornika A,
• czujnik pełnego zbiornika B,
• czujnik niskiego poziomu (ten czujnik próbuje włączyć pompę),
• czujnik krytycznego poziomu (ten czujnik przełącza na wodę kranową).

Niezgodność czujników pełnego zbiornika przez dłużej niż sekundę powoduje błąd, który wyłącza pompę do czasu ręcznego wyczyszczenia błędu, po weryfikacji, że czujniki działają prawidłowo. Czujniki te podpięte są w taki sposób, że przerwanie kabla wskazuje na stan „zbiornik pełny”, doprowadzając do wyłączenia pompy.

Nadszedł czas na podpięcie węża do zbiornika. Tutaj nie pomyślałem i nie kupiłem zbiornika od razu z kranikiem na wąż ogrodowy, zamiast tego mam zbiornik z kranikiem, z którego można nalewać prosto do szklanki. Wąż 1/2 cala jest za mały na wyjście kranika, wąż 3/4 za duży. Musiałem więc wydrukować podkładkę z TPU (elastycznego materiału do druku 3D) i zamontować węża w ten sposób:

Jako że wąż się bardzo zagina, postanowiłem użyć tutaj przejściówki z węża 3/4 na 1/2 i dalej prowadzić wodę wężem 1/2, który jest dużo wygodniejszy.

Przy okazji postanowiłem liczyć szacowany poziom wody w tym zbiorniku. Wyliczyłem, że używalna objętość to 20 litrów, pomiędzy pływakami wskazującymi pełny zbiornik a czujnikiem poziomu krytycznego.

W LOGO! dodałem licznik z wartością początkową 6000 (20 litrów razy 300 impulsów na litr), liczący w dół, a zaraz za nim blok obliczeń zmiennoprzecinkowych (float computation instruction), liczący wartość licznika podzieloną przez 300, co daje bardzo szacowaną ilość używalnych litrów w zbiorniku. Licznik jest resetowany sygnałem z pływaków określających pełny poziom zbiornika.

W tym momencie uświadomiłem sobie jedną ważną rzecz: w sumie to ciśnienie do pralki będzie zbyt niskie. Pralka wymaga minimum 0,5 bara, co przekłada się na to, że zbiornik musi być 5 metrów wyżej od pralki. A jest może metr nad pralką.

Kilka opcji, które widzę w tym momencie:

• spróbować, może zadziała,
• dać za pralką małą pompę do kampera, która będzie utrzymywała ciśnienie.

Oczywiście z tatą zdecydowaliśmy się najpierw na pierwszą opcję.

I w końcu przyszły też elektrozawory (zawory otwierane elektrycznie, prosto z wyjścia sterownika), co umożliwia podpięcie toalety i pralki. Miały przyjść w sobotę, ale jako że sprzedający bardzo spokojnie je wysyłał, przyszły w poniedziałek.

Sukces! Ale nie do końca

W piękny poniedziałkowy wieczór wspólnymi siłami poskładaliśmy wszystkie elementy tej układanki. Może zacznijmy od tego, co poszło dobrze:

• czujniki przepływu działają,
• woda nalewa się do zbiornika nad pralką perfekcyjnie,
• woda nalewa się do spłuczki poprawnie,
• dużo się nauczyłem w zakresie programowania PLC.

Teraz czas na rzeczy, które nie poszły najlepiej.

Po pierwsze, nie wiem dlaczego, zgaduję, że przez nieszczelny zawór, woda cofała się z kranu przez zawór za pralką do zbiornika. Spowodowało to przepełnienie zbiornika i małe zalanie łazienki. Na szczęście zbiornik jest w szafce z ręcznikami, które większość wody wchłonęły. Póki co wszystko działa z zakręconą wodą kranową i, jak to mówią mechanicy, trzeba „jeździć, obserwować”.

Mówiąc o obserwowaniu, łatwo było zauważyć na pralce błąd E02, który w wypadku tej pralki oznacza mniej więcej „za mało wody”. Woda do pralki wlewa się, choć to prawda, że trochę wolno. Ciśnienie ze zbiornika jest dużo mniejsze, niż powinno być według instrukcji, i o ile pralka nie wyświetli tego błędu na początku programu, to wszystko wypierze.

W międzyczasie jeszcze trzeba było zmienić logikę sterowania, która na papierze wydawała się dobra, w praktyce jednak jest inaczej:

• mój świetny pomysł „czujniki muszą się zgadzać co najwyżej po sekundzie” w połączeniu z „aktywacja jednego czujnika wyłącza pompę” nie miał prawa się udać. Czujniki są na trochę różnych poziomach (próbowałem je ustawić na tym samym, ale jednak tak nie jest), przez co wyłączenie pompy po wykryciu pełnego zbiornika przez jeden czujnik powodowało, że jeden był aktywny, a drugi nie,
• pompa do toalety załączana była przez pływak, a wyłączana przez brak przepływu. Ustawione przeze mnie progi (załączenie powyżej 2 l/min, wyłączenie poniżej 1 l/min) są w porządku, ale z jakiegoś powodu spłuczka sama nie zamyka swojego zaworu i woda dalej płynie. Dorobiłem więc wyłączanie pompy przez pływak lub przez brak przepływu, zależnie od tego, co będzie pierwsze. Czujnik przepływu pokazuje 3 l/min, co jest dla mnie zadowalającym wynikiem.

Więc, aby rozwiązać problem ze zbyt małym przepływem do pralki, kupujemy tanią pompę, taką samą jak do toalety, i próbujemy z nią. I przy okazji zawór zwrotny (przepuszcza wodę tylko w jedną stronę), żeby woda nie cofała się do zbiornika i nie zalewała łazienki. I zasilacz do tej pompy. Teraz muszę jechać jeszcze kupić 15 metrów kabla do zasilania tej pompy. I wykorzystamy ostatnie wolne wyjście w PLC.

Co do detekcji, kiedy trzeba włączyć pompę, wspominałem wcześniej, że widzę 2 opcje. Jedna to włączać pompę, kiedy czujnik przepływu wykryje przepływ, druga to podpiąć się pod sygnały elektrozaworów w pralce i tak włączać pompę. Ku mojemu niezadowoleniu okazuje się, że zawory są na 230 V AC, a w dodatku są dwa.

Postanowiłem więc zbudować podwójny układ detekcji AC z wyjściem DC. Nie zależy nam, żeby wiedzieć, który zawór się otworzył, jedyne, co ma tutaj znaczenie, to to, że któryś się otworzył.

Układ składa się z dwóch bardzo podobnych części. Obie działają na tej samej zasadzie: prąd idący do zaworów idzie też do układu, ładując kondensator i zasilając optoizolator (element, który przenosi sygnał światłem, bez połączenia elektrycznego między obiema stronami, więc napięcie z pralki nie ma jak trafić do sterownika). Optoizolator w konfiguracji emitter follower podaje sygnał do PLC.

Zbudowałem więc ten układ i wygląda to tak:

Po położeniu grubej warstwy lakieru izolacyjnego, czekając, aż wyschnie, włączyłem OpenSCAD (program do modelowania 3D, w którym bryłę opisuje się kodem) i zaprojektowałem obudowę:

Zrobiłem zdecydowanie grubsze ściany, niż było to konieczne. Ostatecznie wydruk trwał półtorej godziny i zużył 71 gramów PETG. Biorąc pod uwagę, że jest to najtańszy PETG, jaki jestem w stanie kupić, po około 25 zł za kilogram, daje to niecałe 2 zł w kosztach materiału.

Po założeniu do pralki i podpięciu do PLC nadszedł czas na test. Zaprogramowałem PLC, aby załączał wyjście Q2, jeżeli wejście I2 jest aktywne oraz pralka jest przełączona na wodę deszczową. Dodatkowo jest opóźnienie wyłączenia na 5 sekund, bo pralka często dolewa po trochu, a szkoda przełączać pompę co chwilę.

Na tym etapie nie mam jeszcze pompy ani nawet przeciągniętego kabla do jej zasilania, więc test polega na:

• uruchomieniu pralki,
• obserwacji, czy wyjście ma prawidłowy status.

Jak się okazuje, w teorii wszystko działa poprawnie. Pozostaje więc czekać na pompę.

Ostatnia prosta

Po zamontowaniu pompy i zaworu zwrotnego, żeby zbiornik nad pralką przestał się napełniać wodą kranową, przyszedł czas na ostatni test. Pranie.

Włączyliśmy pralkę i z niecierpliwością patrzyliśmy na wizualizację, aż coś zacznie się dziać. I w końcu się zadziało: woda płynęła do pralki z przepływem 5 litrów na minutę, co jest znaczną poprawą wobec poprzednich 1,2 l/min.

W tym momencie prace ze sprzętem można było uznać za zakończone. Pozostało jedynie dopracować dashboard w Home Assistancie.

Na przyszłość

Rzeczy, które przychodzą mi do głowy, to:

• przewidywanie poziomu wody w zbiorniku na podstawie historycznego zużycia, obecnego poziomu i prognozy pogody, wyliczanie czasu do opróżnienia. To jednak musi poczekać, aż zbierze się trochę więcej danych historycznych, minimum 2 tygodnie, żeby miało sens,
• powiadomienie „dobry moment na pranie”, gdy przewidywane opady na następny dzień spowodują przepełnienie zbiornika.

Zmiana zakresu

Tata stwierdził jeszcze, że fajnie byłoby podpiąć do systemu toaletę w łazience. W tym rozdziale, pisząc o toalecie, mam na myśli inną toaletę niż wcześniej.

Tutaj znalazłem opcje na optymalizację kosztów i przy okazji wciśnięcie protokołu Modbus do systemu.

Toaleta w łazience będzie podpięta przez rozdzielacz do tej samej pompy, do której jest podpięta pralka. Zawór dostarczający wodę kranową do spłuczki będzie bardzo przykręcony, tak aby woda nalewała się powoli, około 10 minut na pełny zbiornik. Dodatkowo do spłuczki dajemy pływak i węża, którym pompa będzie pompować wodę.

Po drodze musi stać jeszcze tylko elektrozawór (tym razem nie z siłownikiem, tylko z elektromagnesem), żeby woda do toalety nie lała się, kiedy pralka chce włączyć pompę.

Jako że kable do sterowania takim systemem kosztowałyby około 190 zł, gdybym miał ciągnąć je z kotłowni, zdecydowałem się tutaj zrobić to inaczej. Raspberry Pi Pico z modułem Ethernet W5500 będzie odpowiadało za sterowanie toaletą, czyli w tym wypadku za zliczanie przepływu przez czujnik przepływu, otwieranie elektrozaworu i odczytywanie stanu pływaka.

Raspberry Pi nie będzie podejmować żadnych decyzji logicznych, sterowanie będzie przychodzić z PLC w kotłowni, przez Modbus TCP (przemysłowy protokół, w którym jedno urządzenie odpytuje drugie o konkretne komórki pamięci).

Ostatecznie po Modbus wystawione jest:

• Coil 1: zawór,
• Coil 2: reset statystyk,
• Discrete Input 1: pływak,
• Input Register 1-2: ilość wody, która przepłynęła przez czujnik,
• Input Register 3-4: obecny przepływ (l/min).

W nazewnictwie Modbus coil to pojedynczy bit, który da się zapisać, discrete input to bit tylko do odczytu, a input register to rejestr z wartością liczbową.

Rejestry w Modbus są zawsze 16-bitowe, a float zajmuje 32 bity, dlatego na jedną wartość muszę wykorzystywać 2 rejestry. Kolejność rejestrów jest dokładnie taka sama, jakiej oczekuje LOGO! 9.

Dodatkowo cały ten sterownik jest zasilany przez POE (power over Ethernet, czyli zasilanie tym samym kablem, którym idzie sieć), bo nie chciało mi się ciągnąć dodatkowego kabla zasilającego, bo mam switcha POE i akurat miałem zapas splitterów POE.

W obecnej konfiguracji, po spłukaniu wody, PLC odczytuje, że pływak spadł, i o ile ma wodę w zbiorniku w łazience, włącza pompę i otwiera zawór. Pompa nalewa wodę szybciej, niż zawór wody kranowej nalewa wodę kranową. Jeżeli w tym samym czasie pralka otworzy swój zawór, pralka ma priorytet i zawór do toalety zostanie zamknięty.

Swoją drogą, uznałem, że sterowanie wodą do toalety w taki sposób jest lepsze niż użycie trójdrożnego zaworu kulowego do wyboru źródła, jak zrobiłem to wcześniej.

Czego ten projekt na sterowniku PLC nauczył mnie o sieciach OT

Zbiornik na deszczówkę to nie jest linia produkcyjna i nie będę udawał, że jest. Ale kilka rzeczy wygląda tak samo, niezależnie od skali.

Logika bezpieczeństwa siedzi w sterowniku, nie w sieci. Dwa pływaki, które muszą się zgadzać, i przerwany kabel oznaczający „zbiornik pełny” to decyzje podjęte na poziomie PLC i to one zadziałają wtedy, kiedy padnie wszystko inne. Patrząc od strony IT, łatwo o tym zapomnieć i widzieć w urządzeniu OT kolejny host w sieci.

To, co w IT nazywamy awarią, w OT ma konsekwencje fizyczne. U mnie najgorszym scenariuszem była mokra łazienka i, jak się okazało, scenariusz się zrealizował. W zakładzie produkcyjnym po drugiej stronie tej samej logiki stoi prasa albo zawór pary.

Te urządzenia mówią protokołami, które powstały, zanim ktokolwiek myślał o uwierzytelnianiu. Modbus TCP nie ma go wcale. Kto ma dostęp do sieci, ten ma dostęp do rejestrów i może zapisać, co chce. Dlatego przy sieciach OT tak uparcie wracamy do segmentacji sieci: to jedyna warstwa, na której da się to realnie ograniczyć. Nie zaktualizujesz firmware’u sterownika, który stoi w linii od dwunastu lat, ale możesz zdecydować, kto się z nim połączy.

Dokumentacja powstaje w trakcie albo nie powstaje wcale. Po kilku miesiącach sam musiałem sprawdzać, które wejście jest od którego pływaka. W systemie, który zbudowałem własnymi rękami.

Jeżeli masz u siebie sieć OT i zastanawiasz się, jak oddzielić ją od reszty infrastruktury, to rozmowa, którą prowadzimy z klientami regularnie. Zajmujemy się tym w ramach zabezpieczeń sieciowych, a pierwsza konsultacja z inżynierem jest bezpłatna: devology.pl/kontakt.