Esphome encja niedostępna

Home Assistant Integracje
1

Witajcie, jakiś czas temu przeszedłem z tasmoty na esphome nijako ze względu na podobno lepsza współpracę z HA.
Faktycznie programowanie itp jest łatwiejsze ale napotkałem dość duży problem.
Wszystkie urządzenia (esp32, wamos d1 czy H801) są w miejscach w których nie ma najmniejszego problemu z zasięgiem. Pomimo tego notorycznie encje mają status niedostępne.
Powoduje to problemy z działaniem choćby skryptu od pompy cwu która potrafi się włączyć i pracować wiele godzin zamiast kilku minut.

Jakieś pomysły?

Screenshot_2021-12-07-11-08-06-612_io.homeassistant.companion.android
Screenshot_2021-12-07-11-08-06-612_io.homeassistant.companion.android1080×2400 214 KB

2

Nie zamieściłeś kodu z ESPHome, więc trudno coś więcej powiedzieć.
Nie masz przypadkiem jednocześnie uruchomionej integracji api: i mqtt: w ESPHome?

4 
esphome:
  name: kotlownia_pc
  platform: ESP8266
  board: d1_mini

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:
  password: "xxxxxxx"

wifi:
  ssid: "xxxxxxx"
  password: "xxxxxxxxxx"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Fallback Hotspot"
    password: "xxxxxxx1RxV"

dallas:
  - pin: D4
    update_interval: 10s

switch:
  - platform: gpio
    name: "Pompa cyrkulacji"
    pin: D3
  
sensor:
  - platform: dallas
    address: 0x3601205048D11B28
    name: "CWU"
    
  - platform: dallas
    address: 0x9801205039D72028
    name: "Bufor powrót"
  - platform: dallas
    address: 0xE701204FE311AF28
    name: "CO zasilanie"
  - platform: dallas
    address: 0xF2012050581CB928
    name: "CO powrót"
  - platform: dallas
    address: 0xA60120502BCEFD28
    name: "Powrót"
  - platform: dallas
    address: 0x530120502832E528
    name: "Bufor zasilanie"
  - platform: dallas
    address: 0xC801205059EAE128
    name: "Cyrkulacja"
  - platform: dallas
    address: 0xFE0120502BE3C528
    name: "Zasilanie"
  - platform: wifi_signal
    name: "Kotlownia_PC"
    update_interval: 60s
    
status_led:
  pin:
    number: D0
    inverted: True

Tak wygląda kod w esp które jest najbardziej problematyczne

5

Możesz spróbować takiego triku - podobno ESPHome ma domyślnie zbyt wysoką moc WiFi i to powoduje niestabilność niektórych modułów, a jeśli nie ma problemu z zasięgiem to można ją swobodnie przyciąć (a dodatkowo wyłączam usypianie)

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_pass
  power_save_mode: none
  output_power: 17
6

Zrobiłem jak napisałeś. Teraz będę obserwować i dam znać jaki efekt.

7

Naprawdę aż tak często wymagany jest pomiar tych temperatur? W przypadku Tasmoty też tak często robiłeś update?

8

Niestety nie pomogło

Edit:
Tasmota sama co zmianę statusu odświeżała, a esphome neistety nie.

Problem dotyczy też esp32 gdzie nie ma wcale interwału przesyłania danych

@Jabol edytuj Swoje posty - nie pisz jednego pod drugim.

10

Odświeża zgodnie z interwałem czasowym, mam u siebie ESPHome na module Heltec “Wifi Kit 8” z dwoma takimi samymi czujnikami tempetatury i wszystko działa poprawnie. Zasięg Wi-Fi na pograniczu dostępności, jakieś -78dBm ale działa.

11

Odświeża zgodnie z interwałem, a ja bym chciał by sie odświeżał w momencie wystąpienia zmiany.

12

@Jabol na czym masz postawioną sieć WiFi?
Pytam, bo miałem podobny problem z modułami ESP32 rozłączającymi się od sieci WiFi, zaraz po przejściu z Mikrotika na UniFi AP 6.

13

Czy SSID sieci 2,4GHz był taki sam jak dla 5GHz?

14

Jedne łacza się do UNIFI UAP AC LITE inne do TP Linka C6.

15

A czy może to mieć znaczenie dla urządzenia które nie “słyszy” sieci 5GHz?
Problem, który wspominasz jest charakterystyczny dla zupełnie innych konfiguracji (i raczej nie podejrzewam, że ktoś ma HA podpięty do sieci przez WiFi 5GHz - bo to chyba jedyny scenariusz gdzie taki problem mógłby wystąpić).

Możesz dalej zmniejszać moc np. z 17dBm do 13dBm lub 10dBm.

Ale zdecydowanie lepszym posunięciem jest logowanie z poziomu ESP
w przypadku problemu z łącznością wypadałoby użyć portu szeregowego

ale na początek proponuję podejrzeć logi w trybie OTA

Generalnie w “pinologii” coś mi tu nie gra - status LED w D1 mini jest jeśli się nie mylę opięta do GPIO2 (czyli D4, a nie do D0), natomiast D4 (czyli GPIO2, swoją drogą jest to niezalecany pin do wykorzystania jako wejście) wykorzystujesz jako 1-wire dla Dallasów

16

Na początku miałem taki sam, później dwa różne na 2,4 i 5GHz, ale to nie miało znaczenia.

17

W Tasmota są do tego reguły. Poniżej link do przykładu z dokumentacji:

18

W ESPHome też można sobie zbudować reguły

Natomiast nie pamiętam jak się zachowują same Dallasy, a nie mogę tego sprawdzić “organoleptycznie”, bo ich obecnie już nie używam.

19

Niestety nie udało mi się rozwiązać problemu.
Przeszedłem na tasmote i problem zniknął

1 polubienie
20

No cóż szkoda, że nie szarpnąłeś się na logowanie, bo fajnie by było znać przyczynę problemu - być może pomogłoby to w ulepszeniu ESPHome (jeśli problem nie występuje w Tasmota, to albo jest błąd w ESPHome, albo były błędy w konfiguracji, które przeoczyliśmy).

21

Skoro przeszedłeś na Tasmotę, sprawdź proszę czy faktycznie odświeżanie jest co zmianę czy raczej na podstawie parametru TelePeriod - Commands - Tasmota?

23

Witam
Dziś wyłożył mi się wymos D1 mini na połączeniu z wifi. Pracował stabilnie 7 dni. Zasięgi wifi przyzwoite.( ok 50 dbi) Drugi wemos na takich samych parametrach działa równo.Korzystam z ESPHome i tak na razie zostaje. Czujnik to DS18B20 dołączony do D4 czyli GPIO2. Przeczytałem wątek i wprowadzę wszystkie proponowane zmiany - efektem się pochwalę
Zmienię czas odświeżania na 60 sek, przełożę czujnik na inny GPIO ( jakieś sugestie?), obniżę moc wifi.
Jednocześnie mam pytanie : jak rozwiązujecie korekcje odczytów z czujników temperatury?
Kilka czujników DS mam na Sonoof-ach w SUPLI i tam jest prosto ale ESPHome to dla mnie nowa zabawka.

Sprawa korekcji nie aktualna. Mr szopen dziękuje za mimowolne wskazanie drogi :grinning: