Sterownik do pieca C.O.

Witam!

Pragnę dziś przedstawić swój pierwszy projekt na Arduino, a mianowicie sterownik pieca C.O. Tak na prawdę jest to sterownik pompek C.O. i pieca niejako przy okazji, ale kto by się takimi szczegółami przejmował :)

Po co to komu?

Tobie? Nie mam pojęcia, ale liczę, że uda mi się zainspirować Cię do popełnienia jeszcze ciekawszego projektu (i oczywiście podzielenia się dalej). Mi projekt jest potrzebny do sterowania ogrzewaniem w domu. Dlaczego?

Otóż mieszkam w piętrowym domu z piwnicą. Parter i piętro to osobne mieszkania, połączone klatką schodową, która nie jest częścią żadnego z nich. Obie kondygnacje obsługuje wspólny piec gazowy, który (sam w sobie) posiada dwa oddzielne obiegi: CO (centralnego ogrzewania) oraz CWU (Ciepłej Wody Użytkowej – znaczy, bojler). Dla każdego obiegu jest osobne wyjście sterujące – pompa obiegu CO oraz pompa obiegu CWU. Piec posiada także wejścia: termostat do regulacji temperatury CO oraz wejście analogowe temperatury wody w bojlerze (termistor). Żeby nie było za prosto, piec ma tylko jedno wejście do sterowania obiegiem CO. Jeśli chodzi o CWU, to oprócz bojlera grzanego gazem, posiadam drugi bojler podłączony do instalacji solarnej (wot, dotacje unijne :>). Logicznym było podłączenie tych bojlerów kaskadowo: zimna woda z rurociągu wpływa najpierw do zbiornika solarnego, gdzie jest podgrzewana albo i nie (np w nocy lub zimą), a następnie MUSI przepłynąć do zbiornika podłączonego do pieca gazowego, który jest podgrzewany (lub nie) w zależności od pory dnia i oczywiście temperatury. Stamtąd woda bez przeszkód dociera do kranów, lub wraca do zbiornika solarnego w celu mieszania (obieg wtórny z oddzielną pompką).

Taki układ został spowodowany wieloma czynnikami: oszczędnością, rozłożeniem w czasie, dostępnymi funduszami… Kto nie jest milionerem i sam grzebie w swoim domu, ten wie jak to jest :)

Generalnie działanie było OK, jednak posiadało dwa istotne mankamenty:

1. Piec ma tylko jedno wejście sterujące obiegiem CO, co oznacza, że wysterować mogę jedynie grzanie na piętrze lub parterze – tam, gdzie jest czujnik temperatury. Można oczywiście włączać pompkę obiegu na piętrze na którym nie ma czujnika, ale jeśli piec w tym czasie nie będzie grzał, to dana kondygnacja będzie się tylko chłodzić.
2. Czasami (latem) słońce nagrzewało 150-cio litrowy zbiornik solarny do temperatury ~95°C, gdy w tym samym czasie 150L w zbiorniku gazowym było zimne. Pomagało włączenie pompki obiegowej między zbiornikami np. przed wyjściem do pracy, i wyłączenie po przyjściu, ale jest to niewygodne (trzeba pamiętać żeby zejść specjalnie do piwnicy), energii (pompka wymiesza wodę szybciej niż wrócę z pracy (8h+), a do tego nie jest idealne – jak się zachmurzy albo będzie po prostu zimno to mieszanie nie jest potrzebne.

Co z tych rzeczy udało się zrealizować? W wersji testowej na moim biurku – wszystko :) Niestety działanie “produkcyjne” nie jest takie łatwe (o tym później), ale już od tygodnia działa oddzielne grzanie w zależności od temperatury/godziny/dnia tygodnia na obu poziomach. Pozostało mieszanie CWU, do którego brakuje mi uruchomienie jednego czujnika. W jaki sposób tego dopiąłem? Czytaj dalej…

Logika (czyli jak to działa)

Cała logika sterownika jest prosta:

1. Jeżeli temperatura wody w zbiorniku solarnym jest wyższa o 5 stopni od temperatury w zbiorniku gazowym, uruchom mieszanie na 30min.
2. Jeżeli temperatura na dowolnej kondygnacji jest poniżej zadanej dla aktualnej pory dnia minus histereza, uruchom pompkę CO dla danej kondygnacji i daj sygnał do włączenia pieca aż do momentu osiągnięcia docelowej temperatury plus histereza.
3. Wyświetl temperaturę czujników, stan przekaźników i aktualny czas na ekranie.

