Płytki z ESPHome już dziś wymieniają się odczytami czujników przez packet_transport, po UDP albo po UART. Nowy komponent packet_interface dokłada pod nim jeszcze jeden poziom: wspólny sposób wysyłania pakietów przez łącze, a na nim warstwy, które ponawiają zgubione pakiety, sprawdzają, czy druga strona wciąż odpowiada, i szyfrują ruch. Autor, clydebarrow, podzielił pracę na serię zmian. Sam komponent z łączem UART trafił do kodu 23 października 2026, a łącze UDP i trzy warstwy dzień później. Wszystko jest w gałęzi rozwojowej, więc powinno trafić do ESPHome 2026.11.

Łącza

Łącze uart dzieli dane na ramki tak samo, jak robi to już platforma UART w packet_transport. Łącze udp wysyła każdy pakiet jako osobny datagram UDP na wszystkie adresy ustawione w komponencie udp.

Jedno z drugim spina nowa platforma packet_interface dla packet_transport. Dzięki niej dotychczasowa wymiana odczytów może działać przez dowolne łącze. Tak wygląda przykład z opisu zmiany dodającej szyfrowanie:

uart:
  tx_pin: GPIO17
  rx_pin: GPIO16
  baud_rate: 115200

packet_interface:
  - platform: uart
    id: serial_link
    encryption:
      key: Johnny Cash
      rolling_code_enable: true
    session:
      keep_alive: 10s
      binary_sensor:
        name: Link connected

packet_transport:
  - platform: packet_interface
    packet_interface: serial_link
    sensors:
      - temperature

Trzy warstwy

Warstwy ustawia się we wpisie łącza. ESPHome zawsze układa je w tej samej kolejności, niezależnie od tego, w jakiej je wpiszesz.

  • Niezawodność (reliability:) działa według protokołu HDLC i dostarcza pakiety między dwoma urządzeniami po kolei, bez strat i powtórzeń. Każdy pakiet rośnie o 3 bajty: bajt sterujący i sumę kontrolną CRC-16. Ramki są numerowane modulo 8, a na lukę w numeracji odbiorca odpowiada ramką REJ, więc nadawca od razu wysyła brakujące dane. Limit czasu wynosi co najmniej 50 ms (domyślnie 200 ms) i dostaje losowy dodatek do jednej czwartej, żeby dwa urządzenia, których ramki się zderzyły, nie nadawały ponownie w tej samej chwili. Dzięki opcji ack_delay jedno potwierdzenie może objąć kilka ramek. Według autora ma to znaczenie przy radiach, które nie potrafią jednocześnie nadawać i odbierać.
  • Sesja (session:) wysyła pakiety podtrzymujące i zgłasza, czy druga strona jest osiągalna, także do czujnika binarnego, jeśli go dodasz. Każdy taki pakiet niesie liczbę losowaną przy starcie, dzięki czemu restart drugiego urządzenia wychodzi na jaw, nawet gdy trwa krócej niż limit czasu. Odstęp keep_alive ustawia się w granicach od 1 s do 1 h, a domyślny limit czasu to trzy takie odstępy.
  • Szyfrowanie (encryption:) szyfruje i uwierzytelnia każdy pakiet algorytmem XXTEA z kluczem 256-bitowym, czyli skrótem SHA-256 wpisanego tekstu. Pakiet zmieniony po drodze albo zaszyfrowany innym kluczem zostaje odrzucony. Po włączeniu rolling_code_enable dochodzi numer uruchomienia zapisany w pamięci flash i licznik pakietów, więc odrzucane są też pakiety przechwycone i wysłane ponownie. Warstwa dokłada do pakietu od 4 do 8 bajtów, a z kodem kroczącym od 16 do 19.

Zanim użyjesz tego w sieci

W scalonym kodzie łącze UDP przyjmuje datagramy od każdego nadawcy. Kolejna zmiana ma sprawić, że gdy udp wysyła na jeden adres, łącze będzie przyjmować pakiety tylko od tego urządzenia. Do tego czasu w sieci współdzielonej z innymi urządzeniami trzeba według autora dodać warstwę szyfrowania albo adresowania. W opisie testów zaznaczono tylko ESP32 z ESP-IDF, a dokumentacja wciąż czeka na scalenie (esphome.io #7783).

Następne w kolejce są warstwy adresowania i dzielenia pakietów, komponent entity_transport oraz łącza TCP, ESP-NOW i LoRa.