Relacje katalogowe

Obsługiwane urządzenia

ESPHome jest otwartą platformą do budowania firmware urządzeń opartych między innymi na ESP32 i ESP8266. Konfigurację urządzenia zapisuje się w YAML, a narzędzia ESPHome generują z niej kod C++, kompilują firmware i programują mikrokontroler przez USB albo OTA. Urządzenie może następnie udostępniać encje bezpośrednio do Home Assistant przez szyfrowany ESPHome native API.

W katalogu bioreaktorów platforma ma potwierdzone zastosowanie w społecznościowym moście dla Brewtools FCS. Projekt lovekull76/brewtools-can-esphome łączy magistralę CAN urządzeń Brewtools z Home Assistant za pomocą ESP32-C3. Nie zastępuje firmware fabrycznych sensorów i mieszadła: tłumaczy ich ramki CAN na encje ESPHome i wysyła polecenia z Home Assistant z powrotem na magistralę.

Najważniejsze dane

Pole Wartość
Producent i opiekun projektu Open Home Foundation / projekt ESPHome
Typ generator firmware, narzędzia kompilacji, Device Builder i protokół native API
Bieżące wydanie sprawdzone dla tej karty ESPHome 2026.8.2, opublikowane 31 sierpnia 2026 r.
Wersja widoczna na zrzucie działającego mostka ESPHome 2026.5.3, kompilacja z 10 czerwca 2026 r.
Snapshot projektu Brewtools gałąź main, commit d6a7f35857a6 z 25 sierpnia 2026 r.
Autorski identyfikator firmware mostka 2026-06-21-sg-raw; jest to build_tag projektu, a nie wersja ESPHome
Mikrokontroler mostka Waveshare ESP32-C3-Zero
Framework ESP-IDF; płytka esp32-c3-devkitm-1, wariant esp32c3
Interfejs procesu CAN/TWAI, 1 Mbit/s, rozszerzone identyfikatory 29-bitowe
Transceiver Waveshare SN65HVD230, 3,3 V, terminacja 120 Ω na module
Integracja nadrzędna Home Assistant przez ESPHome native API
Native API własny protokół TCP z Protocol Buffers, domyślnie 6053/TCP; w projekcie szyfrowany Noise
Aktualizacja urządzenia pierwsze programowanie przez USB, kolejne przez ESPHome OTA, domyślnie 3232/TCP dla ESP32
Konfiguracja brewtools-can.yaml i lokalny secrets.yaml
Licencje runtime C/C++ ESPHome: GPLv3; Python i pozostały kod ESPHome: MIT; most Brewtools: MIT
Opłata licencyjna / dongle bez opłaty licencyjnej i bez sprzętowego klucza uprawnień
Relacja w katalogu Brewtools FCS, poprzez niezależny projekt społecznościowy
Identyfikatory bezpieczeństwa opisane w karcie GHSA-f5mx-f697-fcp9; CVE-2026-23833; CVE-2025-57808; CVE-2024-27081; CVE-2024-29019; CVE-2024-27287; CVE-2021-41104; CVE-2026-71259; CVE-2026-71260

Cztery różne identyfikatory wersji

W tym wdrożeniu występują cztery niezależne numery lub identyfikatory. Nie należy ich sprowadzać do jednego pola „wersja firmware”.

Identyfikator Co oznacza
2026.8.2 bieżące oficjalne wydanie narzędzi i komponentów ESPHome użyte jako punkt odniesienia tej karty
2026.5.3 wersja ESPHome, na której skompilowano urządzenie widoczne na zrzucie Home Assistant
2026-06-21-sg-raw tekst nadany przez autora mostka i wystawiany jako sensor „Firmware build”
d6a7f35857a6 commit snapshotu kodu i konfiguracji mostka analizowanego w tej karcie

ESPHome stosuje numerację kalendarzową ROK.MIESIĄC.PATCH. Numer platformy określa wersje generatora, komponentów i bibliotek użytych do kompilacji. Wgrany plik binarny zachowuje kod z momentu budowania; sama aktualizacja Device Buildera albo pakietu Python na hoście nie aktualizuje urządzenia. Po zmianie platformy YAML musi zostać ponownie zweryfikowany, skompilowany i bezpiecznie wgrany do węzła.