Banalne, nie? :D No to budujemy!

Sprzęt (to, co tygryski lubią najbardziej)

Co wykorzystałem w swoim projekcie:

1. Arduino ProMini 16MHz 5V
2. Moduł RTC – DS1307, interfejs I2C
3. Moduł przekaźników na I2C
4. Wyświetlacz LCD 4×16
5. Rezystory (220 Ω, 4.7 kΩ)
6. Puszki plastikowe, kawałek płytki miedzianej do wytrawienia, kabelki, inne pierdoły widoczne na zdjęciach.

Schemat oraz kod całego bałaganu do ściągnięcia TUTAJ: git, podgląd “na szybko” załączam poniżej. Brakuje na nim trzech rzeczy: czujników temperatury (na PCB jest opisane wyjście OneWire, myślę że nie ma potrzeby dorysowywania samego czujnika), RelayShielda (nie ma go we fritzingu, a jest podłączony dokładnie tak samo jak moduł zegara) oraz wyjść do programowania (mam zmontowaną własnoręcznie przejściówkę z RS232 na FTDI)

Najpierw podłączenia na breadboardzie, kompletnie poglądowo:

Następnie logika (chyba wystarczająco czytelnie):

I na końcu schemat PCB – był tak naprawdę tylko punktem odniesienia do wytrawienia płytki

Tutaj w sumie szału nie ma: będąc wygodnym wykorzystuję jak się da magistrale (OneWire i I2C), co pozwala mi zaoszczędzić piny niezbędne do obsługi wyświetlacza. obie magistrale są na tej płytce jedynie wyprowadzeniami, moduły są podłączane kabelkami – łatwiej potem zmieścić to wszystko w puszkę. Dodatkowo do RealyShielda dopięte zostaną kable zasilające pompki, ale to już jest poza schematem samego Arduino, i myślę że każdy wie jak podłączyć gotowy przekaźnik (konkretne opisy wejść i wyjść znajdą się pewnie przy programowaniu)

Programowanie (komplikowanie życia)

Okej, podłączenie już za nami – nie było tak strasznie, nie? To przechodzimy do zagwozdek logicznych. Kod udostępniam dla potomnych TUTAJ, a poniżej listing całego programu:

Jak widać samego kodu jest dość sporo, i nie zawsze dobrze opisany, dlatego pozwolę sobie skomentować program metoda po metodzie.

Na samym początku oczywiście definicja wyświetlacza (jego pinów i geometrii). Ponieważ za namową kolegi dokupiłem kilka dni temu moduł ethernet, prawdopodobnie cała obsługa wyświetlacza zostanie wyeksportowana do I2C (przejściówka ma do mnie dotrzeć lada dzień) – potrzebuję pinów 11, 12 i 13 do SPI.

Następnie definicja adresu RelayShielda, dwie tablice: stanu aktualnego oraz docelowego przekaźników oraz trzy funkcje do zmiany stanu. Adres wpisany na sztywno, ustalony za pomocą pinów na shieldzie. Tablic użyłem aby nie przełączać za każdym razem przekaźników – funkcje przełączania wywoływane są tylko wtedy, kiedy jest to potrzebne (uznałem że bardziej zależy mi na tym, żeby przekaźniki nie cykały bez potrzeby). Osiągnąłem po poprzez przechowywanie aktualnego stanu przekaźników w tablicy RelaySet, a stanu docelowego w tablicy RelayChan. Synchronizacja następuje poprzez wywołanie funkcji SetRelay, która sprawdza w prostej pętli, czy odpowiednie wartości w  tablicach są zgodne. Jeśli tak, to znaczy że nie trzeba zmieniać stanu przekaźnika, a jeśli się różnią, to w zależności od stanu docelowego włączamy/wyłączamy przekaźnik i za jednym zamachem wpisujemy aktualny stan zarówno do tablicy docelowej jak i na LCD.

