xkansler

Дякую. По цій схемі і під'єднував систему. Зараз беру осцилограф, вольтметр, кліщі і їду до товариша дивитись що у нього і як на 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 Система декілька разів скидалась до до заводських налаштувань (кожен інвертор окремо) і налаштовувалась з нуля, але це нічого не змінило в поведінці системи

Доброго ранку шановне товариство! Замінив свого SUN-5K-LP1 на SUN-12K-LP3. Оновив прошивку на 12К до останньої актуальної - MAIN:2006-1172-1807 / HMI:1001-C050 / Arc Board:D207. Виникло декілька питань: 1. Ніяк не хоче віключатись (не знімається галка) з "Time Of Use" (на 5К це працювало без проблем). Оскільки я керую інвертором з НomeAssistant (напряму по CAN, не через логер) то він мені тільки заважає. Як його відключити, чи в 12К "Time Of Use" не відключається? - Пробував "знімати галку" на інверторі - знімається але не запам'ятовується. - Пробував підключати логер і робити це через хмару Deye Cloud - та сама фігня - Read -> Зняття галки -> Setup - ніфіга не знімається. - Пробував скидати інвертор до заводських налаштувань - Basic Setting -> Factory Reset. Отримую індіанське житло "фігвам" Написав в підтримку Deye - мовчать Може є якийсь ритуальний танок с бубном про який я не знаю? 2. На 12К, в меню Advanced Function немає MPPT Scan хоча в Deye Cloud цей пункт є і начебто налаштовується - тобто можна змінити і зміни запам'ятовується. Але як воно по факту - цей функціонал на 12К працює, чи тільки дослідно вивчати? Може хтось бавився в це? Одразу поясню навіщо воно мені. У мене поле частково затінюється сусідським дубом і на 5К цей функціонал, в моєму випадку, хоча й не сильно але підвищував ефективнісь поля - перевірено дослідним шляхом. Про оптимізатори знаю, але поки хочеться малою кровью.

Це називається жвава дискуссія 😊. Форуми для цього і існують. Тут головне корректнісь в висловах і повага до спільноти..., і щоб учасники спільнити могли отримувати корисну інформацію для вирішення своїх задач/проблем.

Якщо Ви відслідковувіли з самого початку історію питання про те, як у ініціатора питання була побудована система, то мабудь побачили що перша моя відповідь була "Трохи кривувато... але має місце для існування." і далі я надав свої рекомендації які б з мінімальними перелаштуваннями дозволили отримати бажаний, стабільно працюючий (з урахуванням поточних реалій Proxmox) результат. Звичайно можна заганяти запитувача в true рішення - але я не ставив перед собою таке завдяння... Натяк дав. Мене трохи "здивувало" питання про можливість життя NextCloud в CT... А якщо Ви вже перейшли на рівень спілкування "уранові ломи в ртуті" - то на навіть на базових рівнях професійного використання будь яких систем віртуалізації, на будь яких курсах адміністрування Вам мали розповісти що найменш бажаним (хоч і не забороненим) є втручання в конфігурацію хост системи. Серед адмінів (корпоративних систем як мінімум) втручання в хост систему - це шлях до нестабільності. Усі питання які можна вирішити через конфігурації (навіть криві) гостьових систем (СТ/VM) треба вирішувати по моживості там, тому що "лягла" одна VM це проблема однієї VM. "Ліг" хост - лягли УСІ! P.S. Proxmox не бажано робити сервером Samba Якщо у Вас є запитання по тому як монтувати samba шари в середині гостьових систем Proxmox, то будь ласка в приватному листуванні я залюбки дам вам конфіги різних CT гостьових систем (Debian/CentOS ets.) які гарантовано будуть працювати починаючи з Proxmox V4.0.x

У мене для команій, які я облуговую (а їх більше 50), NextCloud (зараз це вже зветься Next Hub), в різних датаклоудах, під різними хіпервізорами, десь Proxmox, десь XCP/Xen, десь VMware (там через слайс) усе крутиться на LXC (CT). Це все на корпорапивному рівні, з витікаючими з цього вимогами. Загалом на усіх NextCloud-ах багато більше 2000 активних користувачів - усе під LXC (для правильного і економного розподілу ресурсів ЦП і RAM) - за останні 10 років ніяких траблів з таким підходом не було... Ви щось знаєте...?

