Home Assistant Накопичення досвіду

[mib]

13 часов назад, Фрай сказал:

 

 

 

…………………………………………………………………………………………………………..……

 

Спасибоооо, еще один год добавлен в статистику

[TaurosRMK]

Останній тиждень контролер вентиляції на ESP32 протягом дня по 5-7 разів переходить в стан Недоступно и зразу повертається до нормальної роботи. Помітив це тому що там кожного разу спрацьовує автоматизація, яка надсилає сповіщення в телеграм про запуск вентиляції. Думав "одноразова акція", але ні, повторюється вже майже тиждень. Час спрацювання рандомний, при цьому робота вентиляції не переривається, все працює.

За цей тиждень НА і ESPHome оновлювалися декілька разів, і десь після цього з'явилася така болячка, бо до цього жодного разу такого не було, а працює контролер вже тривалий час. Не можу зрозуміти в чому проблема.

Згадав що ще з'явився спам від додатку НА на андроїд, також протягом дня часто шле сповіщення про оновлення датчиків. А таке сповіщення, якщо не помиляюся, з'являється коли пропадає мережа, хоча з цим проблем немає, постійно в локальній мережі.

Чи помічає хтось щось схоже?

Прихований текст

 

Змінено 21 вересня користувачем TaurosRMK

[volomoto]

10 годин тому, TaurosRMK сказав:

За цей тиждень НА і ESPHome оновлювалися декілька разів, і десь після цього з'явилася така болячка, бо до цього жодного разу такого не було, а працює контролер вже тривалий час. Не можу зрозуміти в чому проблема.

Зникає зв'язок між есп32 та ХА. Після оновлення ESPHome перекомпільовували прошивку для кінконі?

[TaurosRMK]

26 хвилин тому, volomoto сказав:

Зникає зв'язок між есп32 та ХА. Після оновлення ESPHome перекомпільовували прошивку для кінконі?

Так.

[xkansler]

1 час назад, TaurosRMK сказал:

Так.

Наскільки пам'ятаю у Вас Kincony A2 підключено по WiFi а не по UTP.
У мене при оновленні HA та ESPhome з оновленням (перекомпіляцією) прошивок еспішок з якогось моменту (десь з 2-3х місяці назад) деякі еспішки теж почали іноді втрачати зв'язок (cумарно, наразі в моєму будинку "живе" 64 модулі на базі різних ESP).
Трохи досліджував цю тему. Там щось трохи "накрутили" в WiFi стеку. Не вдаваючить в подробиці пристрій "тримається" за WiFi AP до "останнього". В моєму випадку (WiFi побудовано на 8-ми AP Mikrotik з використанням CAPs з доволі детальним моніторінгом усієї інфраструкрути) аналіз і експерименти привели до того що тепер в усіх конфігах ESPhome для пристроїв які підключені по WiFi я використовую локальну автоматизацію яка перезапускає WiFi на ESP у разі зниження рівня RSSI нижче -78dBi або втрати "коннекту". Виглядає це так: 

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: false
  power_save_mode: none
  manual_ip:
    static_ip: ${device_ip}
    gateway: 192.168.10.1
    subnet: 255.255.255.0
    dns1: 192.168.10.1
  ap:
    ssid: ${upper_devicename} Fallback
    password: !secret ap_password

sensor:
  - platform: wifi_signal
    name: ${upper_devicename} Wifi Signal Strength
    id: wifi_signal_sensor
    update_interval: 60s

interval:
  - interval: 60s
    then:
      - if:
          condition:
            or:
              - not: wifi.connected
              - lambda: 'return id(wifi_signal_sensor).state < -78;'
          then:
            - logger.log: WiFi signal is too weak or not connected. Reconnecting...
            - wifi.disable
            - delay: 2s
            - wifi.enable
 

В моєму випадку такий підхід вирішив проблему. Зараз усе стабільно.

Змінено 22 вересня користувачем xkansler

[TaurosRMK]

9 годин тому, xkansler сказав:

автоматизацію яка перезапускає WiFi на ESP у разі зниження рівня RSSI нижче -78dBi або втрати "коннекту".

Так це ж те саме буде що на скріншоті, при перезапуску контролер стане недоступний і знову появиться в мережі?

[xkansler]

1 час назад, TaurosRMK сказал:

Так це ж те саме буде що на скріншоті, при перезапуску контролер стане недоступний і знову появиться в мережі?

В моєму випадку це не так.

У мене декілька AP (точок доступу) Mikrotik які "тримають" мережу WiFi під керуванням контроллеру CAPs від тієїж Mikrotik.
Контроллер CAPs в сучасній версії RouterOS V7 підтримує стандарти WiFi Roaming 802.11k/v/r (безшовний роумінг Wi-Fi). В інеті є багато інфи про 802.11k/v/r. Якщо дуже спрощено то це взаємодія клиентів і AP для підключення (перепідключення) до найбільш оптимальної AP з точки зору якості зв'язку і завантаженості AP які "тримають" WiFi мережу.
Стек WiFi в ESPhome наразі не підтримує 802.11k/v/r тому в моєму випадку ESPшки іноді "чіпляються" до неоптимальної AP і тримаються за неї "до останнього". Спроби скидати коннект такої ESP на стороні контроллера CAPs не завжди (майже ніколи) не призводять до переконекту ESPшки до більш оптимальної AP. А от перезавантаження ESP або вимкнення->включення WiFi на ESP як правило, в моєму випадку, призводить до того що ESPшка підкючається до більш оптимальної AP. Але при перезавантаженні окрім перепідключення до нової AP скидаються стани усіх змінних, включно з globals, скидаються усі локальні лічильники і локальні автоматизації які працюють на ESP і т.д. При вимкненні->включенні WiFi цього не стається, після перепідключення ESP, HA, в моєму випадку, навіть "не помічає" цього, це видно тільки в логах ESP (logger.log: WiFi signal is too weak or not connected. Reconnecting...).

Якщо у вас мережу WiFi "тримає" декілька AP (MikroTik/Kinnetic/TP-LINK/Ubiquiti etc.) то мій кейс може вам стати в нагоді.

Змінено 22 вересня користувачем xkansler

[TaurosRMK]

56 хвилин тому, xkansler сказав:

мережу WiFi "тримає"

Тримає один роутер ))) який знаходиться в двох метрах від Kincony. Дивно що це сталося буквально останній тиждень, до цього такого ніколи не було. Але сьогодні ніби все ок, хоча вентиляцію вимкнули десь в обід і забули запустити, недавно тільки запустив.
 

[xkansler]

1 минуту назад, TaurosRMK сказал:

Тримає один роутер ))) який знаходиться в двох метрах від Kincony. Дивно що це сталося буквально останній тиждень, до цього такого ніколи не було. Але сьогодні ніби все ок, хоча вентиляцію вимкнули десь в обід і забули запустити, недавно тільки запустив.
 

У мене теж раніше ніяких траблів з ESP по WiFi небуло. А от десь 2-3 місяці тому виникли, при тому що обладнання WiFi не змінювалось і налаштування Mikrotik теж. Я не зафіксував з якої версії ESPhome це почалось, тому що після оновлення ESPhome я перекомпілюю не усі модулі, а тільки ті які використовують компоненти які є в оновлені, або коли є серйозні зміни в API ESPhome. Але на тих що перекомпілював з часом помітив періодичні "відвали".
На форумах по ESPhome з'явилися повідомлення про трабли в стеку WiFi і різні варіанти рішення. Те яке я навів вирішило мою проблему.
Я не стрерджую що у Вас такий самий трабл, але якщо перезапуску ESP не стається то скоріш за усе щось не так з WiFi. Як варіант сусіди могли заспамити канал який використовує ваша AP. 
Загалом в налаштуваннях WiFi ESPhome є досить багато параметрів - esphome.io/components/wifi/

[TaurosRMK]

1 година тому, TaurosRMK сказав:

Але сьогодні ніби все ок, хоча вентиляцію вимкнули десь в обід і забули запустити, недавно тільки запустив.

Тільки сказав що все ок, як буквально 20 хв назад те саме ))

51 хвилину тому, xkansler сказав:

Загалом в налаштуваннях WiFi ESPhome є досить багато параметрів - esphome.io/components/wifi/

Що ж, подивлюся. В крайньому випадку Ethernet кабель вже давно куплено, тільки руки не доходять підключити.