Kolejny blok to obsługa czujników temperatury. Co prawda definicja adresów jest kompletnie książkowa, natomiast już samo wskazanie temperatury (wynik) przechowywane jest w tablicy – wszystko ze względu na łatwość przyporządkowania indeksów – temperatura z indeksu 0 to temperatura, za która odpowiedzialny jest przekaźnik 0, i analogicznie dla przekaźnika 1. To na co pragnę zwrócić uwagę to kompletna definicja funkcji odczytującej temperaturę – zapewne co bardziej spostrzegawczy zauważyli brak biblioteki DallasTemperature. Nie jest mi ona do niczego potrzebna, całość bezpośredniej obsługi czujników posiada jedna jedyna funkcja getTemp, a jej ręczna definicja pozwala mi od razu wpisywać temperaturę do tablicy, oraz – co ważniejsze – łatwą i szybką zmianę czasu oczekiwania na odczyt temperatury – domyślnie funkcja ta czeka aż 750ms, co bez problemu zbiłem do 100ms… Co prawda czasami odczyt jest błędny, ale z drugiej strony łatwiej jest eksperymentować z czasem w samym programie, a nie edytować bibliotekę. Oprócz tego funkcja aktualizująca stan temperatur, osobna do wyświetlania ich na ekranie (może je połączę w jedno jak przepnę wyświetlacz). Ostatnią funkcją w tym bloku jest ta służąca do ustawiania stanu pożądanego przekaźników w zależności od wskazań temperatury. Mam nadzieję że dobrze widać dlaczego przydatne jest posiadanie analogicznych indeksów – przekazuję tylko jeden indeks, a cała magia się dzieje sama :)

Dalej następują tablice grzewcze. Jest to chyba najbardziej trudny do zrozumienia kawałek kodu – trzy gigantyczne tablice wypełnione zerami i jedynkami. Biorą się one z mojej chęci prostego wizualnie zarządzania temperaturą docelową w danej kondygnacji i usunięci zbędnych IFów. Jedynki (wartości true) reprezentują przedział czasu, w którym piec ma grzać do wyższej temperatury, np. kiedy więcej osób przebywa w domu, albo jest wieczór i już nie robi się niczego rozgrzewającego, tylko siedzi i czyta majsterkowo.pl :). Zera z kolei reprezentują stan tzw. przeciwzamrożeniowy – kiedy wyższa temperatura nie jest potrzebna bo albo nikogo nie ma w domu, albo i tak zasuwa się z odkurzaczem z góry na dół :). Na parterze jest tylko jedno ustawienie – każdy dzień wygląda dokładnie tak samo, ponieważ nikt tam chwilowo nie mieszka, a mimo to od czasu do czasu się schodzi, to piec powinien grzać tam tylko wtedy, gdy domownicy tam przebywają – zazwyczaj rano przed wyjściem do pracy i wieczorem przed snem. Postanowiłem, że piętnastominutowe przedziały będą wystarczające do wysterowania takiego działania, stąd cztery kolumny dla każdego z dwudziestu czterech wierszy odpowiadających kolejnym godzinom. Tu również opłaca się sprytne wykorzystywanie indeksów, bo godzinę mam “gratis”, bez zbędnego IFowania :). W przyszłości, jeśli przyjdzie mi na to ochota, mogę łatwo zwiększyć rozdzielczość minutową poprzez dodawanie kolejnych kolumn (rozważałem kroki co 10 lub 5 minut, ale odpuściłem ze względu na ograniczoną ilość pamięci). Również, gdyby bardziej rozbudować ilość tablic w “trzeci wymiar”, można by używać tego indeksu do automatycznego wyboru dnia, bez dodatkowego sprawdzenia tego IFem, jednakże przy aktualnym stopniu złożoności nie jest to możliwe.

W tym miejscu można też pokusić się o zamianę tablicy z bool na float i bezpośrednie wpisywanie temperatur, jednak znów bałem się o rozmiar potrzebnej pamięci, a dwa stany jak dla mnie są póki co zupełnie wystarczające. Ostatnio doczytałem też o dyrektywie PROGMEM, którą postaram się wykorzystać w następnej rewizji.

Dalej następuje definicja timerów do przerwań. Ponieważ na ArduinoProMini mogę z marszu wykorzystać timer1 oraz timer2, z czego jeden generuje przerwanie max co 4 sek a drugi co 16ms, musiałem troszkę nakombinować. Pierwszy if w przerwaniu timera1 pozwala mi odliczać ~30min o ile mam włączoną pompkę mieszającą wodę w zbiornikach CWU. Tutaj akurat postarałem się o dobre komentarze, mam nadzieję że ze zrozumieniem nie będzie problemu. W ten oto sposób dotychczasowy mankament nr 3 mam z głowy. Timer2 służy natomiast do synchronizacji przekaźników (jak podłączę ekran na i2c/spi to postaram się tu wcisnąć też jego odświeżanie). Chciałem zwrócić uwagę na linijkę

czyli jeśli działa pompka CO na piętrze lub parterze, następuje włączenie pieca (przekaźnikiem 2). W ten prosty sposób załatwiam dotychczasowy mankament nr 1.

