OpenBeken może być używany do tworzenia prostych automatyzacji obejmujących wiele urządzeń bez Home Assistant. Nie jest wymagany żaden centralny serwer, wystarczy mieć sflashowane urządzenia Tuya. Tutaj pokażę jedną z takich automatyzacji, w której wykorzystywane są dwa urządzenia - pierwszym jest miernik mocy, używany do pomiaru zużycia energii przez urządzenie, a drugim jest przekaźnik używany do włączania i wyłączania chłodzenia. Chłodzenie zostanie włączone, gdy pobór mocy przekroczy określony próg.
Ta prosta konfiguracja jest wymagana dla mojej karty chłodzenia laptopa DIY, jak pokazano tutaj:
Czy podstawka chłodząca DIY wykonana z wentylatorów 12V pomoże w przegrzewaniu się laptopa?
Najpierw zastanówmy się nad wymaganiami:
- chłodzenie będzie używane w prostym trybie włącz/wyłącz, bez regulacji PWM
- pierwsze urządzenie będzie tylko mierzyć pobór mocy i wysyłać je do drugiego urządzenia
- drugie urządzenie będzie oferować tryb automatyczny lub ręczny, w trybie automatycznym będzie porównywać moc z podanym progiem i włączać przekaźnik, jeśli próg zostanie przekroczony
W razie potrzeby to samo można zrobić z bardziej niezawodnym pomiarem temperatury.
Rozważmy teraz najpierw dostępny sprzęt.
- Laptop jest chłodzony przez wentylatory, które pracują z napięciem 5V. Jest to ważna informacja, ponieważ zostanie ona później wykorzystana do uproszczenia obwodu
- LSPA9 wtyczka mierzy zużycie energii:
- urządzenie DIY kontroluje moc wentylatorów, urządzenie może pracować bezpośrednio na zasilaniu 5V, nie wymaga zasilania sieciowego
Krótkie wprowadzenie
OpenBeken działa obecnie na wielu różnych modułach WiFi. Moduły te można łatwo podłączyć do Home Assistant, ale nie jest to konieczne do prostych automatyzacji. OpenBeken obsługuje system skryptów poprzez LittleFS, tutaj można zobaczyć kilka przykładowych skryptów. Więcej informacji można znaleźć w naszej dokumentacji:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/README.md
DIY urządzenie do sterowania wentylatorami
Moje obecne wentylatory nie działają dobrze z PWM, więc zdecydowałem się na przekaźnik. W przyszłości mogę wprowadzić również sterowanie PWM, ale teraz potrzebowałem tylko podstawowej możliwości ich włączania i wyłączania. Dlatego zdecydowałem się przekonwertować stary smart switch z uszkodzoną przetwornicą 230V na 5V :
Poniższy moduł przełącznika posiada prostą, zasilaną z sieci przetwornicę step down, która dostarcza 5V dla przekaźnika, które jest następnie podawane do 3.3V LDO zasilającego moduł WiFi.
W przypadku zasilania całego układu z 5V, pierwsza przetwornica 230V na 5V nie jest potrzebna, ale należy pamiętać, że napięcie wyższe niż 5V może po prostu spalić LDO 3.3V i moduł WiFi . Jeśli chcesz używać napięcia 12V, wymagany jest konwerter napięcia 12V na 3,3V.
Obwód końcowy:
Zastąpiłem również pełny mostek prostowniczy prostą diodą, ponieważ prąd stały jest tutaj już na wejściu, a dodatkowa dioda jest używana tylko do ochrony przed odwrotną polaryzacją.
DHT11 wyprowadzony do późniejszych eksperymentów:
Obudowa:
.
Ustawienie pomiaru mocy
LSPA9 był już sflashowany, potrzebował tylko skryptu do raportowania poboru mocy do urządzenia docelowego.
Postanowiłem zrobić to za pomocą polecenia HTTP GET ze składnią w stylu Tasmota:
again:
SendGET http://192.168.0.111/cm?cmnd=setChannel%202%20$power
delay_s 0.5
goto again
Upewnij się, że IP urządzenia docelowego jest poprawnie wpisane w skrypcie, upewnij się również, że się nie zmieni (zrób rezerwację MAC na routerze).
To w zasadzie wysyła polecenie ustawienia kanału:
setChannel 2 $power
a $power jest rozszerzane do bieżącej wartości mocy z BL0937.
Konfiguracja urządzenia przekaźnikowego
Urządzenie przekaźnikowe będzie miało nieco bardziej zaawansowany skrypt.
Chciałbym, aby skrypt oferował dwa tryby:
- tryb automatyczny, w którym przekaźnik jest automatycznie ustawiany na otwarty lub zamknięty, w zależności od aktualnego odczytu i podanego marginesu
- tryb ręczny, w którym użytkownik może dowolnie sterować przekaźnikiem.
Ponadto chciałbym, aby margines był konfigurowalny w GUI urządzenia.
Na szczęście wszystko to jest możliwe dzięki typom kanałów OBK:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/channelTypes.md
Zacznijmy pisanie skryptu od określenia kanałów, których potrzebujemy:
// main relay
setChannelType 1 Toggle
setChannelLabel 1 Relay
// working mode
setChannelType 2 Toggle
setChannelLabel 2 Automatic Mode
// received power [W]
setChannelLabel 3 Power
setChannelType 3 Power
// min power to enable cooling
setChannelType 4 TextField
setChannelLabel 4 Min Power To Cool
Warto również zapisać te kanały we flashvars, aby były przechowywane między restartami:
// remember channels
setStartValue 1 -1
setStartValue 2 -1
setStartValue 3 -1
setStartValue 4 -1
Teraz musimy zaimplementować główną logikę... przekaźnik musi być ustawiony na wartość określoną przez zależność danego progu i aktualnego odczytu. Musi się to odbywać często, mniej więcej co sekundę, może 10 sekund... na szczęście okazuje się, że można to zrobić w kilku linijkach:
again:
if $CH2==1 then setChannel 1 $CH3>$CH4
delay_s 1
Jeśli kanał 2 jest 1 (jeśli tryb jest automatyczny), to ustaw kanał przekaźnika na wynik porównania marginesu i wartości. Jeśli kanał 3 jest większy niż 4, to da 1, włączając przekaźnik.
REKLAMA
A oto panel OBK dla tego skryptu:
Użycie czujnika temperatury zamiast zasilania
Pobór mocy może nie być najlepszym wskaźnikiem zapotrzebowania na chłodzenie, ale pokazany skrypt można po prostu dostosować, aby zamiast tego użyć zmierzonej temperatury. OpenBeken obsługuje serię czujników DHT, DS18B20 powinien również działać poprawnie, więc jeśli zapiszesz temperaturę w kanale 3 , ta sama logika, która działa dla mocy, może teraz działać dla temperatury. Nie są wymagane żadne dalsze zmiany w skrypcie.
Testowanie skryptu automatyzacji za pomocą symulatora OpenBeken
Ta sekcja nie jest obowiązkowa, to tylko zalecenie dla programistów .
OpenBeken zawiera symulator urządzenia IoT , który jest wyposażony w automatyczny system autotestu. Autotesty są używane do upewnienia się, że każda kompilacja nie łamie kompatybilności z oczekiwanymi funkcjami i zachowaniami OBK.
Autotesty są uruchamiane automatycznie na Githubie z każdą wersją online .
Oto autotest, który zaprojektowałem:
Kod: C / C++
Zaloguj się, aby zobaczyć kod
Poniższy kod konfiguruje wspomniany skrypt wewnątrz symulatora, a następnie symuluje różne scenariusze przypadków użycia, najpierw scenariusz z wyłączonym automatycznym sterowaniem, a następnie scenariusz z włączonym automatycznym sterowaniem. Symuluje również losowy odczyt mocy i sprawdza, czy zachowanie przekaźnika jest zgodne z oczekiwaniami. Wszystkie oczekiwane stany OBK są potwierdzane za pomocą makr preprocesora ASSERT. Jeśli dana asercja nie powiedzie się, autotesty są zatrzymywane z błędem, dzięki czemu programista może sprawdzić, co jest nie tak.
Mechanizm selftestów jest bardzo przydatny, ponieważ pozwala nam szybko sprawdzić, czy nowe zmiany działają zgodnie z oczekiwaniami. Selftest zakończy się niepowodzeniem, jeśli którakolwiek z nowych zatwierdzonych zmian łamie niektóre ze starych funkcji, które są objęte autotestami.
Selftesty mogą być również uruchamiane na komputerze, podobnie jak wspomniany Symulator OBK.
Podsumowanie
W ten sposób można stworzyć bardzo proste urządzenie przypominające termostat, z jednym lub nawet dwoma oddzielnymi urządzeniami. Termostat można łatwo włączać i wyłączać, a wartość progowa jest również dostępna w GUI.
Jeśli potrzebujesz bardziej zaawansowanego rozwiązania, możesz również rozważyć
tworzenie własnego sterownika .
To na razie wszystko, ale w następnej części pokażę podobny mechanizm, ale z obsługą chłodzenia PWM (stopniowego). Będzie to używane do zmniejszenia hałasu wentylatora, gdy silne chłodzenie nie jest potrzebne.
Fajne? Ranking DIY Pomogłem? Kup mi kawę.