[xkansler]

19 минут назад, TaurosRMK сказал:

Тільки сказав що все ок, як буквально 20 хв назад те саме ))

Що ж, подивлюся. В крайньому випадку Ethernet кабель вже давно куплено, тільки руки не доходять підключити.

Доречі ethernet на Kincony (LAN8720) дуже стабільний. За більше трьох років експлуатації їх серії Kincony KC868 жодного траблу і відвалу. Я Kincony по ethernet використовую в критичних інтеграціях - опалення, електроспоживання, ... все стабільно  

Змінено 22 вересня користувачем xkansler

[beavis]

Мої відвали ESP, які були з самого початку у мене (майже рік тому), схоже вилікувались, коли на 2,4Гц змінив шифруваня з WPA3/WPA2 на WPA2. Те що це може бути проблемою знайшов випадково. Намагався IMOU дзвінок підключити до мережі і він бачив всі доступні, але до жодної не підключався. Почав гратись з шифруванням - і все підключилось. Потім з чатГПТ "підвердив" що для багатьох дешевих модулів Гібридне шифрування може бути проблемою, так як вони не вміють автоматично переключати ці режими і можуть залипати на WPA3. Чи дійсно це так - більше ніде не цікавився. Зараз ESP працює відносно стабільно.

[TaurosRMK]

Став підозрювати що проблема не в ESP, НА чи прошивках, а можливо в роутері. Бо декілька днів назад просто пропав інтернет, хоча від провайдера все було. Перезавантаження і всякі такі дії нічого не давали, частково працював по кабелю, а wi-fi ні, або наоборот, або при вимкненні одної з частот 2.4 GHz чи 5 GHz на деякий час попускало і знову переставав працювати. Знайшов якийсь старий роутер, перевірив, все працює. Потім зайшов в налаштування основного роутера, а там для кожного пристрою присвоїно ІР 0.0.0.0. Скинув на заводські налаштування, ніби попустило, день чи два працювало норм, а потім знову почалися відвали wi-fi в декількох метрах від роутера.

Тому можу припустити що проблема в роутері, який на долі секунди глючить зі своїм wi-fi, а ESP/НА на це реагують і перепідключаються.

[mib]

26 минут назад, TaurosRMK сказал:

Тому можу припустити що проблема в роутері, який на долі секунди глючить зі своїм wi-fi, а ESP/НА на це реагують і перепідключаються.

У меня роутер netis, зачем то раз в сутки толи обновляет сессии толи его глючит, но все девайсы по очереди переподключаются примерно в одно и тоже время, в 3 часа ночи, нигде в настройках я этого не нашел, пока забил в моих реалиях это проблем особых не вызывает

[S K]

В кого є досвід підлючення декількох датчиків DS18B20 наприклад до ESP32? Коли я пыдключаю 1-2 датчики,то все працюэ ок, але якщо пыдключаю быльше, то весь час лізуть помилки контрольних сум. Дивився, що датчики тре пыдключати послыдовно, а не типом зірка. Але як їх підключити, якщо багато датчиків навідстані до 5 метрів максимум.

[yur43]

31 хвилину тому, S K сказав:

В кого є досвід підлючення декількох датчиків DS18B20 

https://www.stroimdom.com.ua/search/?q=DS18B20&quick=1

проблема частіше в шині, а не в ESP

[S K]

та знаю, що проблема в тому, що коли декілька датчиків, топриходить відлуння сигналу. Мене цікавить як хто вирішував проблему встановлення багатьох таких датчиків на одну шину, щоб не було "мусору" выд датчиків. Буду шукати рішення. Перше щознаходжу - робити довгу шину і до неї підключати датчики з відводамимаксимум по 15 см. Іншого вирішення поки незнайшов.

[xkansler]

В 28.09.2025 в 10:20, S K сказал:

та знаю, що проблема в тому, що коли декілька датчиків, топриходить відлуння сигналу. Мене цікавить як хто вирішував проблему встановлення багатьох таких датчиків на одну шину, щоб не було "мусору" выд датчиків. Буду шукати рішення. Перше щознаходжу - робити довгу шину і до неї підключати датчики з відводамимаксимум по 15 см. Іншого вирішення поки незнайшов.