Architektura platformy

Warstwa Rola w rozwiązaniu
pliki YAML deklarują płytkę, komponenty, sensory, akcje, sekrety i parametry kompilacji
host kompilujący uruchamia ESPHome, generuje C++ i buduje firmware przez PlatformIO/toolchain
ESPHome Device Builder osobna aplikacja webowa do zarządzania konfiguracjami, kompilacją, logami i aktualizacją urządzeń
firmware ESP32-C3 wykonuje logikę CAN, utrzymuje Wi-Fi, native API, OTA i encje Home Assistant
Home Assistant wykrywa węzeł przez integrację ESPHome, pokazuje sensory i wysyła działania
magistrala Brewtools 24 V oraz CAN 1 Mbit/s łączące sensor gęstości i mieszadło z mostkiem

Od wydania 2026.6 dawny dashboard wbudowany w polecenie CLI został wydzielony do ESPHome Device Builder 1.0. Bieżące CLI służy między innymi do walidacji, kompilacji, programowania i odczytu logów, natomiast interfejs przeglądarkowy jest oddzielnym pakietem oraz oddzielną granicą sieciową.

Typowe polecenia lokalne to:

esphome config brewtools-can.yaml
esphome run brewtools-can.yaml
esphome logs brewtools-can.yaml
esphome clean brewtools-can.yaml

Device Builder domyślnie nasłuchuje na porcie 6052/TCP. Oficjalny obraz kontenerowy montuje katalog konfiguracji jako /config; sieć hosta jest stosowana tam, gdzie potrzebne jest wykrywanie mDNS. Panel kompilujący powinien być traktowany jak narzędzie administracyjne, ponieważ konfiguracja ESPHome może wykonywać własny kod C++ i ładować komponenty zewnętrzne podczas budowania.

Konfiguracja Brewtools w YAML

Most używa ESP32-C3 z frameworkiem ESP-IDF. Najważniejsze ustawienia sprzętowe wynikające z brewtools-can.yaml to:

Ustawienie Wartość
board esp32-c3-devkitm-1
variant esp32c3
framework.type esp-idf
CAN TX GPIO21
CAN RX GPIO20
CAN bitrate 1Mbps
logger USB_SERIAL_JTAG
dioda statusu pokładowa WS2812 na GPIO10, kolejność RGB

GPIO18 i GPIO19 są pozostawione dla natywnego USB ESP32-C3. Logi trafiają przez USB Serial/JTAG, dzięki czemu diagnostyka przewodowa nie współdzieli linii z transceiverem CAN.

Konfiguracja korzysta z gotowych komponentów ESPHome oraz lambd C++ umieszczonych bezpośrednio w YAML. Snapshot nie zawiera osobnego własnego komponentu C++ ani paczki external_components. Dekodowanie i składanie ramek Brewtools odbywa się w lambdach rejestrujących odbiór CAN oraz akcje encji.

Sekrety, klucz API i hasło OTA

Repozytorium zawiera szablon secrets.yaml.example z pięcioma nazwami:

Nazwa sekretu Zastosowanie
wifi_ssid nazwa docelowej sieci Wi-Fi
wifi_password hasło docelowej sieci Wi-Fi
fallback_ap_password hasło awaryjnego punktu dostępowego urządzenia
bt_api_encryption_key klucz szyfrowania ESPHome native API
bt_ota_password hasło aktualizacji OTA

Konfiguracja odwołuje się do nich składnią !secret, między innymi:

api:
  encryption:
    key: !secret bt_api_encryption_key

ota:
  - platform: esphome
    password: !secret bt_ota_password

Wartości tworzy operator wdrożenia w lokalnym secrets.yaml. Nie są to fabryczne dane logowania produktu Brewtools. Dla filtra katalogowego konfiguracja jest oznaczona jako „klucz w secrets.yaml”, ponieważ uruchomienie native API wymaga rzeczywistego klucza zapisanego pod nazwą bt_api_encryption_key.

