Rozłączanie Home Assistant w ESPHome

Cześć mam problem z ESPHome i HomeAssistant
ESPHome zainstalowane na płytce Olimex ESP32-EVB do której mam podpięty moduł z 8 MCP23017

Założenie jest takie, że mam 64 wejścia i 64 wyjścia, gdy ilość we/wy w kodzie jest niska to wszystko działa fajnie, ale gdy do kodu dodam wszystkie we/wy to dzieją się takie rzeczy jak na logach poniżej:

[20:05:27][D][api.connection:159]: Home Assistant 2022.3.8 (::FFFF:C0A8:16F) requested disconnected
[20:05:27][D][api:102]: Accepted ::FFFF:C0A8:16F
[20:05:27][D][api.connection:827]: Home Assistant 2022.3.8 (::FFFF:C0A8:16F): Connected successfully
[20:05:32][D][api.connection:159]: Home Assistant 2022.3.8 (::FFFF:C0A8:16F) requested disconnected
[20:05:32][D][api:102]: Accepted ::FFFF:C0A8:16F
[20:05:32][D][api.connection:827]: Home Assistant 2022.3.8 (::FFFF:C0A8:16F): Connected successfully

Ja już zgłupiałem i nie znam rozwiązania tego problemu

Przykładowy kod (w sumie powielony po 64 razy + konfiguracja rolet):

switch:
  - platform: gpio
    name: "Kuchnia"
    id: swiatlo_kuchnia
    pin:
      mcp23xxx: mcp23017_wyjscia_0_15
      number: 0
      mode: OUTPUT
      inverted: false

binary_sensor:
  - platform: gpio
    name: "MCP23017 Pin #64"
    pin:
      mcp23xxx: mcp23017_wejscia_64_79
      number: 0
      mode: INPUT_PULLUP
      inverted: true
    on_press:
      then:
      - switch.toggle: swiatlo_kuchnia

Widziałem to już. Ale ja jestem podpięty po kablu, a nie po WiFI. Gdy się przepiąłem na WiFi i zrobiłem wszystko z wskazówkami z GH to było dokładnie to samo.

Tu nie chodzi o medium tylko o historię konfiguracji modułu w samym HA. Nie jest powiedziane co dokładnie powoduje przerwania w połączeniu do API.
Możesz jeszcze sprobować przejść na komunikację po MQTT.

W loga HA jest coś takiego:
Wątek z GH przejrzałem i nic nie znalazłem. Podpinałem sieć do płytki na różne sposoby (różne switche itp.), ale to nic nie dało Możliwe, że ESP nie ogarnia sieciowo tylu we/wy?

Logger: homeassistant.components.esphome
Source: components/esphome/__init__.py:290
Integration: ESPHome (documentation, issues)
First occurred: 11:49:50 (580 occurrences)
Last logged: 12:46:32

Error getting initial data for 192.168.1.241: Timeout waiting for response for <class 'api_pb2.ListEntitiesRequest'>

Kolejne co zauważyłem, to jak integracja nie jest dodana do HA to w logach ESPHome nie ma błędów.

Mam dokładnie ten sam problem, moduł Olimex ESP32 + ekspander 8xMCP23017 (od EasySwitch), wpięte po Ethernecie. Po restarcie ESP32 ciągła pętla Connected i Disconnected.

Sprawdziłem na 100% że ten disconnection inicjuje HA nie ESP (zmodyfikowałem bibloteki po stronie ESPHome). Podejrzewam, że przy połączeniu native po stronie Home Assistance jest timeout na odebranie z modułu ESP listy wszystkich encji. W przypadku gdy ta lista jest długa to ESP się “nie wyrabia” by całą długą listę przesłać do HA. HA uznaje zatem, że skoro nie dostał listy encji, to połączenie się nie udało i rozłącza połączenie z ESP. Potem ponowne połączenie, znowu ESP próbuje wysłać listę encji, ale za długo to trwa, więc HA rozłącza połączenie i tak w kółko.

Jestem już mocno zdeterminowany, próbowałem już prawie wszystkiego, a na forach lipa, bo zwykle tylko jedna rada: popraw sygnał wifi. Mam jeszcze jeden ostateczny test do zrobienia, czyli spróbować przejść na inny moduł ESP ( kupiłem u chińczyka WT32-ETH01 ) i sprawdzić czy to nie jest przypadkiem wina Olimexa.

Jak to nie pomoże, to niestety pozostaje tylko przepisać cały kod i przejść na komunikację MQTT.

Jest jeszcze oprogramowanie Tasmota, na ESPHome świat open source się nie kończy.
Tasmota śmiga po MQTT z HA. Nie doktoryzowałem się z obsługi expanderów pod Tasmota ale jest prawie wszystko w dokumentacji:

@welpl @NotteNick
Niezależnie od tego jak podejdziecie do rozwiązania problemu sugeruję założyć issue zarówno w projekcie ESPHome jak i HA, jeśli problem dotyczy timeoutów, to musi być rozwiązywalny (być może przez usunięcie błędów po stronie integracji lub w samym ESPHome).