Тут досить детально розписано все що стосується OneWire, якраз на прикладі Dallas - mischianti.org/dallas-ds18b20-with-esp32-and-esp8266-all-onewire-topologies-long-stubs-and-more-devices/

В своєму випадку (оскільки використовую ESP32 то пінів вистачає) вішаю по даласу на пін. В принципі по 2-3 даласи на пін у мене теж стабільно працює на звичайній витій парі сигнального кабелю.
Конфіги виглядають так:

one_wire:
  - platform: gpio
    pin: GPIO14
    id: heat_floor_temp_1
  - platform: gpio
    pin: GPIO13
    id: heat_floor_temp_2
  - platform: gpio
    pin: GPIO32
    id: heat_floor_temp_3
  - platform: gpio
    pin:
      number: 33
      mode:
        input: true
        output: true
        pullup: false
    id: heat_floor_temp_4

sensor:

  # Температура подачі з котла
  - platform: dallas_temp
    address: 0xEE3C01D0758DC828
    name: ${upper_devicename} Temp Flow
    one_wire_id: heat_floor_temp_1
    resolution: 12
    unit_of_measurement: "°C"
    filters:
      - round: 2
      - filter_out: nan
      - sliding_window_moving_average:
          window_size: 7
          send_every: 4
          send_first_at: 3

...........................................

  # Температура подачі в контури теплої підлоги
  - platform: dallas_temp
    address: 0x863C01D075E43328
    name: ${upper_devicename} Temp Floor Flow
    one_wire_id: heat_floor_temp_4
    resolution: 12
    unit_of_measurement: "°C"
    filters:
      - round: 2
      - filter_out: nan
      - offset: -0.1
      - sliding_window_moving_average:
          window_size: 7
          send_every: 4
          send_first_at: 3

Змінено В понеділок в 09:55 користувачем xkansler

[TaurosRMK]

Думав проблема зникла, але схоже що ні. Хоча обривів зв'язку, чи як це можна назвати, стало менше.
Додав сенсор wi-fi сингалу, прогнозовано там все супер, 2 метри до роутера, які можуть бути проблеми, стабільно -30...-35 dBm.

Також додав сенсор Reset Reason і помітив що в моменти коли щось не то з Kincony, сенсор показує запис task watchdog. Не розібрався де саме шукати детальну інформацію про це, гугл каже що треба дивитися в лог Kincony, але ж тримати постійно відкритий лог не завжди виходить. Тим більше що між спрацюваннями може пройти годин 10-15, або взагалі серед ночі. Знайшов який журнал налагодження в інтеграції ESPHome, включив його. Сьогодні зайшов подивитися чи є там щось цікавого. Нажаль він не зберіг всі записи, тобто попереднього запису в 07:42 немає, тільки за останні півтори години, але якраз зберігся запис про 13:02. Але в цей час не спрацювала автоматизація Kincony, тобто не прийшло повідомлення в телеграм бот, хоча по запису логу видно що відбулосся перепідключення (якщо я вірно зрозумів).

2025-10-01 13:02:10.096 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Sending HelloRequest: client_info: "Home Assistant 2025.9.4"
api_version_major: 1
api_version_minor: 12

2025-10-01 13:02:10.096 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Sending ConnectRequest: 
2025-10-01 13:02:10.096 DEBUG (MainThread) [aioesphomeapi._frame_helper.base] kincony-a2-n @ 192.168.1.103: Sending frame: [010031c3e239c3d95718d1e164b765b2ba4eaf77071c3898da04f0e2208260e9543f553423286525662f2358efa0370100148b5623e8949bd4ee7b77]
2025-10-01 13:02:10.226 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type NumberStateResponse (len=5): key: 3467138

2025-10-01 13:02:10.226 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type NumberStateResponse (len=5): key: 4050902

2025-10-01 13:02:10.226 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type NumberStateResponse (len=5): key: 1059676

2025-10-01 13:02:10.226 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type NumberStateResponse (len=5): key: 1166887

2025-10-01 13:02:10.281 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type HelloResponse (len=28): api_version_major: 1
api_version_minor: 12
server_info: "2025.9.2"
name: "kincony-a2-n"

2025-10-01 13:02:10.282 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Successfully connected ('2025.9.2' API=1.12)
2025-10-01 13:02:10.282 INFO (MainThread) [aioesphomeapi.reconnect_logic] Successful handshake with kincony-a2-n @ 192.168.1.103 in 0.426s
2025-10-01 13:02:10.282 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Sending DeviceInfoRequest: 
2025-10-01 13:02:10.282 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Sending ListEntitiesRequest: 
2025-10-01 13:02:10.282 DEBUG (MainThread) [aioesphomeapi._frame_helper.base] kincony-a2-n @ 192.168.1.103: Sending frame: [01001462a3ada072f551263d683e4dc880c1c0100145dcf8693498f5041b40e2d8ee925f4441ea579]
2025-10-01 13:02:10.282 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type ConnectResponse (len=0): 
2025-10-01 13:02:10.360 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type DeviceInfoResponse (len=106): name: "kincony-a2-n"
mac_address: "xx:xx:xx:xx:xx:xx"
esphome_version: "2025.9.2"
compilation_time: "Sep 30 2025, 11:20:18"
model: "esp32dev"
webserver_port: 80
manufacturer: "Espressif"
friendly_name: "Kincony A2_N"
api_encryption_supported: true

Попередньо грішив на роутер, який почав барахлити, але оновив прошивку і наче з ним все ок. А от зрозуміти що саме спричиняє ці перезавантаження/обриви, поки не знаю як. Знайшов ще інфу що можливо Kincony не вистачає живлення і тому вона перепідключається. Kincony А2 живиться 9-24В, в меня якраз було 9В через понижуючий модуль (там були нюанси з іншими пристроями при 24В, тому прийшлося використати понижуючий модуль 24В->9В), але він з можливістю регулювання, тому підкрутив до 12В. Особливо не допомогло, все рівно бувають описані раніше проблеми. Наприклад за вчора було аж 4 спрацювання автоматизації, яка відбувається при натисканні перемикача "Запуск системи", відбувається запуск обладнання і в кінці приходить повідомлення в телеграм бот. І от чому ця автоматизація спрацьовує коли система вже працює, поки не зрозуміло.

Що ще порадите зробити, щоб знайти можливу проблему?

Змінено 8 годин тому користувачем TaurosRMK

[xkansler]

1 час назад, TaurosRMK сказал:

Думав проблема зникла, але схоже що ні. Хоча обривів зв'язку, чи як це можна назвати, стало менше.
Додав сенсор wi-fi сингалу, прогнозовано там все супер, 2 метри до роутера, які можуть бути проблеми, стабільно -30...-35 dBm.

Також додав сенсор Reset Reason і помітив що в моменти коли щось не то з Kincony, сенсор показує запис task watchdog. Не розібрався де саме шукати детальну інформацію про це, гугл каже що треба дивитися в лог Kincony, але ж тримати постійно відкритий лог не завжди виходить. Тим більше що між спрацюваннями може пройти годин 10-15, або взагалі серед ночі. Знайшов який журнал налагодження в інтеграції ESPHome, включив його. Сьогодні зайшов подивитися чи є там щось цікавого. Нажаль він не зберіг всі записи, тобто попереднього запису в 07:42 немає, тільки за останні півтори години, але якраз зберігся запис про 13:02. Але в цей час не спрацювала автоматизація Kincony, тобто не прийшло повідомлення в телеграм бот, хоча по запису логу видно що відбулосся перепідключення (якщо я вірно зрозумів).

2025-10-01 13:02:10.096 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Sending HelloRequest: client_info: "Home Assistant 2025.9.4"
api_version_major: 1
api_version_minor: 12

2025-10-01 13:02:10.096 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Sending ConnectRequest: 
2025-10-01 13:02:10.096 DEBUG (MainThread) [aioesphomeapi._frame_helper.base] kincony-a2-n @ 192.168.1.103: Sending frame: [010031c3e239c3d95718d1e164b765b2ba4eaf77071c3898da04f0e2208260e9543f553423286525662f2358efa0370100148b5623e8949bd4ee7b77]
2025-10-01 13:02:10.226 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type NumberStateResponse (len=5): key: 3467138

2025-10-01 13:02:10.226 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type NumberStateResponse (len=5): key: 4050902

