Dziś zhakujemy ... podgrzewacz wody. Tym razem lutowanie będzie minimalne.
Krótko mówiąc, jakieś dwa lata temu kupiłem sobie nową pompę ciepła podgrzewacz wody .
Podgrzewacz z pompą ciepła jest około 3x bardziej wydajny niż elektryczny i wszystko jest fajne, z wyjątkiem wentylatora sprężarki. Po wieczornym prysznicu działa jeszcze przez godzinę lub dwie, wydając grzechoczący dźwięk - producent (sic!) powiedział, że to normalne. Rozwiązaniem było ręczne przyjście do pralni i zmiana trybu na elektryczny. Następnie, rano, zmienić go z powrotem na pompę ciepła, spłukać, powtórzyć, pokonać cel. Chcę więc, aby przełączał się na elektryczny zaraz po wieczornym prysznicu (czujnik wilgotności) i wracał do pompy ciepła około 4 nad ranem.
Grzałka jest wyposażona w port CEA 2045 do zdalnego sterowania*. (Uwaga: port ma styki 240 V, więc należy zachować szczególną ostrożność!) Lowes miał nawet usługę w chmurze, aby z niej korzystać. Fajnie, co? Ale usunęli ją, zanim jeszcze dostałem swój grzejnik. Kiedyś działał za pośrednictwem dodatkowego klucza sprzętowego IRIS. Można je dostać na eBay całkiem tanio , ponieważ nie są już przydatne. Jednak nie dla ciekawskiego umysłu.
Zdobyłem więc klucz IRIS i natychmiast go otworzyłem. Ma układ scalony do dekodowania protokołu CEA i moduł Wi-Fi ISM43362 firmy Inventeksys do wysyłania danych. Tuż obok modułu Wi-Fi znajdują się dwa otwory na piny RX i TX (zwykły nagłówek 0,1 cala, oznaczony 1) oraz piny 3,3 V / GND na 5-pinowym nagłówku, który ma 2 mm, oznaczony 2 (pin 3 - 3,3 V, pin 4 - GND, piny 1,2 również pokazują 3,3 V, ale nie są podłączone do pinu VCC modułu Wi-Fi - używaj na własne ryzyko).
Podłączyłem adapter UART (użyłem ESP32), aby zobaczyć, co się dzieje. Konfiguracja dla ESP32 znajduje się poniżej.
I żyje. Początkowo próbuje połączyć się z https://energysmartwaterheater.com. Ta usługa nie jest już dostępna, więc musiałem dodać rekord A do mojego DNS** (używam Pihole, ale może to być cokolwiek) i przekierować https://energysmartwaterheater.com na 192.168.0.1 (lub gdziekolwiek będziesz hostował most). Ale to nie jest takie proste - teraz pokazuje błąd SSL:
Na szczęście w Internecie są mądrzy ludzie, którzy na to wpadli: https://github.com/excaliburpartners/EnergySmartBridge. Udostępniają oni kontener docker i wszystko powinno działać od samego początku. Zanim zastosujesz się do ich instrukcji i zbudujesz kontener, przeczytaj poniżej. Kiedy utworzyli konfigurację Docker dla kontenera odwrotnego proxy, użyli obrazu nginx:latest. Najnowszą wersją była wówczas 1.24. Teraz najnowszą wersją jest 1.27, która już nie działa, więc musisz edytować ich plik docker w /energysmart-proxy: nginx:latest -> nginx:1.24. Następnie edytuj konfigurację (zarówno docker-compose.yml, jak i EnergySmartBridge.ini) - podaj adres swojego brokera MQTT, zrób docker-compose build i docker-compose up -d. Ha, teraz jest lepiej:
Usługa EnergySmartBridge wysyła kilka komunikatów MQTT raportujących stan sterownika nagrzewnicy. Ładne, ale bardzo ograniczone. Ten facet (https://github.com/starsoccer/energysmartbridge) rozszerzył most i ujednolicił go z odwrotnym proxy. Nie mogłem sprawić, by jego odwrotne proxy działało, więc wziąłem jego kod źródłowy tylko dla mostu (https://github.com/starsoccer/energysmartbridge/tree/master/energysmartbridge/src) i skopiowałem go do EnergySmartBridge/EnergySmartBridge, który został utworzony zgodnie z instrukcjami tutaj https://github.com/excaliburpartners/EnergySmartBridge . Zatrzymaj wszystkie kontenery utworzone przez EnergySmartBridge, usuń ich obrazy, powtórz procedury budowania i uruchamiania (nie zapomnij zaktualizować EnergySmartBridge.ini). Teraz obserwuj logi UART. Po nawiązaniu połączenia w eksploratorze MQTT powinny pojawić się nowe tematy, w szczególności "homeassistant/water_heater/C47F5101D65F/config", w którym można ustawić konfigurację. Przede wszystkim definiuje on "mode_command_topic": "energysmart/C47F5101D65F/mode_command", oraz "modes": ["eco", "heat_pump", "electric", "off"]. Możesz albo wysyłać rzeczy bezpośrednio do tego tematu przez mosquito, albo możesz utworzyć wpis klimatyczny w Home Assistant: (120C to w rzeczywistości 120F; kiedy ustawiam grzejnik na C, zachowuje się dziwnie - zbadam więcej)
Teraz możesz zmienić tryb! Należy pamiętać, że klucz sprzętowy łączy się z mostkiem tylko raz na 5 minut. Jeśli więc zmienisz tryb w Home Assistant, nie spiesz się do grzejnika, aby potwierdzić; poczekaj, aż logi UART pokażą kolejne udane połączenie. Teraz podłącz go do automatyki i gotowe! Teraz możesz odłączyć monitor UART.
Dla tych, którzy nie chcą bawić się kontenerami Docker i sieciami, istnieje alternatywny, bardziej hardware'owy sposób . Przeczytaj także sekcję komentarzy!
* Sam protokół to RS485, ale jest on dość bezużyteczny bez wiedzy o tym, jak dekodować dane. Klucz sprzętowy ma układ scalony do dekodowania.
** Pobawiłem się również konfiguracją routera, aby wymusić przekierowanie całego ruchu (zwłaszcza żądań do 8.8.8.8) z klucza sprzętowego na 192.168.0.1. Okazuje się, że nie jest to konieczne
Krótko mówiąc, jakieś dwa lata temu kupiłem sobie nową pompę ciepła podgrzewacz wody .
Podgrzewacz z pompą ciepła jest około 3x bardziej wydajny niż elektryczny i wszystko jest fajne, z wyjątkiem wentylatora sprężarki. Po wieczornym prysznicu działa jeszcze przez godzinę lub dwie, wydając grzechoczący dźwięk - producent (sic!) powiedział, że to normalne. Rozwiązaniem było ręczne przyjście do pralni i zmiana trybu na elektryczny. Następnie, rano, zmienić go z powrotem na pompę ciepła, spłukać, powtórzyć, pokonać cel. Chcę więc, aby przełączał się na elektryczny zaraz po wieczornym prysznicu (czujnik wilgotności) i wracał do pompy ciepła około 4 nad ranem.
Grzałka jest wyposażona w port CEA 2045 do zdalnego sterowania*. (Uwaga: port ma styki 240 V, więc należy zachować szczególną ostrożność!) Lowes miał nawet usługę w chmurze, aby z niej korzystać. Fajnie, co? Ale usunęli ją, zanim jeszcze dostałem swój grzejnik. Kiedyś działał za pośrednictwem dodatkowego klucza sprzętowego IRIS. Można je dostać na eBay całkiem tanio , ponieważ nie są już przydatne. Jednak nie dla ciekawskiego umysłu.
Zdobyłem więc klucz IRIS i natychmiast go otworzyłem. Ma układ scalony do dekodowania protokołu CEA i moduł Wi-Fi ISM43362 firmy Inventeksys do wysyłania danych. Tuż obok modułu Wi-Fi znajdują się dwa otwory na piny RX i TX (zwykły nagłówek 0,1 cala, oznaczony 1) oraz piny 3,3 V / GND na 5-pinowym nagłówku, który ma 2 mm, oznaczony 2 (pin 3 - 3,3 V, pin 4 - GND, piny 1,2 również pokazują 3,3 V, ale nie są podłączone do pinu VCC modułu Wi-Fi - używaj na własne ryzyko).
Podłączyłem adapter UART (użyłem ESP32), aby zobaczyć, co się dzieje. Konfiguracja dla ESP32 znajduje się poniżej.
Spoiler:
esphome:
name: esphome-water_heater
friendly_name: Podgrzewacz wody
platforma: esp32
board: esp32doit-devkit-v1
# Włącz logowanie
logger:
level: VERBOSE
baud_rate: 0
# Włącz interfejs API Home Assistant
api:
ota:
wifi:
ssid: "mySSID"
hasło: "myPassword"
use_address: 192.168.0.30
ap:
ssid: "awaryjny hotspot podgrzewacza wody"
hasło: "0zr7bHSn1epQ"
web_server:
port: 80
uart:
id: my_uart
tx_pin: GPIO1
rx_pin: GPIO3
baud_rate: 115200
debug:
direction: BOTH
dummy_receiver: true
after:
delimiter: "\n"
sequence:
- lambda: UARTDebug::log_string(direction, bytes);
name: esphome-water_heater
friendly_name: Podgrzewacz wody
platforma: esp32
board: esp32doit-devkit-v1
# Włącz logowanie
logger:
level: VERBOSE
baud_rate: 0
# Włącz interfejs API Home Assistant
api:
ota:
wifi:
ssid: "mySSID"
hasło: "myPassword"
use_address: 192.168.0.30
ap:
ssid: "awaryjny hotspot podgrzewacza wody"
hasło: "0zr7bHSn1epQ"
web_server:
port: 80
uart:
id: my_uart
tx_pin: GPIO1
rx_pin: GPIO3
baud_rate: 115200
debug:
direction: BOTH
dummy_receiver: true
after:
delimiter: "\n"
sequence:
- lambda: UARTDebug::log_string(direction, bytes);
I żyje. Początkowo próbuje połączyć się z https://energysmartwaterheater.com. Ta usługa nie jest już dostępna, więc musiałem dodać rekord A do mojego DNS** (używam Pihole, ale może to być cokolwiek) i przekierować https://energysmartwaterheater.com na 192.168.0.1 (lub gdziekolwiek będziesz hostował most). Ale to nie jest takie proste - teraz pokazuje błąd SSL:
Spoiler:
[06:00:33][D][uart_debug:158]: <<< "[BOOT AC] Enabled\r\n"
[06:00:33][D][uart_debug:158]: <<< "[JOIN ] mySSID"
[06:00:40][D][uart_debug:158]: <<< ",192.168.0.12,0,0\r\n"
[06:00:40][D][uart_debug:158]: <<< "\r\n"
[06:00:40][D][uart_debug:158]: <<< " ____ __ __ _ _____ _\r\n"
[06:00:40][D][uart_debug:158]: <<< " ___ / ___| \\\ / / /(_)| ___|(_)\r\n"
[06:00:40][D][uart_debug:158]: <<< " / _ \\\\___ \\\ _____\\\ \\\ /\ / | | | | |_ | |\r\n"
[06:00:40][D][uart_debug:158]: <<< " | __/ ___) |_____|\\V V / | || _| | |\r\n"
[06:00:40][D][uart_debug:158]: <<< " \\___||____/ \\\_/ \\_/ |_||| |_|\r\n"
[06:00:40][D][uart_debug:158]: <<< "\r\n"
[06:00:40][D][uart_debug:158]: <<< "Inventek Systems\r\n"
[06:00:40][D][uart_debug:158]: <<< " Embedding Connectivity Everywhere\r\n"
[06:00:41][D][uart_debug:158]: <<< " Copyright (c)2011-2013\r\n"
[06:00:41][D][uart_debug:158]: <<< "\r\n"
[06:00:41][D][uart_debug:158]: <<< "> \r\n"
[06:00:41][D][uart_debug:158]: <<< "C4:7F:51:01:D 6:5F\r\n"
[06:00:41][D][uart_debug:158]: <<<
"ISM43362-M3G-L44,C2.4.0.3.AO7,v2.4.0,v1.4.0.rc1,v7.1.0,120000000,energySmart
eS-WiFi FW-3.1\r\n"
[06:00:41][D][uart_debug:158]: <<<
"mySSID,myPASSWORD,3,1,0,192.168.0.12,255.255.255.0,192.168.0.5,255.255.255.255,255.255.255.255,2,1,0,US,1\r\n"
pominięto kilka użądleń
[06:02:45][D][uart_debug:158]: <<< "> \r\n"
[06:02:45][D][uart_debug:158]: <<< "[TCP SSL] Łączenie z 192.168.0.1\r\n"
[06:02:45][D][uart_debug:158]: <<< "[TCP SSL] Niepowodzenie walidacji: 0C\r\n"
[06:02:45][D][uart_debug:158]: <<< "[TCP SSL] Zaawansowany kontekst, nie udało się połączyć\r\n"
[06:02:45][D][uart_debug:158]: <<< "BŁĄD: Nieznany błąd\r\n"
[06:02:45][D][uart_debug:158]: <<< "Usage: P6 <0 = Stop, 1 = Start> \r\n"
[06:02:45][D][uart_debug:158]: <<< "> \r\n"
[06:00:33][D][uart_debug:158]: <<< "[JOIN ] mySSID"
[06:00:40][D][uart_debug:158]: <<< ",192.168.0.12,0,0\r\n"
[06:00:40][D][uart_debug:158]: <<< "\r\n"
[06:00:40][D][uart_debug:158]: <<< " ____ __ __ _ _____ _\r\n"
[06:00:40][D][uart_debug:158]: <<< " ___ / ___| \\\ / / /(_)| ___|(_)\r\n"
[06:00:40][D][uart_debug:158]: <<< " / _ \\\\___ \\\ _____\\\ \\\ /\ / | | | | |_ | |\r\n"
[06:00:40][D][uart_debug:158]: <<< " | __/ ___) |_____|\\V V / | || _| | |\r\n"
[06:00:40][D][uart_debug:158]: <<< " \\___||____/ \\\_/ \\_/ |_||| |_|\r\n"
[06:00:40][D][uart_debug:158]: <<< "\r\n"
[06:00:40][D][uart_debug:158]: <<< "Inventek Systems\r\n"
[06:00:40][D][uart_debug:158]: <<< " Embedding Connectivity Everywhere\r\n"
[06:00:41][D][uart_debug:158]: <<< " Copyright (c)2011-2013\r\n"
[06:00:41][D][uart_debug:158]: <<< "\r\n"
[06:00:41][D][uart_debug:158]: <<< "> \r\n"
[06:00:41][D][uart_debug:158]: <<< "C4:7F:51:01:D 6:5F\r\n"
[06:00:41][D][uart_debug:158]: <<<
"ISM43362-M3G-L44,C2.4.0.3.AO7,v2.4.0,v1.4.0.rc1,v7.1.0,120000000,energySmart
eS-WiFi FW-3.1\r\n"
[06:00:41][D][uart_debug:158]: <<<
"mySSID,myPASSWORD,3,1,0,192.168.0.12,255.255.255.0,192.168.0.5,255.255.255.255,255.255.255.255,2,1,0,US,1\r\n"
pominięto kilka użądleń
[06:02:45][D][uart_debug:158]: <<< "> \r\n"
[06:02:45][D][uart_debug:158]: <<< "[TCP SSL] Łączenie z 192.168.0.1\r\n"
[06:02:45][D][uart_debug:158]: <<< "[TCP SSL] Niepowodzenie walidacji: 0C\r\n"
[06:02:45][D][uart_debug:158]: <<< "[TCP SSL] Zaawansowany kontekst, nie udało się połączyć\r\n"
[06:02:45][D][uart_debug:158]: <<< "BŁĄD: Nieznany błąd\r\n"
[06:02:45][D][uart_debug:158]: <<< "Usage: P6 <0 = Stop, 1 = Start> \r\n"
[06:02:45][D][uart_debug:158]: <<< "> \r\n"
Na szczęście w Internecie są mądrzy ludzie, którzy na to wpadli: https://github.com/excaliburpartners/EnergySmartBridge. Udostępniają oni kontener docker i wszystko powinno działać od samego początku. Zanim zastosujesz się do ich instrukcji i zbudujesz kontener, przeczytaj poniżej. Kiedy utworzyli konfigurację Docker dla kontenera odwrotnego proxy, użyli obrazu nginx:latest. Najnowszą wersją była wówczas 1.24. Teraz najnowszą wersją jest 1.27, która już nie działa, więc musisz edytować ich plik docker w /energysmart-proxy: nginx:latest -> nginx:1.24. Następnie edytuj konfigurację (zarówno docker-compose.yml, jak i EnergySmartBridge.ini) - podaj adres swojego brokera MQTT, zrób docker-compose build i docker-compose up -d. Ha, teraz jest lepiej:
Spoiler:
[06:04:26][D][uart_debug:158]: <<< "[TCP SSL] Connecting to 192.168.0.1\r\n".
pominięto kilka żądeł
[06:04:27][D][uart_debug:158]: <<< "HTTP/1.1 200 OK\r\n"
[06:04:27][D][uart_debug:158]: <<< "Server: Mono-HTTPAPI/1.0\r\n"
[06:04:27][D][uart_debug:158]: <<< "Date: Fri, 07 Jun 2024 06:04:27 GMT\r\n"
[06:04:27][D][uart_debug:158]: <<< "Content-Length: 15\r\n"
[06:04:27][D][uart_debug:158]: <<< "Keep-Alive: timeout=15,max=100\r\n"
[06:04:27][D][uart_debug:158]: <<< "\r\n"
[06:04:27][D][uart_debug:158]: <<< "{\"Success\":\"0\"}\r\n"
[06:04:27][D][uart_debug:158]: <<< "OK\r\n" <span class="notranslate">
pominięto kilka żądeł
[06:04:27][D][uart_debug:158]: <<< "HTTP/1.1 200 OK\r\n"
[06:04:27][D][uart_debug:158]: <<< "Server: Mono-HTTPAPI/1.0\r\n"
[06:04:27][D][uart_debug:158]: <<< "Date: Fri, 07 Jun 2024 06:04:27 GMT\r\n"
[06:04:27][D][uart_debug:158]: <<< "Content-Length: 15\r\n"
[06:04:27][D][uart_debug:158]: <<< "Keep-Alive: timeout=15,max=100\r\n"
[06:04:27][D][uart_debug:158]: <<< "\r\n"
[06:04:27][D][uart_debug:158]: <<< "{\"Success\":\"0\"}\r\n"
[06:04:27][D][uart_debug:158]: <<< "OK\r\n" <span class="notranslate">
Usługa EnergySmartBridge wysyła kilka komunikatów MQTT raportujących stan sterownika nagrzewnicy. Ładne, ale bardzo ograniczone. Ten facet (https://github.com/starsoccer/energysmartbridge) rozszerzył most i ujednolicił go z odwrotnym proxy. Nie mogłem sprawić, by jego odwrotne proxy działało, więc wziąłem jego kod źródłowy tylko dla mostu (https://github.com/starsoccer/energysmartbridge/tree/master/energysmartbridge/src) i skopiowałem go do EnergySmartBridge/EnergySmartBridge, który został utworzony zgodnie z instrukcjami tutaj https://github.com/excaliburpartners/EnergySmartBridge . Zatrzymaj wszystkie kontenery utworzone przez EnergySmartBridge, usuń ich obrazy, powtórz procedury budowania i uruchamiania (nie zapomnij zaktualizować EnergySmartBridge.ini). Teraz obserwuj logi UART. Po nawiązaniu połączenia w eksploratorze MQTT powinny pojawić się nowe tematy, w szczególności "homeassistant/water_heater/C47F5101D65F/config", w którym można ustawić konfigurację. Przede wszystkim definiuje on "mode_command_topic": "energysmart/C47F5101D65F/mode_command", oraz "modes": ["eco", "heat_pump", "electric", "off"]. Możesz albo wysyłać rzeczy bezpośrednio do tego tematu przez mosquito, albo możesz utworzyć wpis klimatyczny w Home Assistant: (120C to w rzeczywistości 120F; kiedy ustawiam grzejnik na C, zachowuje się dziwnie - zbadam więcej)
Teraz możesz zmienić tryb! Należy pamiętać, że klucz sprzętowy łączy się z mostkiem tylko raz na 5 minut. Jeśli więc zmienisz tryb w Home Assistant, nie spiesz się do grzejnika, aby potwierdzić; poczekaj, aż logi UART pokażą kolejne udane połączenie. Teraz podłącz go do automatyki i gotowe! Teraz możesz odłączyć monitor UART.
Dla tych, którzy nie chcą bawić się kontenerami Docker i sieciami, istnieje alternatywny, bardziej hardware'owy sposób . Przeczytaj także sekcję komentarzy!
* Sam protokół to RS485, ale jest on dość bezużyteczny bez wiedzy o tym, jak dekodować dane. Klucz sprzętowy ma układ scalony do dekodowania.
** Pobawiłem się również konfiguracją routera, aby wymusić przekierowanie całego ruchu (zwłaszcza żądań do 8.8.8.8) z klucza sprzętowego na 192.168.0.1. Okazuje się, że nie jest to konieczne
Fajne? Ranking DIY