Klucz native API ma postać 32 bajtów zakodowanych Base64. Powinien być unikatowy dla urządzenia. Hasło OTA jest odrębnym sekretem; przejęcie jednego nie powinno automatycznie otwierać drugiego kanału administracyjnego. Pliku secrets.yaml, katalogu Device Buildera, kopii zapasowych konfiguracji ani logów kompilacji nie należy publikować razem z repozytorium projektu.

Sprzęt referencyjnego mostka

Autor projektu zbudował węzeł z powszechnie dostępnych modułów:

  • Waveshare ESP32-C3-Zero;
  • transceiver Waveshare SN65HVD230 z zasilaniem 3,3 V i terminacją 120 Ω;
  • przetwornica 24 V → 5 V, pokazana na przykładzie modułu LM2596;
  • drugi rezystor terminujący 120 Ω na przeciwległym końcu magistrali;
  • złącze LP12 do zasilania i CAN urządzeń Brewtools.

Przy wyłączonym zasilaniu poprawnie zakończona magistrala ma około 60 Ω pomiędzy CAN H i CAN L, ponieważ dwa rezystory 120 Ω pracują równolegle.

Pin LP12 Kolor Sygnał
1 czerwony +24 V
2 żółty CAN H
3 biały CAN L
4 zielony NC w tej konfiguracji
5 czarny GND

Most może pracować bez Display Module FCS podczas normalnego odczytu i sterowania obsługiwanymi węzłami. Fabryczny moduł FCS pozostaje potrzebny do aktualizacji firmware urządzeń CAN Brewtools. Jest to istotny podział: OTA ESPHome aktualizuje wyłącznie firmware ESP32-C3, a nie sensor gęstości ani mieszadło na magistrali.

Identyfikator i format ramek CAN

Brewtools używa rozszerzonych, 29-bitowych identyfikatorów. Projekt składa identyfikator według wzoru:

(priority << 27) |
(senderNodeType << 19) |
(receiverNodeType << 11) |
(secondaryNodeId << 8) |
messageType
Pole Liczba bitów Znaczenie
priority 2 priorytet ramki
sender node type 8 typ nadawcy
receiver node type 8 typ odbiorcy
secondary node ID 3 egzemplarz danego typu węzła
message type 8 typ pomiaru lub polecenia

W analizowanym kodzie występują typy węzłów: kontroler/PLC 8, sensor gęstości 4 oraz mieszadło 6.

Obsługiwane pomiary i polecenia

Message type Dane Interpretacja w mostku
12 float, little-endian temperatura brzeczki w °C
14 float, little-endian skalibrowana gęstość właściwa SG
15 float, little-endian surowe SG, skalowane przez podział przez 1000
17 uint32, big-endian prędkość mieszadła w rpm
27 wartość sterująca zadanie PWM mieszadła
28 polecenie rozpoczęcie kalibracji gęstości
29 odpowiedź potwierdzenie/status kalibracji
33 polecenie rozpoczęcie pomiaru gęstości

Most wysyła zadanie PWM mieszadła z identyfikatorem 0x40301B, polecenie startu pomiaru gęstości z 0x402021, a kalibrację z 0x40201C. Najnowszy commit snapshotu dodał osobny sensor surowej, nieskalibrowanej wartości SG i wygładzanie wartości skalibrowanej.

Kod projektu obejmuje sensor gęstości/temperatury i mieszadło. Dokumentacja Brewtools opisuje również sensor ciśnienia, radar poziomu i FCS I/O, lecz analizowany snapshot nie tworzy dla nich encji ani dekoderów. Ta granica zapobiega przypisaniu mostkowi funkcji istniejących tylko w protokole producenta.

Encje Home Assistant

Integracja używa native API, a nie MQTT. Po połączeniu z Home Assistant węzeł udostępnia encje sterujące, pomiarowe i diagnostyczne.

Grupa Encje widoczne w konfiguracji
mieszadło przełącznik, nastawa PWM, odczyt rpm
gęstość start pomiaru, skalibrowane SG, surowe SG, punkt odniesienia i polecenie kalibracji
temperatura temperatura brzeczki
diagnostyka uptime, Wi-Fi RSSI, wewnętrzna temperatura ESP, licznik ramek CAN, build firmware, wersja ESPHome i status