2025-10-01 13:02:10.226 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type NumberStateResponse (len=5): key: 1059676

2025-10-01 13:02:10.226 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type NumberStateResponse (len=5): key: 1166887

2025-10-01 13:02:10.281 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type HelloResponse (len=28): api_version_major: 1
api_version_minor: 12
server_info: "2025.9.2"
name: "kincony-a2-n"

2025-10-01 13:02:10.282 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Successfully connected ('2025.9.2' API=1.12)
2025-10-01 13:02:10.282 INFO (MainThread) [aioesphomeapi.reconnect_logic] Successful handshake with kincony-a2-n @ 192.168.1.103 in 0.426s
2025-10-01 13:02:10.282 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Sending DeviceInfoRequest: 
2025-10-01 13:02:10.282 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Sending ListEntitiesRequest: 
2025-10-01 13:02:10.282 DEBUG (MainThread) [aioesphomeapi._frame_helper.base] kincony-a2-n @ 192.168.1.103: Sending frame: [01001462a3ada072f551263d683e4dc880c1c0100145dcf8693498f5041b40e2d8ee925f4441ea579]
2025-10-01 13:02:10.282 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type ConnectResponse (len=0): 
2025-10-01 13:02:10.360 DEBUG (MainThread) [aioesphomeapi.connection] kincony-a2-n @ 192.168.1.103: Got message of type DeviceInfoResponse (len=106): name: "kincony-a2-n"
mac_address: "xx:xx:xx:xx:xx:xx"
esphome_version: "2025.9.2"
compilation_time: "Sep 30 2025, 11:20:18"
model: "esp32dev"
webserver_port: 80
manufacturer: "Espressif"
friendly_name: "Kincony A2_N"
api_encryption_supported: true

Попередньо грішив на роутер, який почав барахлити, але оновив прошивку і наче з ним все ок. А от зрозуміти що саме спричиняє ці перезавантаження/обриви, поки не знаю як. Знайшов ще інфу що можливо Kincony не вистачає живлення і тому вона перепідключається. Kincony А2 живиться 9-24В, в меня якраз було 9В через понижуючий модуль (там були нюанси з іншими пристроями при 24В, тому прийшлося використати понижуючий модуль 24В->9В), але він з можливістю регулювання, тому підкрутив до 12В. Особливо не допомогло, все рівно бувають описані раніше проблеми. Наприклад за вчора було аж 4 спрацювання автоматизації, яка відбувається при натисканні перемикача "Запуск системи", відбувається запуск обладнання і в кінці приходить повідомлення в телеграм бот. І от чому ця автоматизація спрацьовує коли система вже працює, поки не зрозуміло.

Що ще порадите зробити, щоб знайти можливу проблему?

Дивна поведінка. Схоже що о 13:02 було перепідключення до WiFi. Спробуйте в конфігу yaml (для вашого Kincony) включити більш детальний лог саме WiFi компонента, десь так:
logger:
  level: VERBOSE
  initial_level: ERROR
  logs:
    wifi: VERBOSE

Також включіть сенсор Uptime щоб точно знати що не відбувається загального перезавантаження ESP:
sensor:
  - platform: uptime
    type: seconds
    name: Uptime Sensor

P.S.
Якщо Ваш роутер працює в сильно "загаженому" радіо середовищі (багато сусідських роутерів, zigbee концентраторів, блютуз пристроїв та інше) то рівень RSSI (рівень сингалу) мало-інформативний.
RSSI - це показник потужності Wi-Fi сигналу, що надходить до вашого пристрою. Набагато важливіше, і сильніше впливає на стабільність передачі данних - SNR (Signal to Noise Ratio - співвідношення сигнал/шум) - www.wireless-nets.com/resources/tutorials/define_SNR_values.html
Якщо, для прикладу у вас роутер працює на 6-му каналі (частота 2.4Ghz) і ваша ESP показує RSSI -40dbi а за "стінкою" працює інший роутер теж на 6-му каналі (його сигнал для вашого роутера являється шумом) і в точці знаходження вашої ESP рівень сигналу цього роутера -45dbi то при начебто високому (-40dbi) сигналу ваш SNR усього 5dbi і при такому SNR передача данних майже неможлива.
Це як ніби багато людей, в одній локаціЇ, одночасно дуже гучно розмовляють. Гучність є, а от розібрати про що йде мова майже неможливо. Так і з RSSI.