1 polubienie

Czy udało się rozwiązać ten problem. W Tasmota jest ograniczenie do jednego MCP23017 i tak zastanawiałem się czy ESPHome daje radę z kilkoma modułami MCP23017. Problemem może być szybkość komunikacji po I2C ponieważ płytki trzeba odpytywać często jeżeli mają być rejestrowane zdarzenia na wejściach.

Tak, któraś z aktualizacji ESPHome lub Home Assistant sprzed kilku miesięcy naprawiła całkowicie ten problem. Teraz działa super na natywnej komunikacji HA-<->ESP.

Mam u siebie do pierwszej szyny I2C w moim ESP32 podpięte 8 expanderów i do drugiej szyny kolejne 4 expandery. W sumie moje ESP32 obsługuje obecnie prawie 200 wejść i wyjść ( 8x16 + 4x16).

Mam w planach jeszcze rozszerzyć o 4 dodatkowe moduły MCP23017 i dojść do maksymalnych 256 wejść/wyjść ale póki co MCP23017 są jeszcze słabo dostępne i drogie.

Nie wiem jak Tasmota, ale ESPHome nie ma najmniejszego problemu z wieloma expanderami. Tak wygląda fragment mojej konfiguracji:

i2c:
  - id: bus_a
    sda: 13
    scl: 16
    scan: False
    frequency: 800kHz
  - id: bus_b
    sda: 33
    scl: 32
    scan: False
    frequency: 800kHz
mcp23017:
  - id: "mcp23xxx_0x20"
    address: 0x20
    i2c_id: bus_a
  - id: "mcp23xxx_0x21"
    address: 0x21
    i2c_id: bus_a
  - id: "mcp23xxx_0x22"
    address: 0x22
    i2c_id: bus_a
  - id: "mcp23xxx_0x23"
    address: 0x23
    i2c_id: bus_a
  - id: "mcp23xxx_0x24"
    address: 0x24
    i2c_id: bus_a
  - id: "mcp23xxx_0x25"
    address: 0x25
    i2c_id: bus_a
  - id: "mcp23xxx_0x26"
    address: 0x26
    i2c_id: bus_a
  - id: "mcp23xxx_0x27"
    address: 0x27
    i2c_id: bus_a
  - id: "waveshare_0x27"
    address: 0x27
    i2c_id: bus_b
  - id: "waveshare_0x26"
    address: 0x26
    i2c_id: bus_b
  - id: "waveshare_0x25"
    address: 0x25
    i2c_id: bus_b
  - id: "waveshare_0x24"
    address: 0x24
    i2c_id: bus_b
2 polubienia

Proponuje jednak podzielić to między kilka modułów ESP aby w awarii jednego z nich przynajmniej część domu działała :wink:.

Na taką okoliczność posiadam drugi identyczny ESP schowany w szafce. W razie awarii, wgrywam aktualną konfigurację ( lub działam na wstępnie już wgranym sofcie ale w starszej wersji) i podmieniam moduł ESP w rozdzielni.

Jeden moduł łatwiej utrzymywać i zarządzać jego konfiguracją. Poza tym jeżeli wszystkie urządzania (oświetlenie, przekaźniki, styczniki, przyciski, czujki ) są wpięte w jedno ESP i zarządzane jedną konfiguracją, to cały system jest bardziej autonomiczny ( komunikacja nie przechodzi przez Home Assistant ) tylko działa w ramach jednego układu. Pozwala mi to na wyłączenie Home Assistant, a i tak oświetlenie będzie działało. Sygnał naciśnięcia przycisku idzie do ESP i z tego samego ESP idzie sygnał na przekaźnik załączający oświetlenie. Home Assistant jest tutaj tylko dodatkiem.

Gdyby infrastruktura była rozproszona ( wiele różnych ESP ) to komunikacja między nimi MUSI iść przez HA. I tak wciśniecie przycisku włącznika oświetlenia (wejście w pierwszym ESP ) gdzie przekaźnik przykładowo były na wyjściu w drugim ESP, to komunikacja musiałby być następując ESP 1 → HA → ESP 2. Gdy Home Assistant zostanie wyłączony, to światło się wtedy nie włączy.

Resumując, moim zdaniem rozproszenie systemu na kilka układów ESP raczej obniża niezawodność niż je podwyższa.

EDIT: Dobra, nie musi iść przez HA, komunikacja między ESP może odbywać się także poprzez MQTT, ale to niewiele zmienia, to taki sam wymóg sprawnego działania pośrednika.

Próbowałeś?
Nie?
To spróbuj.

Drugi “identyczny” moduł ma inny MAC-adress, więc nie do końca jest taki identyczny jak można by sądzić, jak na razie tylko standard Z-wave dysponuje sensownie działająca procedurą wymiany uszkodzonego urządzenia na nowe (ale z punktu widzenia HA i tak jest bezużyteczna, bo nie jest zaimplementowana w Z-waveJS).

