Termostat ze sterowaniem pompą oparty na ESP8266

Do stworzenia termostatu opartego o ESP8266 nakłonił mnie znajomy. Potrzebował urządzenia sterującego grzałką i łatwo zdalnie konfigurowalnego. Zaraz pomyślałem o płytce NodeMCU którą miałem pod ręką...

Oprogramowanie nie powstało w języku LUA (co mogłaby sugerować płytka) a w języku C++ w środowisku programistycznym Arduino.

Choć urządzenie nie doczekało się działania w docelowej lokalizacji, to po publikacji projektu w Internecie otrzymałem sugestię by dodać obsługę pompy.
W chwili obecnej program umożliwia ustawienie temperatury utrzymywanej przez grzałkę (oraz definicję histerezy), możliwa jest również definicja temperatur przy których uruchamiana jest pompka obiegu wody. Na chwilę obecną projekt zawiera jedynie samo oprogramowanie, brak natomiast projektu płytki. By uruchomić urządzenie wystarczy do płytki NodeMcu podłączyć transoptor sterujący triakiem, który z kolei uruchamia np. grzałkę. Odczyt temperatury dokonywany jest za pomocą DS18B20.

Po wgraniu oprogramowania do układu należy nawiązać z nim połączenie za pośrednictwem portu UART (prędkość: 115200 baud).
Ważnym jest by jako zakończenie linii wybrać "nowa linia", czyli znak "\n" - informuje on ESP o zakończeniu wysyłania instrukcji, bądź ciągu znaków.
Wysyłając znak "h" wyświetlane jest menu z poziomu którego dokonujemy konfiguracji sieci WiFi (wyświetlamy dostępne sieci, łączymy z wybraną, wpisujemy hasło).
Po uzyskaniu adresu IP możliwa jest w następnej kolejności konfiguracja urządzenia za pośrednictwem przeglądarki stron internetowych.



Szczegółowy opis urządzenia oraz odnośniki do najnowszych "wsadów" dla ESP8266 opublikowałem w artykule ESP8266 - Termostat

Fajne! Ranking DIY

Może i się czepiam ale tą samą funkcjonalność można otrzymać przy pomocy esp easy i pewnie temu podobnych w ciągu kilku sekund bez środowiska "programistycznego".
No i pisanie, że program jest w C++ gdzie nie ma żadnej klasy jest dalekim nadużyciem.

Linoge napisał:

Może i się czepiam

Chyba tak

Linoge napisał:

ale tą samą funkcjonalność można otrzymać przy pomocy esp easy i pewnie temu podobnych w ciągu kilku sekund bez środowiska "programistycznego".

Oczywiście... Również można taką samą funkcjonalność uzyskać używając zakupionego w sklepie sprzętu. Ot, moje rozwiązanie jest takie jak zaprezentowałem... Co nie znaczy, że jedyne i jedynie słuszne. Jeśli ktoś chce skorzystać, miło mi - udostępniam wsad (nie ma potrzeby używania "środowiska programistycznego"). Jeśli natomiast ktoś chce sobie coś zmienić w programie i bardziej dostosować - udostępniam źródła.

Linoge napisał:

No i pisanie, że program jest w C++ gdzie nie ma żadnej klasy jest dalekim nadużyciem.

Czy przejrzałeś wszystkie pliki linkowane przez kompilator w tym programie?
Generalnie jest to kompilator języka C++ a nie C.

Pewno mu chodziło o zgubne skutki zawieszenia sie;) ale realnie patrząc dobrze zbudowany układ powinien przewidywać zespawanie się styków wiec zawieszenie tez nie zaszkodzi;) A czy esp się aż tak bardzo wiesza, mam prawie 3 lata w akwarium do sterowania oświetleniem i działa.
Częściej wynalazki fabryczne w bojlerach padają np dość często.

Galareta napisał:

Pewno mu chodziło o zgubne skutki zawieszenia sie;) ale realnie patrząc dobrze zbudowany układ powinien przewidywać zespawanie się styków wiec zawieszenie tez nie zaszkodzi;)

Jak napisałem w pierwszym poście, bardziej myślałem o triaku... Przekaźniki półprzewodnikowe również są... Może jestem w błędzie ale nie używam przekaźników opartych o elektromagnes.
Po za tym co złego się może stać w przypadku zawieszenia się? Większy rachunek za prąd i wodę? Trzeba być szaleńcem żeby mieć instalację CO bez zabezpieczenia (całkowicie zamknięty obieg).