Змінено 7 годин тому користувачем xkansler

[TaurosRMK]

1 годину тому, xkansler сказав:

Дивна поведінка. Схоже що о 13:02 було перепідключення до WiFi. Спробуйте в конфігу yaml (для вашого Kincony) включити більш детальний лог саме WiFi компонента, десь так:
logger:
  level: VERBOSE
  initial_level: ERROR
  logs:
    wifi: VERBOSE

Також включіть сенсор Uptime щоб точно знати що не відбувається загального перезавантаження ESP:
sensor:
  - platform: uptime
    type: seconds
    name: Uptime Sensor

P.S.
Якщо Ваш роутер працює в сильно "загаженому" радіо середовищі (багато сусідських роутерів, zigbee концентраторів, блютуз пристроїв та інше) то рівень RSSI (рівень сингалу) мало-інформативний.
RSSI - це показник потужності Wi-Fi сигналу, що надходить до вашого пристрою. Набагато важливіше, і сильніше впливає на стабільність передачі данних - SNR (Signal to Noise Ratio - співвідношення сигнал/шум) - www.wireless-nets.com/resources/tutorials/define_SNR_values.html
Якщо, для прикладу у вас роутер працює на 6-му каналі (частота 2.4Ghz) і ваша ESP показує RSSI -40dbi а за "стінкою" працює інший роутер теж на 6-му каналі (його сигнал для вашого роутера являється шумом) і в точці знаходження вашої ESP рівень сигналу цього роутера -45dbi то при начебто високому (-40dbi) сигналу ваш SNR усього 5dbi і при такому SNR передача данних майже неможлива.
Це як ніби багато людей, в одній локаціЇ, одночасно дуже гучно розмовляють. Гучність є, а от розібрати про що йде мова майже неможливо. Так і з RSSI.

Оновлю yaml і подивлюся що буде. Тільки де ті логи wi-fi шукати, вони кудись записуються чи тільки коли логування відкрито і потім його зберігати вручну?
З приводу роутера, тільки один роутер, поруч є ще usb zigbee свисток в сервері НА на міні ПК. Більше нічого немає, а оскільки це приватний будинок, то інших роутерів десь поруч також немає. В налаштуваннях каналу стоїть авто.

[TaurosRMK]

Згадав що десь в недавніх оновленнях ESPHome додали підтримку ESP-now. Чи хтось вже пробував зв'язувати пристрої між собою по ESP-now? Чи працює коректно?

[xkansler]

4 минуты назад, TaurosRMK сказал:

Згадав що десь в недавніх оновленнях ESPHome додали підтримку ESP-now. Чи хтось вже пробував зв'язувати пристрої між собою по ESP-now? Чи працює коректно?

Так з версії за серпень 2025 року ESPNow є штатним компонентом ESPhome - esphome.io/components/espnow/

Попробував "на зуб" в сценарії ESP32+DS18B20 (зліпив вуличний датчик) який передає вуличну температуру контроллеру який керує газовим котлом Vaillant через eBus (esp32 + eBus adapter) - 2 неділі працює стабільно, далі спостерігаю

[TaurosRMK]

32 хвилини тому, xkansler сказав:

Так з версії за серпень 2025 року ESPNow є штатним компонентом ESPhome - esphome.io/components/espnow/

Попробував "на зуб" в сценарії ESP32+DS18B20 (зліпив вуличний датчик) який передає вуличну температуру контроллеру який керує газовим котлом Vaillant через eBus (esp32 + eBus adapter) - 2 неділі працює стабільно, далі спостерігаю

Можна код? Бо я пробував практично в перший тиждень після оновлення, щось не вийшло в мене. Але я ще той програміст 😆

[TaurosRMK]

5 годин тому, xkansler сказав:

Також включіть сенсор Uptime щоб точно знати що не відбувається загального перезавантаження ESP:
sensor:
  - platform: uptime
    type: seconds
    name: Uptime Sensor

Спрацювало знову, прийшло повідомлення в телеграм бот. Зайшов подивитися, а там ось так 🤔 Шкода лог не був відкритий, щоб глянути більш детально.