Oczywiście to tylko kwestia integracji z HA, bo wszystko co sobie ogarniesz lokalnie wewnątrz ESP po podmianie (i flashowaniu) będzie działać.

Po prostu umieść obwód sterujący i obwód wykonawczy na tym samym ESP, natomiast zrób sobie podział chaty na niezależne strefy funkcjonalne (wtedy w razie awarii masz tylko cześć chaty w obszarze awarii).

Masz rację, tak nie powinno projektować się systemów. Ale wg mnie lepiej mieć dwa ESP, każdy po 64 in/out niż jeden ESP z 128 in/out, to taki tylko przykład obrazujący sytuację.

P.S. Nie tylko sam moduł ESP może ulec awarii, moduły od EasySwitch też mogą ulec awarii a awarie zdażają się w najmniej oczekiwanych sytuacjach, najgorzej jak się jest w delegacji :wink:, wtedy rodzina siedzi przy świeczkach.

Czyli zbudowałeś sobie coś podobnego do Boneio i tylko bardzo duża ilość in/out a tym samym rozmiar urządzenia powstrzymuje mnie przed jego kupnem :frowning:. Po za tym uważam, że to super rozwiązanie, podobnie jak Twoje.

No to pięknie. Właśnie takiego rozwiązania od długiego czasu szukałem. Zaczynałem od Arduino, które na połączeniu przez ethernet co jakiś czas (kilka miesięcy, pół roku) potrafiło stracić komunikację do serwera MQTT. Drugi problem z Arduino to konieczność wymontowaniu płytki żeby wgrać nową konfigurację np. dodanie nowego przycisku. Następnie zrobiłem przegląd układów pod Micropython’a, tam można już zdalnie zmieniać konfigurację jednak dalej trzeba “rzeźbić” kod. Ostatnio wpadła mi w ręce Tasmota i już byłem w ogródku i witałem się z gąską gdy okazało się , że można podpiąć tylko jeden układ MCP23017. I tak trafiłem na ESPHome. Także super , że to działa . Teraz czeka mnie przesiadka na ESPHome co po wstępnych testach zapowiada się na prostą operację. Dzięki za informacje i przykłady konfiguracji to znacznie przyspiesza prace :slight_smile: .

Co do odtworzenia kopii zapasowej to ciekawy temat szczególnie przy rozbudowanej instalacji, warto to przetestować. Wstępnie wydaje się to proste. W HA jest cała konfiguracja zapisana , komunikacja HA->ESP przebiega po IP na porcie 6053 więc wystarczy w DHCP zmienić MAC ESP na nowy albo ręcznie przypisać IP wymienianej płytki ESP i wgrać dotychczasową konfigurację.
Tak więc można nawet na półce mieć taki układ ESP z wgraną już konfiguracją i ręcznie zdefiniowanym adresem IP. Wtedy taka podmiana powinna działać “od strzała”.

Nie wystarczy, bo to nie kwestia IP tylko MAC-adresu, więc będziesz musiał grzebać w rejestrach urządzeń i encji (nie twierdzę, że to awykonalne).
Ba ESPHome używa mDNS, więc nawet nie musisz mieć statycznych IP (czy przyspawanych do MAC-ów za pomocą ARP) jeśli tylko w sieci działa jak należy multicast i mDNS (ale nie zmienia to faktu identyfikacji urządzeń ESP po MAC-u w HA) a i tak HA rozpoznaje konkretny egzemplarz MCU (no chyba, że znasz metodę na skuteczne nadpisanie MACa).

No tak, poza ESP32 może ulec awarii sam układ MCP23017. Jeżeli wejścia są zabezpieczone jakąś separacją przez optotranzystory to właściwie ryzyko jest znikome. Jednak w przypadku wielu płytek MCP23017 warto mieć rozbite to na pojedyncze płytki, które w całości można podmienić albo układy zainstalowane na podstawkach. Tak żeby ich wymiana była błyskawiczna.
Tak się zastanawiam kiedy robiona jest konfiguracja wyjść MCP23017 przez ESPHome. Po podmianie trzeba by jeszcze wymusić ponowne skonfigurowanie portów nowego MCP23017. Adres I2C zostanie ten ten sam więc to jest ok.

O ile się nie mylę każdorazowo przy inicjalizacji (przy bootowaniu ESP).

Jeżeli w konfiguracji użyje się tych samych nazw wejść/wyjść co poprzednio to nawet jeżeli to będzie widziane jako nowe urządzenie to i tak będzie to wpływać na wartości encji, które do tej pory zostały zdefiniowane w HA. Id encji są definiowane na podstawie “name” z YAML ESPHome.
To zdaje się, że działa coś na wzór MQTT, gdzie temat będzie odpowiednikiem encji. Dopóki reguły automatyzacji będą się odnosić do encji a nie do “devices” to wydaje się, że taka podmiana powinna być możliwa.

Po prostu sprawdź podmieniając sprzęt na zapasowy, tak będzie najprościej.
Albo zajrzyj do rejestrów urządzeń/encji i przejrzyj jak faktycznie się to odbywa.