Sterowanie i sensory mostka Brewtools CAN w Home Assistant

Źródło: repozytorium lovekull76/brewtools-can-esphome, images/hass.jpeg. Ekran pokazuje sterowanie mieszadłem, kalibrację i rozpoczęcie pomiaru oraz odczyty rpm, SG i temperatury.

Stan włączenia mieszadła i nastawa PWM są przechowywane w pamięci flash. Po zmianie kod opóźnia zapis o 1,5 sekundy i wywołuje synchronizację preferencji, ograniczając serię zapisów przy przesuwaniu wartości. Podczas startu czeka pięć sekund i ponownie wysyła zapamiętane PWM, jeżeli mieszadło było włączone. To zachowanie trzeba uwzględnić przy analizie nieoczekiwanego ruchu po zaniku zasilania.

Kalibracja gęstości jest jednopunktowa. Konfiguracja utrwala wartość odniesienia oraz czas kalibracji, wysyła polecenie do węzła i interpretuje odpowiedź typu 29. Zachowanie procesu zależy więc równocześnie od stanu sensora Brewtools, wartości utrwalonej w ESP32 i encji widocznej w Home Assistant.

Diagnostyka i identyfikacja buildu

Diagnostyka działającego mostka Brewtools CAN

Źródło: repozytorium lovekull76/brewtools-can-esphome, images/hass_2.jpeg. Widoczna kompilacja używa ESPHome 2026.5.3, ma build 2026-06-10-cal-latch, 161 944 odebrane ramki CAN, status Connected, uptime 12 092 s i RSSI −70 dBm.

Pokładowa dioda WS2812 przekazuje uproszczony stan bez otwierania panelu:

Kolor Stan
czerwony brak połączenia Wi-Fi
niebieski Wi-Fi działa, native API Home Assistant nie jest połączone
zielony native API jest połączone

Licznik ramek CAN pozwala odróżnić utratę komunikacji magistrali od problemu prezentacji encji. Wartość RSSI pomaga powiązać przerwy native API z warunkami radiowymi. Sensor wersji ESPHome zwraca również hash konfiguracji i czas kompilacji, co jest mocniejszym identyfikatorem niż ręcznie ustawiany build_tag.

Native API

ESPHome native API jest własnym protokołem działającym po TCP i wykorzystującym Protocol Buffers. Domyślny port urządzenia to 6053/TCP. Integracja Home Assistant utrzymuje połączenie do urządzenia, subskrybuje stany i wysyła wywołania usług/akcji.

W projekcie Brewtools blok api.encryption włącza szyfrowanie Noise. Klucz z secrets.yaml jest wymagany po obu stronach. Segmentacja Wi-Fi nadal ma znaczenie: szyfrowanie chroni treść i uwierzytelnia klienta posiadającego klucz, ale dostępność urządzenia zależy od stosu sieciowego, poprawności dekodera protokołu i ochrony samego sekretu.

Węzeł jest automatycznie wykrywany przez Home Assistant. Projekt nie konfiguruje MQTT, własnego brokera ani tematów telemetrycznych. Zapowiedzi MQTT dotyczące innych produktów Brewtools nie są dowodem, że ten społecznościowy most używa MQTT.

Pierwsze programowanie, OTA i porty

Pierwsze programowanie ESP32-C3 odbywa się przez USB. Jest to również moment, w którym można zaktualizować bootloader. Późniejsze aktualizacje projektu mogą korzystać z komponentu ota platformy ESPHome.

Usługa Domyślny port Zastosowanie w tym rozwiązaniu
ESPHome native API 6053/TCP encje, stany, polecenia i logi przez integrację
ESPHome OTA na ESP32 3232/TCP wgrywanie nowego firmware po uwierzytelnieniu hasłem
ESPHome Device Builder 6052/TCP panel hosta kompilującego; nie jest usługą firmware mostka
mDNS 5353/UDP wykrywanie nazw i urządzeń w sieci lokalnej