W setupie włączam obsługę watchdoga (czytałem gdzieś że arduino może się wiechnąć po ~49 dniach ze względu na przepełnienie funkcji milis(), a nie chciałbym się obudzić któregoś dnia w zimnym domu :). Watchdoga ustalam na 8sekund (po tym czasie powinien restartnąć arduino), bo nie chciałem za często go resetować, a z kolei jak sterownik wiechnie się na 8sek to też nic wielkiego się nie stanie – grunt żeby się zrestartował). Od razu resetuję też rzeczonego watchdoga, tak na wszelki wypadek. Następnie ustawiamy dostawcę zegara, wyłączamy przekaźniki (póki co mają być w stanie deklarowanym na saaamym początku programu, a więc 0), odpalamy LCD, czyścimy, ładnie się witamy (a co!), ustalamy timery 1 oraz 2 na jak największe wartości, aż wreszcie czyścimy ekran (starczy tego przywitania) i odpalamy przerwania.

Pętla loop nie jest zbytnio zamotana, najpierw (przede wszystkim) następuje reset watchdoga. Następnie pobieramy temperatury z czujników (przejrzyście, bo w funkcji jest syf), wyświetlamy czas i temperaturę z czujników. I oczywiście sprawdzamy czy trzebaby grzać czy nie – zauważcie jak dzięki logicznemu wykorzystaniu adresowania tablic omijam dwa IFy – ten od sprawdzenia godziny oraz minut. Niestety nie mogę ominąć IFowania dnia – póki co wystarcza mi rozdzielenie grzania na weekend/dni robocze, dlatego też pisałem wcześniej o małej złożoności programu. Tym niemniej takie rozwiązanie jest IMO o niebo lepsze od ciągnących się w nieskończoność i zagnieżdżonych switch…case, że o nieszczęsnych ifach nie wspomnę. Na sam koniec ustawiamy przekaźniki (synchronizujemy je zgodnie z tablicą RelayChan i grzecznie czekamy 200ms przed następnym obrotem :)

Lutowanie i montaż (jeszcze więcej komplikowania)

No to jak wszystko już było gotowe, nadszedł czas żeby to zmontować. Z góry muszę przeprosić za kiepską jakość zdjęcia, ale podczas składania nie miałem jeszcze porządnego aparatu, a i tak wydawało mi się że robię je zupełnie niepotrzebnie.

Cóż tu widać? Gotową, wytrawioną płytkę z zapiętym do niej ArduinoProMini oraz LCD, RelayShield (po prawej), przejściówkę RS-232 do FTDI (za Mega, z dopiętym szarym kabelkiem), Arduino Mega (używałem do zasilania czujników, nie chciało mi się chwilowo wyprowadzać napięcia z samego ProMini), Zegar się schował za płytką, ale widać kawałek tasiemki do niego idącej. W głębi trafo z gołymi zaciskami na 230V (nie róbcie tak:>) i troszkę bliżej zasilacz 5V. No i na pierwszym planie BreadBoard z powtykanymi czujnikami temperatury (z lewej) i zbędnymi kabelkami po prawej.

Płytka -podstawka, po lewej miejsce na arduino, po prawej LCD

To samo od spodu, zauważcie rezystor 4.7K jest zlutowany równolegle to tego z wierzchniej strony, później wyjaśnię czemu.

A tutaj znów wierzch z włożonym już ProMini. wtyczka z białym i zielonym kabelkiem to wyprowadzenie I2C(TWI) na płytkę – nie za bardzo było jak to zmieścić normalną drogą, stąd taki potworek)

Kiedy stwierdziłem że czas odpalić cały ten majdan, zaczęło się przenoszenie do puszek:

Tutaj widać front-panel z zegarem (górny lewy róg) podstawką z LCD (to duże w środku) i wyjściem do programowania (dolny prawy). wszystko porządnie przyśrubowane (żadnego kleju!), co ciekawe do frontu przymocowany jest ekran LCD, a podstawka z arduino trzyma się na samych goldpinach – wchodzi bardzo ciasno, więc nie ma obaw przed poruszeniem.

Tutaj mamy zbliżenie na LCD z wyciągniętą podstawką (w tle) i moduł zegara.