Galareta napisał:

A czy esp się aż tak bardzo wiesza, mam prawie 3 lata w akwarium do sterowania oświetleniem i działa. Częściej wynalazki fabryczne w bojlerach padają np dość często.

Również jestem tego zdania. No ale może kolega sam wyjaśni co miał na myśli.

Galareta napisał:

Pewno mu chodziło o zgubne skutki zawieszenia sie;) ...

Mam do ESP (NodeMCU) podłączone 3 czujniki temperatury, 4 wilgotności i do tego ESP steruje siłownikiem otwierającym (w zależności od różnicy temperatur) okno w szklarni oraz wysyła zebrane dane na serwer. Układ (będący na zewnątrz) pracuje 4-ty rok i ani razu się nie zawiesił.

Nie oznacza to jednak, że nie należy się przed tym zabezpieczyć. W moim przypadku (gdyby się zawiesił) mogłoby mi poparzyć rośliny w szklarni.

Mam jedną uwagę do tego fragmentu kodu programu:

Dobra praktyka nakazuje, aby w C/C++ nie używać operatorów porównania (==) dla wartości typu float. Takie porównywanie wcale nie musi zwracać prawidłowej wartości logicznej. Akurat w tej części programu jest to niezwykle istotne.
Gdybyś trochę więcej czasu spędził na przetestowaniu tego kodu, to byś się o tym przekonał.
Zdaje sobie sprawę, że w necie jest pełno tego typu radosnego kodu, ale to nie znaczy, że należy go bezmyślnie powielać.

Tutaj możesz sobie o tym trochę poczytać.

khoam napisał:

... Dobra praktyka nakazuje, aby w C/C++ nie używać operatorów porównania (==) dla wartości typu float.

Problem, którego dotykasz tyczy się nie tylko C/C++. Spotkałem się z nimi w JS, PHP a najwcześniej spotkałem się z nim w Clipperze (gdzieś w okolicach roku 90 ubiegłego stulecia). O ile dobrze pamiętam problem tyczy się sposobu zapisu wartości zmiennoprzecinkowej w pamięci komputera (w systemie binarnym). Obstawiam, że tyczy się "wszystkich" języków programowania.

AGrodecki napisał:

...
O pompie też coś było. Pompa do grzałki?

Nie, do obiegu

AGrodecki napisał:

...
Generalnie im zadanie bardziej odpowiedzialne, tym bardziej odpowiedzialne wykonanie. Użycie zabawkowych modułów raczej nie wchodzi w grę. Dlatego część radioamatorska kosztuje 5zł, odpowiednia funkcjonalnie część do poważnego zastosowania kosztuje 50zł a tej samej funkcjonalności część do zastosowań przemysłowych kosztuje 500zł. Pewnych rzeczy na szemranych modułach nie robi się w ogóle. Po prostu.

W porządku. Tylko proszę nie wyolbrzymiaj, że z powodu zawieszenia ESP zatną się czujniki temperatur (te Twoje profesjonalne), zatnie się zawór bezpieczeństwa, jednocześnie zablokuje zawór gazowy, i trafią w kocioł wszystkie nieszczęścia tego świata.

khoam napisał:

Mam jedną uwagę do tego fragmentu kodu programu:
Dobra praktyka nakazuje, aby w C/C++ nie używać operatorów porównania (==) dla wartości typu float. Takie porównywanie wcale nie musi zwracać prawidłowej wartości logicznej. Akurat w tej części programu jest to niezwykle istotne.
Gdybyś trochę więcej czasu spędził na przetestowaniu tego kodu, to byś się o tym przekonał.

Prawdę mówiąc z powodzeniem testuję niemalże od 10 lat.
Do tego projektu zaczerpnąłem to rozwiązanie z CCS C dla mikrokontrolerów PIC, jednak widzę, że to rozwiązanie jest również stosowane w wielu innych bibliotekach...
Po wpisaniu w google "while (temp == 85.0 || temp == (-127.0));" zwracana jest cała masa stron, co oczywiście nie znaczy, że musi to być prawidłowe.
Zapoznam się z linkiem jaki dostarczyłeś, zakładam, że rzutowanie na int powinno rozwiązać sprawę. Dzięki za zwrócenie uwagi - nie znałem tego problemu.