Hasło OTA jest używane w mechanizmie challenge-response i nie jest przesyłane wprost. OTA automatycznie włącza safe mode. Dla ESP32 obsługa rollback jest domyślnie aktywna, jeśli pozwala na to bootloader i układ partycji.

Wydanie 2026.8.2 obsługuje również weryfikację podpisanych obrazów OTA, ale snapshot Brewtools nie konfiguruje signed_ota_verification. Ochrona tej konkretnej konfiguracji opiera się na haśle OTA, izolacji sieci i kontroli hosta budującego. Dodanie podpisu wymaga świadomego zarządzania kluczem oraz zgodnej konfiguracji partycji i bootloadera.

Safe mode i rollback

Domyślna logika safe mode uznaje firmware za działające po minucie poprawnego startu. Po dziesięciu nieudanych uruchomieniach urządzenie przechodzi w tryb awaryjny, a domyślny timeout ponownego restartu wynosi pięć minut. Na ESP32 licznik i stan są utrzymywane we flash.

Rollback umożliwia powrót do poprzedniej partycji, gdy nowy obraz nie potwierdzi udanego startu. OTA nie aktualizuje bootloadera, dlatego urządzenie z dawnym bootloaderem może wymagać ponownego programowania przez USB przed skorzystaniem z nowszych mechanizmów. Od ESPHome 2026.8 uporządkowane zamknięcie może domyślnie oznaczyć firmware jako poprawne, co ogranicza fałszywy rollback przy planowanym restarcie.

Projekt mostka zaleca odczekanie około 60 sekund po OTA. Jest to spójne z domyślnym czasem potwierdzenia udanego startu. Weryfikacja wdrożenia powinna objąć powrót encji, wzrost licznika ramek CAN, status native API oraz zachowanie mieszadła odtwarzającego zapisany stan.

Wi-Fi, fallback AP i captive portal

Konfiguracja podstawowej sieci pobiera SSID i hasło z secrets.yaml. Blok wifi.ap definiuje awaryjny punkt dostępowy chroniony osobnym fallback_ap_password, a captive_portal pozwala uzupełnić ustawienia sieciowe przez przeglądarkę.

Firmware mostka nie włącza komponentu web_server; portal awaryjny nie jest stałym panelem sterowania procesem. Ekspozycja portalu zależy od stanu połączenia Wi-Fi. Jego hasło powinno być niezależne od hasła sieci głównej i hasła OTA.

Urządzenie przetwarza trzy rodzaje tajemnic o różnych skutkach przejęcia:

  1. hasło Wi-Fi daje dostęp do sieci, w której pracuje węzeł;
  2. klucz native API pozwala klientowi zestawić szyfrowane połączenie sterujące;
  3. hasło OTA pozwala próbować wgrać nowy obraz firmware.

Do tego dochodzi hasło fallback AP, używane podczas odzyskiwania łączności. Każdy sekret powinien mieć osobną wartość, ewidencję właściciela i procedurę rotacji po skopiowaniu konfiguracji lub przejęciu hosta kompilującego.

Licencjonowanie i koszt

Repozytorium ESPHome rozdziela licencje według warstwy. Kod runtime w C/C++ trafiający do firmware jest udostępniany na GPLv3, natomiast kod Python i pozostałe pliki projektu są objęte MIT. Repozytorium brewtools-can-esphome ma licencję MIT.

ESPHome nie wymaga płatnej licencji stanowiskowej, subskrypcji ani dongla USB. Koszt wdrożenia obejmuje sprzęt: ESP32-C3-Zero, transceiver CAN, przetwornicę, obudowę, przewody i host Home Assistant/Device Builder. Sprzętowym nośnikiem tożsamości nie jest dongle licencyjny; klucze API i hasła są elementami konfiguracji firmware oraz hosta.

Bezpieczeństwo hosta kompilującego

Model zagrożeń ESPHome traktuje autora konfiguracji YAML jak zaufanego użytkownika mającego możliwość wykonywania kodu na hoście budującym. Lambdy w konfiguracji stają się C++, a komponenty zewnętrzne mogą dostarczać kod Python wykonywany podczas walidacji i generowania oraz kod C++ w firmware. Nie są uruchamiane w izolowanej piaskownicy.

