xkansler

Так з версії за серпень 2025 року ESPNow є штатним компонентом ESPhome - esphome.io/components/espnow/ Попробував "на зуб" в сценарії ESP32+DS18B20 (зліпив вуличний датчик) який передає вуличну температуру контроллеру який керує газовим котлом Vaillant через eBus (esp32 + eBus adapter) - 2 неділі працює стабільно, далі спостерігаю

Дивна поведінка. Схоже що о 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.

Тут досить детально розписано все що стосується 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

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

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

В моєму випадку це не так. У мене декілька 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.) то мій кейс може вам стати в нагоді.

Наскільки пам'ятаю у Вас 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 В моєму випадку такий підхід вирішив проблему. Зараз усе стабільно.

😅... Мережевий є, як ви мабудь здогадались - SUN-15K-G05

Стосовно мережевих інверторів інших виробників (відмінних від Deye/Sunsynk), у мене немає точної інфи, хоча в інеті бачив подібні кейси з інверторами інших брендів. Наскільки ця інфа реальна важко стверджувати... Стосовно того що керування мережевим інвертором Deye/Sunsynk підключеним до Gen порту гібрида Deye/Sunsynk, який працює в режимі Microinvertor то це штатний функціонал, який описаний в документації інверторів Deye. Цей функціонал підтверджений діючою інсталяцією, конфігурацію якої я навів вище. Оскільки ми тут начебто в гілці "Deye інвертори гібридні", то мені видається, можливо, що починати досліджувати які "розклади" на цю тему у інших брендів не зовсім правильно, для цього є профільні гілки на цьому форумі або на інших. Мережеві інвертори Deye досить "бюджетні" відносно гібридів. ~$750 за трифазний SUN-15K-G05 доволі прийнятна ціна на якісний виріб для розширення гібридної системи

Не зовсім так. Там набагато цікавіше - гібрид при підключені мережевого інвертора на порт Gen (порт Gen режимі Microinvertor) за допомогою частоти доволі плавно може обмежувати або "відпускати" генерацію мережевого (при відсутності Grid) в залежності "потреби яка виникає" на Load або для заряду батарей: Зараз в такому режимі працює одна з інсталяцій (у мого товариша): три 5K гібридних однофазних в трифазній схемі (з синхронізацією фаз) + 15K мережевий трифазний у котрого фази відповідно розведені по портам Gen на 5К - все працює як швейцарський годинник

Дякую. По цій схемі і під'єднував систему. Зараз беру осцилограф, вольтметр, кліщі і їду до товариша дивитись що у нього і як на N та PE. Тільки після замірів буду приймати рішення чи з'єднувати N i PE на постійній основі чи через контактор. Може виявитись що у нього ситуація, в питанні N i PE, ще веселіша ніж у мене (дивіться пост вище). У нього до речі на вході стабів не має і він вже мав проблеми. За останній рік телевізор і інверторний холодильник "навернулися". Зубри як Deye не допомогли - і телевізор і інверторний холодильник підключені на Load. В обох приладах "постріляли" варистори в БП, причому в телевізорі вони не спасли - вигоріло усе далі, включно з БП і процем. Скоріш за все була імпульсна перенапруга від якої ні Зубри ні Deye не спасли.

Дякую за підказки. Я не комутую PE і N на постійній основі тому що в наших пенатах (Буча) електрики так чудять що мати не горюй. Коли з нашої місцевості вибили клятих москалів то тут майже повністю була знищена енерго-інфраструктура. Ці вилупки коли заходили одразу лупили по трансформаторах, тому роботи по налагодженю мережі перманентно тривають і донині. І хоч на вході у мене стоять три Quant (інверторні стаби) все одно я трохи стрьомаюсь на постійній основі з'єднувати N і PE, хоч PЕ у мене локальний, дуже добрий і з'єднаний з PE мережі. P.S. Для розуміння того що маю. Якщо я чотирьохполюсником (L1,L2,L3,N) відкидаю мережу і міряю потенціал між N і PE на "стовбі" то маю "гуляючі" 50-70V

Була у мене така здогатка, окільки у 5К, на Load, при відключеній зовнішній мережі, як такого нуля немає - на відміну від "старших" моделей у нього всередені немає реле яке комутує нуль на землю коли інвертор переходить в "острівний" режим роботи без мережі. Коли 5K стояв у мене то для того щоб мій газовий котел "не дуркував", я використовуючи сигнал інвертора (Signal Island Mode), при відключені зовнішньої мережі NO контактором замикав N на PE. Якщо це зробити в троьхфазній системі по сигналу з мастера то все буде Ок? Є у кого досвід троьхфазної системи з трьох однофазних Deye?

Отже, трясьця засада!!! У мене це один з ключових параметрів ("Grid peak-shaving power") за допомогою якого я керую системою. Оскільки ЗТ у мене нема, і система постійно "Zero Export To Load" то я за допомогою "Grid peak-shaving power" керую споживанням з мережі, щоб не клацати контактором на вході (хоча торьохполюсний контактор перед інвертором поставив). У мене досить "хитрі" алгоритми які враховують прогноз виробітку по сонцю (з двох джерел), статистику споживання за попередні періоди, стан аккумів і керуючи "Grid peak-shaving power" і "Max Battery Charge" я дослідним шляхом (багато графіків і аналіз на їх основі) написав алгоритми які мінімізують споживання з мережі і максимально утилізують сонце з PV для своеї СЕС але так щоб не залишитись без резерву в аккумах. В алгоритмах враховано навіть "привіти" довбаних кацапів, в вигляді тривог, через інтеграцію HA - Ukraine Alarm Довбані китайці... Тепер доведеться переосмислити як керувати і переписувати алгоритми, що їх...

Одразу не відходячи від касси другий кейс питань до товариства. Свій 5К я віддав товаришу у якого стояло 2 шт. 5К в режимі паралель на одній фазі. Все працювало бездоганно. Зараз він підключив ЗТ і стало питання трифазної схеми. Зібрали трифазну схему з трьох 5К. Все по мануалу. При запуску системи, з під'єднаною зовнішньою мережою, система працює. Мережу бачить, LOAD живить, аккуми заряджає, з PV бере, нормально продає. Як тільки відключається зовнішня мережа система вилітає в помилку, на LOAD нічого немає, аккуми не бачить. Видає F41Parallel_System_Stop, а за ним якийсь дивний Alert - F50AC_V_GridCurr_DcHigh_Fault. Його в мануалі взагалі нема. Цей Alert навіть не гуглиться. Після під'єднання зовнішньої мережі в нормальний стан не повертається без повного перезапуску. Після перезапуску інверторів все стартує і працює до слідуючого від'єднання зовнішньої мережі. Може хтось стикався, бо підтримка Deye мовчить. P.S. Усі три інвертори абсолютно однакові. Купувалися одночасно у одного продавця, тобто товариш тоді купив собі два і я один. Серійники дуже поряд - тобто це +/- одна партія. Прошивки на всіх 5К однакові, останні, оновлені підтримкою Deye Stable version - MAIN：3388-1515 / HMI：0000-C379. Прошивки логерів на всіх трьох - LSW3_32U_5406_1.06 Система декілька разів скидалась до до заводських налаштувань (кожен інвертор окремо) і налаштовувалась з нуля, але це нічого не змінило в поведінці системи