Dodano po 10 [minuty]:

AGrodecki napisał:

Zawór bezpieczeństwa się nie zatnie. Przy zagotowaniu wody puści i jak to z nimi zazwyczaj bywa, już się nie zamknie .

No i wszystko prawidłowo.

AGrodecki napisał:

Powtarzam, tak odpowiedzialnych zadań takiej padlinie jak ten moduł się nie powierza.

Jaki układ zatem kolega poleca?

Przypominam, że znajdujemy się w dziale DIY i mamy tu do czynienia z konstrukcjami amatorskimi, które wykonujemy dla własnej satysfakcji i na własną odpowiedzialność. Nie są to konstrukcje komercyjne, choć i w takich ESP8266 znajduje zastosowanie (przykład pierwszy z brzegu - Sonoff Smart Home). Wniosek jaki wyciągam z narzekań forumowiczów jest taki, że powinienem w artykule zaznaczyć fakt iż ingerencja w układ CO rodzi pewne ryzyko, z którego być może nie wszyscy zdają sobie sprawę.

Ja już widziałem układy STM32 w poważnych komercyjnych produktach.
Sam mam sterownik CO na arduino mini pro już 3 lata i działa OK choć długo poprawiałem błędy w trakcie życia systemu.
Dodam tylko że zabezpieczenia pozostały seryjne i działają niezależnie.

pitron napisał:

...
Dodam tylko że zabezpieczenia pozostały seryjne i działają niezależnie.

Tego właśnie nie rozumie kolega AGrodecki.

Myślę, że rozumie, ale chodzi mu o coś innego.
Każde urządzenie należy produkować z myślą o jego awarii i konsekwencjach jakie z niej wynikną.
Awaria urządzenia do podlewania kwiatków może doprowadzić do
a) utopienia kwiatków
b) ususzenia kwiatków
Awaria rozrusznika serca może doprowadzić do
a) śmierci pacjenta
b) poważnych problemów zdrowotnych
Awaria sterownika CO może doprowadzić do
a) ... i tu wpisujemy nasze propozycje

Teraz jakie są konsekwencje awarii urządzenia do kwiatków? Niewielkie. Czy potrzebujemy zabezpieczenia? Raczej nie - w najgorszym wypadku stracimy kwiatki, ewentualnie zaleje nam podłogę. Warto zabezpieczyć? W ograniczonym zakresie, tak - np. dodać watchdog sprzętowy, dodatkowe programowe funkcje które przerwą program jeśli np. czujnik wilgotności przestanie odpowiadać albo będą dozować średnią dawkę.
Jakie są konsekwencje dla rozrusznika serca? Chyba nie muszę opowiadać... Błędy oprogramowania się zdarzają, problemy sprzętowe również.
A co z piecem CO? I na ten problem zwraca uwagę AGrodecki. Trzeba brać pod uwagę możliwości awarii i liczyć się z konsekwencjami. Czasem wystarczy zmienić program, czasem dodać sprzętowe zabezpieczenie, a czasem totalnie zrezygnować ze stosowania rozwiązania.

hindoos napisał:

...
Każde urządzenie należy produkować z myślą o jego awarii i konsekwencjach jakie z niej wynikną....
...

Kolego. Możemy pisać eseje odbiegając od głównego tematu. Jasne, że tak należy i jak wczytasz się w wątek to zauważysz, że jest kilku (w tym ja), którym udało się obsłużyć coś za pomocą "badziewia" baz błędów. Dlaczego? Bo problemy zawieszania w dużej mierze to źle napisana aplikacja.

Na domiar złego - onegdaj byłem wzywany do ASO na aktualizację oprogramowanie hamulca parkingowego. Z tego co wyczytałem w necie, zdarzały się przypadki automatycznego zaciągnięcia się hamulca przy prędkości podróżnej. Tak wygląda "myślenie o skutkach awarii" i proszę nie demonizujmy, że ESP, który steruje grzałką i pompą jest zagrożeniem. W każdym takim układzie stosuje się niezależne zabezpieczenia i to bez znaczenia czy grzałką steruje ESP czy "profesjonalny" układ. Gdyby "profesjonalny" był bezawaryjny to nie byłyby potrzebne zabezpieczenia.

EOT.

kolgreen napisał:

Prawdę mówiąc z powodzeniem testuję niemalże od 10 lat.