Ma to praktyczne konsekwencje:

  • pull request do konfiguracji jest zmianą kodu, nie tylko zmianą danych;
  • źródło external_components powinno być przypięte do zweryfikowanego commitu;
  • Device Builder powinien działać na wydzielonym hoście lub w odpowiednio ograniczonym kontenerze;
  • tokeny repozytoriów, klucze podpisu i secrets.yaml nie powinny być dostępne procesom niezwiązanym z kompilacją;
  • wygenerowane pliki binarne należy hashować i wiązać z commitem konfiguracji oraz wersją ESPHome.

Projekt Brewtools analizowany w tej karcie nie pobiera zewnętrznego komponentu: używa komponentów dystrybucji ESPHome i lambd zawartych w jednym YAML. Nadal wymaga audytu zmian YAML, ponieważ lambdy sterują ramkami wysyłanymi do urządzeń fizycznych.

Podatności i advisories ESPHome

Poniższa tabela rozdziela podatności firmware urządzenia, dawnego dashboardu i hosta budującego. Sam numer CVE bez komponentu i zakresu wersji nie opisuje ekspozycji mostka.

Identyfikator Komponent i skutek Wersje / naprawa Znaczenie dla mostka Brewtools
GHSA-f5mx-f697-fcp9 XSS w captive portal przez złośliwą nazwę SSID; możliwa kradzież danych Wi-Fi podczas konfiguracji starsze niż 2026.7.3; poprawka 2026.7.3 most używa captive_portal; wersja działającego firmware ma bezpośrednie znaczenie
CVE-2026-23833 / GHSA-4h3h-63v6-88qx integer overflow w dekoderze protobuf native API, prowadzący do crash/reboot 2025.9.0–2025.12.6; poprawka 2025.12.7 i 2026.1.0b3+ dotyczy portu 6053; szyfrowanie Noise wymaga znajomości klucza do wejścia w kanał
CVE-2025-57808 / GHSA-mxh2-ccgj-8635 obejście Basic Auth komponentu web_server na ESP-IDF dokładnie 2025.8.0; poprawka 2025.8.1 snapshot mostka nie włącza web_server
CVE-2024-27081 / GHSA-8p25-3q46-8q2p path traversal dawnego dashboardu, odczyt/zapis katalogu konfiguracji i możliwość RCE 2023.12.9; poprawka 2024.2.1 dotyczy hosta dashboardu, nie magistrali CAN ani native API urządzenia
CVE-2024-29019 / GHSA-5925-88xh-6h99 CSRF / obejście uwierzytelnienia dawnego dashboardu 2023.12.9; poprawka 2024.3.0 dotyczy administracyjnego hosta kompilującego
CVE-2024-27287 / GHSA-9p43-hj5j-96h5 stored XSS w dawnym dashboardzie od 2023.12.9 do 2024.2.1; poprawka 2024.2.2 dotyczy interfejsu przeglądarkowego hosta
CVE-2021-41104 / GHSA-48mj-p7x2-5jfm endpoint OTA w urządzeniowym web_server ignorował skonfigurowane Basic Auth do 2021.9.1; poprawka 2021.9.2 snapshot nie używa urządzeniowego web_server
CVE-2026-71259 walidator URL dla external_components dopuszczał ścieżkę file:, umożliwiając wykonanie kodu Python podczas config/run NVD opisuje wydania do 2026.7.0 zagrożenie hosta budującego i niezaufanej konfiguracji; snapshot nie używa external_components
CVE-2026-71260 JSON urządzeniowego web_server ujawniał wartość encji tekstowej pracującej w trybie hasła NVD opisuje wydania do 2026.7.0 snapshot nie konfiguruje web_server ani tekstowej encji hasła

Bieżące ESPHome 2026.8.2 znajduje się poza wymienionymi zakresami wersji. Zrzut mostka pokazuje jednak kompilację 2026.5.3, która poprzedza poprawkę captive portal 2026.7.3. Jeżeli ten konkretny build pozostaje wdrożony, powinien zostać przebudowany na poprawionym wydaniu i wgrany do ESP32-C3. Ocena musi bazować na sensorze wersji działającego urządzenia lub skrócie obrazu, a nie na wersji pakietu zainstalowanej obecnie na Device Builderze.