А можна побачити якісь пруфи стосовно забобонів моунтини в середині СТ samba шари? Усе що треба для роботи samba це порти UDP 137,138 та TCP 139,445 Тобто ви своїм постом (без пруфів) хочете сказати весь мережевий стек LXS, який є базовим для CentOS/Debain/Fedora/Gentoo/OpenSUSE і т.д. є повний "хлам" і непрацююча історія?

Здається "продаванам" такі пости не подобаються - тоді точно знайду час, і в максимильно стислі строки доведу проект до "продакшину". Весь код, детальні схеми, графіки вимірювань, фото - викладу в відкритий доступ (з проєктом на github). P.S. Дяка "дислайкеру" з красномовним ніком "Наблюдатель" за заохочення...

В меню інвертора цього нема. Але батареї (принаймі Deye) цю інфу (по CAN шині - адреса CAN ID:0x359) надають інвертору. В додатку для смартфонів або через web-морду це можна побачити - дивитись треба в "Пристрій"->"Батарея"->"клік по серійнику батареї". Там можуть бути три стани "порту" батарей Charge/Discharge/Idle (заряджається/розряждається/"простоює")

Рішення від MeanWell досить пристойні, з точки зору якості, але цінник, за таку потужність, досить не малий. Навіть в Китаї десь від $170, а тут взагалі від ~$300 Тему з зарядними пристроями для LiFePo4 48V систем уже давно за західних (і не тільки) форумах розклали по поличках. На сьогодняшній день найоптимальнішими рішеннями (с точки зору якість/надійність/ціна) є керовані промислові блоки живлення для телекому. Тут можна ознайомитись з переліком -endless-sphere.com/sphere/threads/overview-best-rectifiers-for-charging-voltage-mod-eltek-delta-huawei-emerson-vertiv.114784 Вони розраховані на експлуатацію 365/24 в найсуворіших умовах. Мають усі можливі захисти, оскільки від них живляться елементи критичної інфраструктури телекому вартістю у сотні-мільйони $US. Вартісь простоїв там космос... У них є тільки єдиний для усіх недолік - вентилятор який виходить з ладу через N років експлуатації. Міняється за 5 хвилин, без паяльника. Більше там нічого не ламається і вони працюють роками в онлайн. На томуж ebay/aliexpress за ~S$100 + $20-25 доставка через Mist ви можете без проблем придбати дуже пристойний зарядний, з переліку в посиланні вище, на 3kW. Я собі привіз і використовую Vertiv R48-3000e3. Усі ці блоки живлення керуються по CAN шині. Керувати можна як напругою так і струмом. Протоколи керування є у відкритому доступі. На github є купи проектів під ESP/ESP32, або будь який Arduino. Тобто купуєте БП за умовних $125 (з доставкою) + ~$10 за ESP32 модуль + CAN модуль і отримуєте керований (через вебморду або по usb->pc, або як собі захочете, придумаєте...) до 3kW зарядний пристрій промислового рівня. В усіх цих пристроях реалізована "аварійна система". Усі вони розраховані на роботу під керуванням спеціалізованих контроллерів які постійно моніторять стан БП (під керуванням одного контроллера може бути ціла стійка таких БП на десятки kW) а також отримуючи дані від зовнішніх пристроїв (які вони живлять) і зовнішніх датчиків, вони в реальному часі "підлаштовують" параматри V-I БП. Якщо блок живлення втрачає зв'язок з управляючим модулем то він "переходить" на так звані "аварійні налаштування". Для прикладу - якщо БП заряджає LiFePo4 то контроллер можна налаштувати що від буде підіймати напругу до 56.8V (для прикладу) і струм буде стартувати з 40А і знижувати до 5А на 56.8V (теж для прикладу). У разі якщо втрачається зв'язок БП з контроллером (аварія контроллера, згорів, обрив дата лінії і т.д.) то БП переходить на "аварійні" налаштування які занесені в його вбудований мікроконтролер (в його енергонезалежну пам'ять) - для прикладу 55V/1A - це все програмується і все можна у будь який момент змінити. Ці БП ставляться "в паралель" для нарощування загальної потужності яку треба видати і все це керується контроллером - хоч промисловим, хоч DIY Тобто використовуючи промисловий БП з DIY ("самопальним") контроллером за $10 ви все одно отримаєте абсолютно безпечний зарядний пристрій для своїх батарей! У своєму кейсі я використовуючи таке рішення, зараз правда тільки на "колінці" (ще не в продакшині, через брак часу) зв'язую таку зарядку з своїм рішенням для керування/моніторінгу інвертора Deye з його-ж батареями. Якщо спільноті тема цікава то по завершенню викладу сюди оповідь про цей кейс. P.S. Для затравки ресурси по темі: Huawei R4850G2 (3kW) - www.beyondlogic.org/review-huawei-r4850g2-power-supply-53-5vdc-3kw/ Eltek Flatpack2 (1/1.8kW) - github.com/taHC81/Eltek-Flatpack2-ESPhome Vertiv R48-3000e3 (1/2/3kW): - github.com/PurpleAlien/R48_Rectifier - github.com/anikrooz/Emerson-Vertiv-R48 - github.com/anikrooz/housebatt

Не треба сприймати ESPhome і його YAML як мову програмування. Це не так. Розписувати довго. Вікі досить точно дає розуміння YAML - uk.wikipedia.org/wiki/YAML Сама ESPhome "базуеться" на Arduino framework - esphome.io/components/esp32.html#esp32-arduino-framework (або як альтернатива ESP-IDF framework від Espressif). У складі цих фреймворків є набір бібліотек в яких описані об'єкти і класи за допомогою яких можна взаємодіяти з ESP32, ESP32-S2, ESP32-S3, ESP32-C3, ESP32-C6, ESP32-H2 і т.д. В рамках синтаксису YAML який використовує ESPhome усе сильно "заточено" під взаємодію з HomeAssistant, тому розглядати ESPhome у "відриві" можна, але навляд-чи доцільно, оскільки для ардуіно існує багато IDE з великим набором фреймворків які набагато гнучкіші і потужніші. А от якщо треба щось "прикрутити" та базі мікроконтроллерів підпримуваних ESPhome до HA - то це саме те що треба! ESPhome має потужний API який повністю імплементовано в HA через інтеграцію ESPhome. Всі датчики, серсори, і т.д. створені в ESPhome, а також іх стани, властивості і т.д. прозоро "прокидаються" через це API в НА. Також є можливість в зворотньому напрямку "прокидати" сутності і іх властивості з HA (не важливо "звідки вони опилилися" в HA, тобто яка інтергація і з якої экосистеми их "підтягнула") в ESPhome. Звичайно є деякі обмеження API і вони викладені в офіційній документації. Якщо на сильно примітивному рівні спробувати пояснити що таке YAML який використовує ESPhome - то це набір описів і правил (його навіть називають конфіг-файл) які ESPhome при створенні бінарника спочатку транслює у код "С" (такий собі препроцесор) який використовує Arduino framework, потім компілює вже стандартним компілятором Arduino і збирає/асемблює з цього бінарну прошивку. Окрім описів і правил в YAML ESPhome можна напряму використовувати код "С" через lambda: - це може бути один рядок коду або цілий фрагмент, в якому можна оперувати об'єктами і змінними ESPhome. Це часто використовується коли в об'єкті (класі) ESPhome немає тих методів або фукнцій які вам потрібні для обробки змінних, тоді ви використовуючи класичний синтаксис "С" можете напряму "працювати" з змінними об'єкту ESPhome. Це якщо,... ну дуже коротко...

Взагалі при використанні VM/CT, не важливо що за гіпервізор ви використовуєте VMWare/Xen/Proxmox/VirtualBox..., на продакшині старайтесь користуватись простим правилом - один сервіс - одна VM/CT. Усілякі універсальні "комбайни" тільки ускладнюють адміністрування, пошук проблем і тягнуть за собою при падінні усі сервіси які обслуговує така VM/CT. У тому-ж Proxmox дуже непогано організовано управляння/розподілення RAM між CT. Воно на практиці дозволяє виділити RAMу для CT навіть більше ніж її є фізично на хості з Proxmox. Він доволі стабільний - у мене в управлянні є хост під Proxmox в датацентрі Hetzner, на якому крутяться в різні часи від 30 до 64 VM/CT, причому більша частина з них на публічних IP які "дивляться у світ", і мають свої DNS які публічно резолвяться. Так от uptime у нього більше 5-ти років

А... забув дописати - не треба ці диски по sambа моунтити до проксу і потім прокидати у CT - їх треба моунтити по samba в самих CT. В CT контейнері: apt install cifs-utils Далі як зазвичай - www.naturalborncoder.com/2023/07/mounting-a-samba-share-under-debian/

В такому випадку тільки варіант ставити "Samba share", з офіційного магазину додатків HA, шарити через smaba. Документації в інеті повно. Усе давно розписано

Трохи кривувато... але має місце для існування. Ваша проблема досить легко вирішується штатними інструментами Proxmox. Серед властивостей в Options буль-якої VM або CT є пункти: - Start at Boot: Yes/No - запускати VM/CT при старті Proxmox - Start/Shutdown order - тут задаєте в якому порядку запускакати - першим - 1, другим - 2 і т.д. і задаєте Delay (затримку) яку зробить Proxmox після запуску цієї VM/CT до запуску слідуючої. Це треба якщо у вас "важка" VM/CT і їй треба час щоб окрім старту запустити усі свої сервіси. При шутдауні Proxmox все йде в зворотньому порядку - принцип стека - "першим прийшов - останнім пішов" У вашому випадку поставте для медиа серверу order=1,up=10 (завантажити першою і почати вантажити інші після старту першої через 10 сек), а інші VM/CT далі по номерам 2,3,... Ті які використовують сервіси які стартують на першій VM/CT ставте в кінець

Це рішення, доречі дозволило в межах сім'ї повністю відмовитись від комерційних хмар Apple/Google/Microsoft і тримати персональні данні, фото, відео виключно локально. Раз на неділю уся папка з данними серверу NextCloud, скриптом архівується, шифрується AES-512 і після цого перекидіається на підключений по юсб до серверу NextCloud HDD 2Tb... про всяк випадок...

Для таких задач (синхронізація данних, фото, відео, контактних книг і т.д. з телефонів під Android/iOS) як у вас найбільше з OpenSource рішень підходить NextCloud - nextcloud.com/blog/nextcloud-hub9/ Сервер NextCloud ставиться легко в Docker. На виході отримаюте приватну хмару обмежену тільки розміром дискового простору який готові для цього виділити. На ПК/ноутах/планшетах/смартах під Windows/Linux/Android/iOS ставляться додаток NextCloud який ви коннектите до свого серверу NextCloud який синхронізує вибрані вами на пристроях теки. Після цього якщо на будь якому пристрої доєднаному до вашого серверу NextCloud щось змінилося ця зміна одразу синхрониться по всіх пристроях: - зробили фотку на смарті - вона додається на ПК в теку синхронізації. - на ПК написали щось у Word або склали таблицю в Exel кинули в теку яка налаштована як синхронізована з NextCloud і ці файли доступні на смарті NextCloud веде логи що і коли додано, редаговано, видалено. Є система версіювання. Є система корзин і т.д.

Ще є варіант спробувати відслідкувати на стороні ESP що там з WiFi за допомогою вбудованого ESPhome логгінга: Код YAML: logger: level: VERY_VERBOSE Скомпілюйте та "закиньте" в ESP. Після старту ESP в лог "посипеться" дуже детальна інфа. Не закрівайте це "вікно". Інфи буде дуже багато. Як відвалиться ESP, клікаєте "Download Logs" і тоді файл "в студію"

"Хворі - не займайтесь самолікуванням!"😄 Цей велосипед вже давно винайшли і назвається він аналіз! Ставте на звичайний андроїд смарт (певен що iOS таке теж є) будь який з додатків аналізу WiFi мереж (їх є вагон). Для прикладу - play.google.com/store/apps/details/WiFiAnalyzer_open_source?id=com.vrem.wifianalyzer&hl=uk, і буде вам щастя Цей додаток вам розгорнуто покаже що з каналами в вашій локації. Наскільки який завантажено, рівні сигналів, співвідношення сигнал/шум та ще й надасть рекомендації стосовно того які канали бажано використовувати в вашій локації.

Від блоку живлення великої потужності для живлення ESP не потрібно - для "голої" ESP32 5W абсолютно достатньо (це майже двократний запас). Від блоку живлення важливо отримати "красиві" 5V, як я писав - "стабільне, без просадок і викидів, шуму та гармонік" P.S. Ще що приходить в голову, зважаючи на досвід. В прошивках "побутових" роутерів часто реалізують TCP/IP стек не слідуючи на 100% вимогам IEEE. З чим стикався сам - були випадки (у друзів/знайомих) коли в мережі були пристрої яким призначали статичні IP, при цьому адреси які були статично прописані "попадали" в пул адрес які були виділені для DHCP. В таких випадках, в мережах, побудованих на "побутових" роутерах починаються "дивні речі" - по суті поведінка така: Пристрій з статичною адресою підключений і "тримає" неактивні сессії TCP/IP, в цей час DHCP надає по запиту пристрою що підключається, адресу яка "зайнята статикою" і цей пристрій її приймає. Після цього в мережі "співїснують" два пристрої які "бодаються" за один і тойже IP - то відвалюються то з'являються то один то інший девайс. В сімействі стандартів IEEE 802.X це все передбачено і є чіткі регламенти та правила як цього уникнути - але китайці не завжди їх реалізують (ні на програмному ні на аппаратному рівні). Спробуйте відключити живлення ESP та спроскануйте свою мережу (наприклад Nmap). Потім "зашийте" в ESP, достовірно вільну, статичну адресу яка не входисть в пул DHCP адрес. Для прикладу фрагмунт коду YAML для ESPhome який за це відповідає: wifi: ssid: !secret wifi_ssid # ваша wifi мережа password: !secret wifi_password # пароль до неї fast_connect: true manual_ip: static_ip: 192.168.10.98 # ваша достовірно вільна IP gateway: 192.168.10.1 # IP вашого роутера subnet: 255.255.255.0 # маска мережі dns1: 192.168.10.1 # адреса DNS

Тут досить важко, без додаткової статистичної інформації по WiFi мережі, щось кваліфіковано та достовірно рекомендувати. Пристрої Xiaomi мені не знайомі в користуванні, але як я розумію детального логування та притомного моніторінгу там нема. Точніше він є, на рівні ядра Linux на якому і побудована прошивка Xiaomi (як і усіх інших), але це обладннаня для "домогосподарок", а їм за задумом виробника це не потрібно. Хоча я можливо і помиляюсь стосовно Xiaomi. Якщо там є пристойне логуваня то я насамперед уважно подивився на нього, відфільтрувавши log по MAC/IP вашої ESP. Також можна спробувати замінити блок живлення на щось гарантовано якісне - стабільне, без просадок і викидів шуму та гармонік в 5V

Можу вставити свої, невеличкі, три копійки в дискусію по стабільності ESP32/ESP8286 і не тільки - просто ділюсь досвідом. В моєму кейсі розумного будинку, наразі, експлуатується 68 шт. різних пристоїв на ESP. Приблизно половина з них, це перешиті, прямо "з коробки" в ESPhome, "фабричні" Sonoff (дімери/реле і інше). До деяких Sonoff допаяні додаткові датчики. Усі інші - це різноманітні кастомні рішення. Для найбільш критичних застосувать (управління опаленням, електропостачанням, водопостачанням, безпека та інше) застосовуються ESP модулі з Ethernet під RJ45 на борту (www.aliexpress.com/item/1005007637656362.html). Таких пристроїв 10 шт. Використання ESP з RJ45 зроблено свідомо, через "професійну деформацію" яка пов'язана з 30-ти річним стажем роботи в IT. Останніх років 10 це побудова та експлуатація корпоративних мереж та IT інфрастуктур. За 4 роки експлуатації якихось значних, не вирішувальних, траблів в моїх кейсах не зафіксовано. Що було: - 2 випадки коли були "криві" і нестабільні модулі ESP закуплені в одній "партії", і ці трабли були вирішені банальною, прямою заміною модулів з іншої партії. - у деяких реле Sonoff MiniR2 (ESP8286), на четвертому році експлуатації, почала "надуватися" ємность яка є всередині модулів в ланцюгу живлення (470µF x 16V). Вона там трохи "дешманьська" - купив жменю полімерних електролітів LowESR 105°C SAMWHA - та по ходу перепаюю як виходять з ладу. На сьогодні це 3 різні реле. - 2 випадки "кривих" БП живлення "а-ля" USB зарядки 5V для телефонів. Заміна на нормальне живлення (зараз в кастомних рішеннях використовую виключно Hi-Link HLK-5M05 - arduino.ua/prod6602-modyl-jivlennya-hlk-5m05-220v-5v-5vt) стабілізували роботу ESP. Оце і всі "хардварні" трабли з ESP, з якими я стикався за 4 роки, з більш чим півсотнею модулів. Тепер програмна частина і WiFi. В останніх версіях (десь вже більше року) ESPhome, в частині WiFi, профіксили майже весь стек WiFi для ESP32/ESP8286. В Pull requests проекту, стосовно проблем з WiFi для ESP32/ESP8286 майже тихо. В changelog версій (github.com/esphome/esphome/releases), також, стосовно fix/bugfix WiFi, останній рік (для ESP32/ESP8286) - тиша. Наразі, як і було з самого початку, з WiFi підключенням ESP все стабільно. Домашня мережа, в WiFi частині, побудована на обладнанні Mikrotik. Її "тримають" 6шт. AP Mikrotik RBcAPGi-5acD2nD під керуванням CAPsMAN на RB3011UiAS. WiFi мережа з IoT пристроями розумного будинку ізольована від "світу", і її "напряму бачить" (вона в окремому VLAN) тільки один з віртуальних інтерфейсів HA, який "крутиться" на VM у Proxmox. Ця WiFi мережа використовує найбільш "вільні" номери каналів 2.4Mhz (з урахуванням досить не малих 2-х мереж Zigbee 2.4Mhz - зараз це >100 пристроїв) які є в моїй локації. Інші WiFi ("домашня" і гостьова) працюють на інших каналах, і в своїх VLAN (знов "професійна деформація"). Правда "домашня" мережа WiFi зараз працює, виключно, на частоті 5Mhz, а пару каналів 2.4Mhz "віддав" під гостьову WiFi. Звичайно перед розподіленням каналів (частоти 2.4Mhz) пройшовся з "аналізатором" (звичайний телефон на Android + app WiFiAnalyzer) по дому та "накидав" план розміщення AP, частот зважаючи на рівні співвідношення сигнал/шум на каналах. Уся ця "кухня" моніториться Zabbix-ом, і в разі коли десь в IoT сегменті виникають трабли (Drops/Error/Reconnect/Collision та інше), Zabbix одразу маякує мені в Email та Telegramm. Навіть з моїм, як ви бачите, трохи "параноїдальним" (як для домашньої мережі підходом) можу констатувати - все біль ніж стабільно. Прямо зараз до WiFi мереж мого будинку доєднано 102 пристрої - фото додаю P.S. На цьому форумі, в іншій гілці, я писав про свою реалізацію інтеграції HA і Deye: На доданому фото видно розміщення "коробочки" з модулем ESP32 з "об'язкою" RS-485 та 2хCAN. Усе прямо під інвертором, в ~5-ти сантиметрах від WiFi антени логгера Deye - з серпня це рішення стабільно працює, без жодного "відвалу". ESP32 доєднано до мережі по WiFi, оскільки на момент реалізації "в тумбочці" закінчились WT32-ETH01 а кортіло дуже сильно. В подальшому скоріш за все заміню на WT32-ETH01 коли "доїдуть" бо рахую, що мойому випадку, ESS система (інвертор+панелі+батареї) є частиною критичної інфраструктури дому.