Na płytce stykowej ?!

kolgreen napisał:

Na chwilę obecną projekt zawiera jedynie samo oprogramowanie, brak natomiast projektu płytki. By uruchomić urządzenie wystarczy do płytki NodeMcu podłączyć transoptor sterujący triakiem, który z kolei uruchamia np. grzałkę

Kolego zdecyduj się, czy piszemy o tym, co opublikowałeś na tym forum, czy o Twoich dotychczasowych doświadczeniach zawodowych.

kolgreen napisał:

powinienem w artykule zaznaczyć fakt iż ingerencja w układ CO rodzi pewne ryzyko, z którego być może nie wszyscy zdają sobie sprawę.

Tak, powinieneś o tym napisać. Dodatkowo też powinieneś skromnie wspomnieć, że opublikowane przez Ciebie oprogramowanie nie zawiera żadnych procedur autodiagnostycznych sterownika np. weryfikacji poprawności działania sensora temperatury w trakcie działania całego układu. W końcu nie chodzi tu o sterownik do oświetlenia na choinkę.

kolgreen napisał:

Zapoznam się z linkiem jaki dostarczyłeś, zakładam, że rzutowanie na int powinno rozwiązać sprawę.

Niestety nie rozwiąże problemu. W podanym przeze mnie linku jest wiele przykładów na rozwiązanie tego problemu.
W tej chwili wystąpienie błędów w odczycie temperatury jest całkowicie ignorowane przez Twój kod, ale sterownik "działa".

khoam napisał:

kolgreen napisał:

Prawdę mówiąc z powodzeniem testuję niemalże od 10 lat.

Na płytce stykowej ?!

Nie. Dlaczego? Jeśli zerkniesz na moją skromną stronę zauważysz, że żadne z urządzeń nie jest zbudowane na płytce stykowej. Jestem daleki od tego typu rozwiązań. ESP8266 można oczywiście wstawić jako "moduł" do zaprojektowanej przez siebie płytki (na gold pinach), ale o wiele lepiej zwyczajnie wlutować. Na przykład będący w takiej postaci:

kolgreen napisał:

Dlaczego?

Pewnie dlatego, że w pierwszym poście dałeś obrazek z płytki stykowej

Moderowany przez tmf:

Koledzy, proszę trzymać się tematu. Dyskusje nie na temat, można prowadzić w HydeParku lub odpowiednich działach Po godzinach.

Witam
tak dla testu chciałem kompilować kod który zamieściłeś ale niestety się nie da wywala błędy.

kuba2509 napisał:

tak dla testu chciałem kompilować kod który zamieściłeś ale niestety się nie da wywala błędy.

U mnie się kompiluje bez błędów. Może wybrałeś niewłaściwą płytkę - ma być NodeMCU.

kuba2509 napisał:

Witam
tak dla testu chciałem kompilować kod który zamieściłeś ale niestety się nie da wywala błędy.

Jak tu kolega powyżej napisał - sprawdź czy wybrałeś dobrą płytkę lub pokaż błędy.

Dodano po 4 [minuty]:

khoam napisał:

Dobra praktyka nakazuje, aby w C/C++ nie używać operatorów porównania (==) dla wartości typu float.

Zagłębiłem się trochę w temat i jestem chyba bogatszy o jakąś wiedzę.

Została dodana funkcja porównująca floaty czy są sobie równe, z dokładnością przesadną przy pomiarze temperatury:



I teraz odczyt wygląda następująco:



Co zatem wiąże się z powyższym, kod jak i binarka zostały zaktualizowane.
Jest też innych kilka aktualizacji, jak np. pokazanie w przeglądarce czy pompa i grzałka są włączone.

To teraz trzeba sobie odpowiedzieć na pytanie: co się stanie jeżeli te błędy odczytu temperatury będą miały charakter permanentny np. w wypadku uszkodzenia sensora?
Pętla będzie działać w nieskończoność, a grzałka raz włączona grzać czas cały. Nie widziałem, aby kolega obsługiwał w kodzie watchdog - nie ma też obsługi błędów na tę okoliczność.
Nie czepiam się, to akurat jest bardzo ważne.

Dodano po 27 [minuty]:

kolgreen napisał:

if (fabsf(a-b) < 0.0001f){

Zamiast 0.0001f użyłbym stałej FLT_EPSILON - trzeba dołączyć plik nagłówkowy "float.h".