Granice zaufania w integracji Brewtools

Zmiana stanu fizycznego może przejść przez cały łańcuch:

operator → Home Assistant → native API/Noise → ESP32-C3 → CAN → mieszadło lub sensor

W przeciwnym kierunku telemetria przechodzi z urządzenia CAN przez własne dekodery lambd do encji Home Assistant. Weryfikacja integralności obejmuje zatem:

  • konto i automatyzacje Home Assistant;
  • klucz native API;
  • YAML, wersję ESPHome i toolchain hosta;
  • binarny obraz oraz partycje OTA ESP32-C3;
  • okablowanie, terminację i liczbę węzłów CAN;
  • identyfikatory node type / node ID;
  • firmware fabrycznych urządzeń Brewtools;
  • zapisane w flash stan mieszadła, PWM i dane kalibracyjne.

Status zielonej diody oznacza połączenie API, a nie poprawność wartości procesu. Rosnący licznik ramek potwierdza odbiór ruchu CAN, ale nie potwierdza właściwego node ID, jednostek lub kierunku sterowania. Test odbiorczy powinien korelować encję, ramkę, odpowiedź urządzenia i obserwowany skutek fizyczny.

Akwizycja i baseline

Dla działającego mostka warto utrwalić jednocześnie:

  1. pełny YAML i wszystkie dołączane pliki bez ujawniania sekretów w raporcie roboczym;
  2. osobną zabezpieczoną kopię secrets.yaml oraz identyfikatory kluczy użytych przez Home Assistant;
  3. commit projektu, wersję ESPHome, hash konfiguracji, czas kompilacji i hash pliku binarnego;
  4. wynik esphome config i log kompilacji z wersjami toolchainu;
  5. układ partycji, stan OTA/rollback i kopię obrazu flash możliwą do pozyskania sprzętowo;
  6. adres IP, MAC, nazwę mDNS, port 6053 i reguły segmentacji;
  7. wpis integracji ESPHome oraz automatyzacje Home Assistant wywołujące encje mostka;
  8. mapę przewodów LP12, terminację i zmierzoną rezystancję CAN H–CAN L;
  9. node ID, wersje firmware sensora oraz mieszadła;
  10. wartości utrwalone: stan mieszadła, PWM, referencyjne SG i czas kalibracji;
  11. próbkę ruchu CAN obejmującą stan spoczynkowy, start pomiaru, kalibrację i zmianę PWM;
  12. zdjęcia płytki, transceivera, przetwornicy, złączy i numerów rewizji.

Sekrety powinny trafić do wydzielonego zaszyfrowanego materiału dowodowego. W raporcie wystarczy identyfikator, hash i informacja o rotacji; publikacja wartości klucza rozszerza incydent na wszystkie kopie konfiguracji oraz klientów Home Assistant, które go przechowują.

Materiały i kod do pobrania

Materiał Zastosowanie Link
ESPHome 2026.8.2 oficjalne źródła wydania platformy release na GitHub
Instalacja ESPHome pakiet Python, Device Builder i obrazy Docker oficjalny przewodnik instalacji
ESPHome CLI walidacja, kompilacja, flash i logi oficjalna dokumentacja CLI
Native API protokół, port, szyfrowanie i konfiguracja połączenia komponent API
ESPHome OTA aktualizacja, uwierzytelnienie i porty platform komponent OTA
Safe mode progi startu, timeout i odzyskiwanie komponent safe mode
Brewtools CAN na innych platformach oficjalne pola identyfikatorów i typy komunikatów dokumentacja Brewtools
brewtools-can-esphome YAML, secrets.yaml.example, schemat połączeń, modele obudowy i zrzuty repozytorium projektu MIT
Advisories ESPHome aktualna historia ostrzeżeń bezpieczeństwa upstream GitHub Security Advisories

Powiązane urządzenia i oprogramowanie

Źródła