Pełny przegląd całego bałaganu – przez puszkę z lewej przechodzą wszystkie kable od pieca do pompek, czujników, zasilania, stąd też spory natłok okablowania. Wprawne oko zauważy też radiatory zasilacza (miałem tam doprowadzone 12V DC, wystarczyło tylko dopiąć zasilacz bez trafo i voila). Przed samym założeniem wygląda to jak wyżej. Żółty kabelek to szyna danych 1-wire, czarne kabelki GND, spleciony czerwono-czarny to i2c do RelayShielda (zresztą widać jak się łączy z płytką przy lewym brzegu zdjęcia), para pomarańczowy-czerwony to +5V, a na samym dole mamy tasiemkę do zegara. Zdjęcie zostało wykonane wcześniej, stąd kabelki do FTDI mają jeszcze “kostkę”.

A tutaj z kolei cały ten bałagan w pełnej okazałości – zasilacz po lewej podaje dodatkowe 12V (do czego innego).

Cały sterownik w jednym ujęciu (widać błędy na wyświetlaczu, za chwilę wyjaśnię o co biega)

Piec + sterownik i trochę bałaganu, jak to w piwnicach :)

Problemy i błędy (ghrrr)

Niestety musiałem się zmierzyć z kilkoma nieprzewidzianymi problemami, które na nieszczęście objawiły się dopiero po połączeniu wszystkiego w miejscu docelowym. Kolejny dowód na to, że wszystkiego nie da się przewidzieć…

1. Częste restarty arduino

Okazało się, że jeśli załącza się pompka na parterze, to arduino wykonuje niekontrolowany restart, po którym następuje reset przekaźników, następnie włączana jest pompka na parterze, niekontrolowany restart… ad infinitum. Po grzebaniu i mierzeniu i dalszym testowaniu, winnymi okazały się zakłócenia powodowane przez zbyt bliskie poprowadzenie kabelków z 230V AC i sygnałowego 1-wire do czujnika na parterze. W związku z tym że odległość była spora, a wszystko szło w jednym kablu, zamiast 230V AC jest tam teraz 12V DC – przekaźnik na RelayShieldzie steruje za pomocą tego napięcia innym przekaźnikiem przy samej pompce. Pomogło.

2. Restartowanie arduino w kółko po przeprogramowaniu

To był ciekawy błąd. Używam laptopa z przejściówką USB-RS232 na chipie Prolific (z linuksem działa super), do tego kabel RS232 null-modem i na koniec widoczna na zdjęciach przejściówka RS232-FTDI. Po programowaniu arduino resetowało się w kółko, po chwili kombinowania i zastanawiania się o co właściwie mu chodzi, odpiąłem kabel RS232 od przejściówki przy sterowniku. Pomogło. Teraz leży zwinięty na piecu i czeka na wykorzystanie :)

3. Błędne odczyty temperatur

Tutaj diagnoza była w miarę prosta: albo źle podłączony czujnik (spalony poprzez zamianę biegunów), albo zbyt mały czas oczekiwania na przeliczenie temperatury, albo zbyt duża “waga” magistrali 1-wire. Niestety czujniki (zwłaszcza ten na piętrze i parterze) są znacznie oddalone od arduino, wobec czego należało zmniejszyć wartość rezystora mięczy linią +5V a szyną danych. Wartość dopasowałem “na oko” , z wykorzystaniem potencjometru wlutowanym równolegle do już istniejącego rezystora 4.7K i nastawionym na full, po czym kręciłem aż odczyt temperatury będzie prawidłowy. Następnie wylutowałem potencjometr, zmierzyłem nastawioną wartość, i wlutowałem odpowiedni rezystor. Jak można zauważyć, czasami odczyt nie jest prawidłowy i psuje porządek danych na wyświetlaczu, ale nie przeszkadza to w żaden sposób w działaniu, więc z tym nie walczę. Czujnik podpisany jako ZbCWU nie jest podłączony, stąd -0.0 na odczycie.

Rozwój

No cóż, to jeszcze nie koniec – pozostało podłączenie czujnika do bojlera CWU, a już mam plany jak w tym grzebać – przede wszystkim byłoby super gdyby udało mi się dodać port Ethernet i wypychać dane z czujników oraz stan przekaźników w sieć, tworząc wykresy :) Ciekawym (choć na razie mało realnym) pomysłem byłoby też dopięcie czujnika temperatury z zewnątrz, ale nawet nie mam pomysłu na algorytm wykorzystujący go podczas grzania :)

Tym niemniej sterownik działa jak należy już od dwóch tygodni, jest ciepło, a jeżeli się zawiesił, to watchdog go zrestartował jak należy, dzięki czemu dalej jest ciepło.

Ze swojej strony pozostaje mi tylko podziękować za poświęcony czas, oraz zachęcić Was do komentowania, głosowania i zgłaszania własnych pomysłów :)