xkansler

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

Не буду Вас навертати до секти "прихильників локальних систем управління розумними будинками (РБ)" (Home Assistant (HA), Domoticz, OpenHAB, NodeRED ets.), але навіть у міській квартирі для РБ завжди можна знайти гідне застосування. На сьогодняшний день, наприклад для НА, можливості практично безмежні і упираються вони не в власний функціонал а в "фантазії" і розуміння власника що йому потрібно і що йому хочеться! У вашому кейсі я, можливо, розвинув тему далі. Так WiFi свисток за ... це класно, але.. Спробуйте трохи "погратися" в РБ. Додайте до НА наприклад, можливість взаємодіяти, з пристроями на протоколі Zigbee (через ZHA або Zigbee2MQTT). Додавання Zigbee до HA це питання від ~$10 (за USB донгл) до ~$30 (за SLZB-06P або SLZB-06M). А далі: - наприклад, якщо у Вас стоїть тепловий лічильник, по Zigbee термометру ($5-$10) в кожну локацію, де є батарея, на яку Ви встановите Zigbee термостат (від ~$20). автоматизаціями ствоюєте "температурні" розклади - вночі наприклад в спальні 19°C (як на мене так комфортніше спати) а з ранку 21°C. Вдень можна "приспустити" температуру до 20°C, коли нікого вдома нема (датчики руху або присутності), і т.д. Таким чином отримаєте комфорт і в кінці місяця матимете профіт в рахунку за тепло. - маючи інтегрований в НА інвертор, Ви включивши через розумні Zigbee розетки (від $5) тих споживачів які "їдять" більше 500Вт зможете автоматизувати їх "апетит" в залежності від поточного стану SOC батарей або орківських атак (Ukraine Alarm) - у Квазіса ( ) є гарно розписані сценарії на цю тему. І так далі. Основна ідея цього допису полягає в тому що - встановив НА і "За 2.5 бакса зробив Wi-Fi-свисток", насправді є "з гармати по горобцям". НА це потужний інструмент за допомогою якого можна робити життя комфортнішим (не наступаючи на свій гаманець) а можна його використовувати "з гармати по горобцям". Але Ви в будь-якому випадку рухаєтесь в правильному напрямку, головне не зупиняйтесь... ))

Це все "форки" ноги яких ростуть звідси - ebusd.eu/

DS18B20 це класичний 1-Wire датчик. На малюнку "класична" схема підключення до esp8266/esp32 в "паралель" декількох DS18B20 на один "цифровий" pin. По досвіду на одиному "цифровому" піні в esphome стабільно працюють до 8-ми DS18B20. При більшій кількості на пін починаються "глюки" Якщо треба більше 8-ми підключити то просто "розкидуєте" на 2 піни. Наприклад для esp32 можна 8 шт. DS18B20 на Gpio15 і 8 шт. DS18B20 на Gpio14, і так далі поки піни/даласи не закінчаться;-( Конфіг/код YAML для esphome (esphome.io/components/sensor/dallas_temp.html) дуже простий (приклад для 16-ти DS18B20): -------------- # створюємо дві 1-Wire шини one_wire: - platform: gpio pin: GPIO14 id: one_wire_1 - platform: gpio pin: GPIO15 id: one_wire_2 # створюємо температурні сенсори на датчиках DS18B20 sensor: - platform: dallas_temp address: 0xEE3C01D0758DC821 # унікальна адреса датчика DS18B20 name: "Temp Sensor 01" one_wire_id: one_wire_1 accuracy_decimals: 2 # точність вимірювання до 2-го знака після коми .......тут по аналогії 2,3,4,5,6,7......... - platform: dallas_temp address: 0xEE3C01D0758DC828 name: "Temp Sensor 08" one_wire_id: one_wire_1 accuracy_decimals: 2 - platform: dallas_temp address: 0xEE3C01D0758DC831 name: "Temp Sensor 09" one_wire_id: one_wire_2 accuracy_decimals: 2 .......тут по аналогії 10,11,12,13,14,15......... - platform: dallas_temp address: 0xEE3C01D0758DC838 name: "Temp Sensor 16" one_wire_id: one_wire_2 accuracy_decimals: 2 Головне - кожен DS18B20 має свію унікальну адресу в форматі 0xEE3C01D0758DC821. Дізнатися адреси датчиків в esphome дуже просто. Спочатку в коді YAML вказуєте тільки секцію "one_wire", і робите "Install". Після того як скомпілюється і завантажиться в esp-шку прошивка дивитесь логи (прямо в інтерфейсі esphome). Як тільки прошивка "стартує", якщо все правильно підключено і датчики "живі" esp почне сканувати створені 1-Wire шини і відображати адреси "знайдених" датчиків (доречі на 1-Wire існує багато і інших датчиків тиску/вологості/струму/протоку і т.д). Ви маєте побачити щось на кшталт такого: ---------------- [04:44:23][I][app:100]: ESPHome version 2024.10.0 compiled on Oct 18 2024, 16:12:40 [04:44:23][C][logger:185]: Logger: [04:44:23][C][logger:186]: Level: DEBUG [04:44:23][C][logger:188]: Log Baud Rate: 0 [04:44:23][C][logger:189]: Hardware UART: UART0 ...... [04:44:23][C][gpio.one_wire:020]: GPIO 1-wire bus: [04:44:23][C][gpio.one_wire:021]: Pin: GPIO14 [04:44:23][C][gpio.one_wire:080]: Found devices: [04:44:23][C][gpio.one_wire:082]: 0xee3c01d0758dc828 (DS18B20) [04:44:23][C][gpio.one_wire:082]: 0x863c01d075e43328 (DS18B20) [04:44:23][C][gpio.one_wire:082]: 0x600121122fbf8022 (DS18B20) [04:44:23][C][gpio.one_wire:082]: 0xd83c63e381e54428 (DS18B20) [04:44:23][C][gpio.one_wire:082]: 0xd83c63e381e54431 (DS18B20) [04:44:23][C][gpio.one_wire:082]: 0xd83c63e381e5c511 (DS18B20) [04:44:23][C][gpio.one_wire:020]: GPIO 1-wire bus: [04:44:23][C][gpio.one_wire:021]: Pin: GPIO15 [04:44:23][C][gpio.one_wire:080]: Found devices: [04:44:23][C][gpio.one_wire:082]: 0xd83c63e381e54451 (DS18B20) [04:44:23][C][gpio.one_wire:082]: 0xd83c63e381e54319 (DS18B20) [04:44:23][C][gpio.one_wire:082]: 0xd83c63e381e54293 (DS18B20) [04:44:23][C][gpio.one_wire:082]: 0xd83c63e381e52387 (DS18B20) [04:44:23][C][gpio.one_wire:082]: 0xd83c63e381ebc517 (DS18B20) [04:44:23][C][gpio.one_wire:082]: 0xd83c63e381e5a412 (DS18B20) Це доречі реальній вивід лога в моїй системі контролю і управляння контурами теплих підлог. З цього виводу лога ви і берете адреси знайдених датчиків, додаєте в код YAML секцію "sensor", і підставляєте в "address:" адреси ваших рельних датчиків які ви отримали при виводі лога. Після цого інсталите новий YAML і отримуєте в HA свої температурні сенсори через інтеграцію ESPHome

Доречі забув вказати що бувають ситуації коли система має "глобальний" статус Partly Online (Partly Offline). Такий статус встановлюється коли якийсь (або декілька) з компонентів системи "відвалилися". Для прикладу: - у вас дві батареї підключені по CAN до інвертора і одна з них "відвалилася". - у вас два інвертора в паралелі і один з них "відвалилася". - у вас два інвертора в паралелі і один з них "втратив" грід. - і т.д. В таких випадках у Вас буде Partly Online. Далі "пробігшись" по вкладці Devices Ви зможете побачити що саме Offline а що Online.

Можу поділитися своїм досвідом (рішенням). Ще до встановлення гібрида Deye (з панелями та аккумами) у мене було зроблене резервування обладнання котельні (газ.котел + насоси + контроллер управляння тепл.підлогами + контроллер управління котлом по ebus + газова/"водяна" безпека) та IT пул (сервер HA + роутер + PoE комутатор ярда мережі + відеонагляд) з використанням відносно недорогого Victron MultiPlus II 500/12/20 + 2 х 100Ah свинцево-карбованих батареї (все інтегровано в HA через VE.Bus->MK2 - github.com/diebietse/invertergui) що надавало приблизно 2 години автономності системі. У мене є бензиновий інверторний генератор який також інтегрований в HA і повністю під його контролем. Раніше (до Deye) система бачила через інтеграцію Victron що зникла зовнішня напруга і коли батареї Victron розряджались до 50%, НА давав команду пуска генератору. Далі вже HA "приймав" всі рішення стосовно того коли глушити "гену". Зараз коли з'явивилась система ESS Deye я не відключав Victron а просто залишив його "підключеним за" Deye на виході Load (Grid -> Deye/Load -> Victron -> "HA/Котельня"). Тепер Victron виконує функцію "бекап бекапу" - тобто якщо з якихось причин Deye "втратив" грід і якісь трабли з його АКБ у мене HA продовжує працювати, вже тільки на Victron. Я трохи підправив логіку роботи HA з урахуванням цих змін, але суть залишилась таж сама - все під контролем HA який має надійне живлення. Основна ідея полягає в тому щоб "повісити" HA на своє джерело безперебійного живлення, яке стоїть за Deye, та підключене на його Load. Це надає можливість не втратити з'язок з HA у разі коли Grid або Deye "дуркує", і як мінімум, отримати сповіщення від HA про виникнення "нештатних" ситуацій і відреагувати на них з урахуванням своїх можливостей (напр. генератор). P.S. Замість Victron можна використати будь-який інвертор/зарідний+батарея, головне, на мій погляд з'язати його (наприклад через ESP) з HA, щоб він міг бачити хочаб приблизний рівнь заряду на батареї цього інвертора і чи отримує він живлення.

Скрін з додатку Solarman/DeyeCloud, який Ви надали, свідчить про те що логер підключений до хмари (Solarman/DeyeCloud). Якщо в додатку на смарті (або при доступі через браузер до Solarman/DeyeCloud) Ви на вкладці Devices -> Logger, бачите Status Online, це свідчить що він з'єднаний з хмарою. В противному випадку був-би статус Offline.

Тема має місце для існування... Але через деякий час, через те що HA це "дуже широко", там буде лебідь,рак та щука. Все що стосується HA то він має дуже багато файних ресурсів, починаючи з HA Community (community.home-assistant.io/) і закінчуючи тим-же Квазісом (https://www.youtube.com/c/AlexKvazis)... Там є інфа і про Deye але її треба "виловлювати". Я думаю що варіант Deye+HA має бути більш "профільним" і спорідненим з "Deye інвертори гібридні".

Є таке відчуття що гілка форуму з "Deye інвертори гібридні" потехеньку мігрує в сторону Deye - HomeAssistant. Deye+HA - тема безумовно цікава, корисна і дуже перспективна але для більшості товариства яке просто поставила собі Інвертор/PV/Батарею(ї) такі "розмови" можуть здаватися темними хащами які взагалі незрозуміло про що... і тільки захоращують гілку. Думаю для для Deye+HA треба створити свою гілку де "гіки", с точки зору пересічного власника Deye, зможуть на "своїй мові" ділитись своїм досвідом та думками... P.S. Я готовый бути активним членом такого комюніті, але мантейнером/адміном навряд, через мало прогнозований графік роботи і як наслідок наявністі вільного часу. Останні 10 днів він є, а наступні 10 дніє його може бути ніт.

Не зовсім так. Solar Forecast як зазначено в описі самої інтеграції (www.home-assistant.io/integrations/forecast_solar) бере данні в EU Photovoltaic (re.jrc.ec.europa.eu/pvg_tools/en/tools.html). Open-Meteo Solar Forecast (https://github.com/rany2/ha-open-meteo-solar-forecast?tab=readme-ov-file) бере данні з сервісу Open Meteo (https://open-meteo.com/) який є потужним агрегатором данних з різних джерел і своїм API. В своїх налаштуваннях я використовую обидві інтеграції беручи їх данні, і на базі них створюю свої темплейт сенсори, в яких на додаток до цих данних враховую власну статистику (поки не велику - липень-жовтень), тому-що дуб сусідів частково кидає тінь на частину моєго PV поля в період з 14:00 до 16:00. Останню неділю мої темплейт сенсори прогнозу відрізняються від реальності +/-10%. По мірі "реального" збирання статистики думаю що буде можливо довести похибку прогнозу до меньших розмірів.

Для Deye/Sunsynk тут все розписано - slipx06.github.io/sunsynk-power-flow-card/examples/sunsynk.html

Розкладів буде рівно стільки скільки їх є в меню вашого інвертора. Нові вона (інтеграція) не створює

"Пробіжіться" по моїм постам/цитуванням у цій гілці, я на всі свої пояснення давав посилання на джерела. Я можу викласти код. Але як я писав у мене частина логіки в самій ESP а частина в HA. Інтеграція самого інвертора і батарей йде через ESPhome (логер Deye взагалі ніяк в цьому не задіяно) тому і назви сутностей не такі які створює інтеграція Solarman - десь я їх робив такими-же, а десь робив іншими, більш як на мене зрозумілими. Тому мій код Вас може тільки заплутати.

YAML не складний, і доволі зрозумілий. А от Сі (через lambda) там зовсім не псевдо а нормальний класичний. Це питання досвіду та ваших "скілів"

В мене так і керується - НА дивиться на прогноз мого поля PV на завтра використовуючи Forecast.Solar (www.home-assistant.io/integrations/forecast_solar) і в залежності від цього приймає рішення заряджати батареї і до якого рівня від гріду після 23:00 (нічний тариф) або не заряджати а залишити на ніч як є а зранку нехай їх заряджає сонце. Це звичайно я написав в дуже спрощеному вигляді. Насправді у мене набагато складніші алгоритми які враховують статистичне споживання будинку у часи коли є сонце за попередні періоди, стан батарей, чи є тривога (Ukraine Alarm - www.home-assistant.io/integrations/ukraine_alarm) і т.д. і на базі цих данних приймаються рішення HA/ESP як керувати інвертором/батареями

Фізично це, в моєму випадку, виглядає так: В середині Box (див.фото): - ESP32 з кодом для ESPhome - RS-485 для комунікації з інвертором. - CAN трансивер SN65HVD230 - для комунікації з батареями через PCS порт батарей - CAN трансивер MCP2515 - для комунікації з батареями через InterCAN порт батарей (читає стан кожної комірки, кожної батареї)

Якщо треба змінити алгоритми автоматизацій, то да міняєте код YAML і компілюєте. Це робиться в 3 кліки з самої HA або через WEB "морду" яка крутиться на самій ESP. Якщо треба змінити параметри автоматизацій, в рамках діючого на ESP алгоритму (наприклад верхні/нижні межі якихось автоматизацій) то нічого перекомпільовувати не треба, все можна налаштовувати або з HA або через WEB "морду" ESP просто міняючи ці параметри. Звісно в коді YAML це все треба описувати/програмувати

Можна і без ESP, підключившись до логеру через інтеграцію Solarman по IP який ваш логер отримує в вашій "домашний" мережі використовуючи WiFi. Але я вже писав що в такому випадку вся логіка керування (автоматизації) буде виключно в HA. Якщо з HA щось стається (завис/щось выйшло з ладу/живлення) то всі керування теж "лягають". У випадку з ESP особливо важливі/критичні для вас керування ви "виносите" в код на ESP за допомогою ESPhome, а менш важливе, чи те що має взаємодіяти з HA залишаєте в HA. Поясню на простих прикладах: - автоматизація на стороні ESP постійно моніторить данні з інвертора по RS485 і керує струмом заряду і верхньою межою SoC батарей. Це працює на самій ESP без участі HA (його можна взагалі вирубити) - автомитизація вимикання розеток з потужними споживачами (які інтегровані в HA у вигляді розумних розеток/розумних реле і т.д.) коли GRID перейшов в OFF щоб не грузити аккум - це тільки на стороні HA з використанням автоматизацій, тому-що ESP ніяк "не бачить" ваші розетки/реле.

Все що можна налаштувати через меню інвертора можна налаштувати через HomeAssistant, якщо інвертор підключений по схемі - HA -> ESP32 (ESPhome) + RS485 -> Інвертор (на вхід CAN/BMS з батареї). На вході CAN/BMS (RJ45) інвертора фізично розведені і підключені як CAN шина так і RS485 От тут у поляка все розписано - hybrydaplus.pl/index.php/2023/09/19/komunikacja-deye-sun-10k-sg04lp3-eu/ А тут він розписав з кодом під ESPhome "Time of Use" - hybrydaplus.pl/index.php/2024/04/23/nowa-funkcja-dodajemy-kod-od-time-of-use/ Я вже наводив посилання, звідки всі "ноги ростуть": - аппаратно-програмна частина (ЕPS-ESPhome) - github.com/klatremis/esphome-for-deye - програмна частина "на стороні" НА (Дашборди, сенсори і т.д.) - github.com/slipx06/Sunsynk-Home-Assistant-Dash P.S. Було запитання про затримку зв'язки ESP-HA - її нема взагалі. Тобто вона взичайно є в межах швидкості RS485 та тої дискретносні з якою інвертор робить свої заміри і "публікує" на шинах CAN та RS485 ці данні. Більш того різні показники інвертор "публікує" з різною частотою - це все залежить від прошивки інвертора. Для прикладу струм PV та струм BAT мій Deye-5K (з прошивками HMI:C36F i MAIN:3386-1515) "публікує" з частотою раз на 15сек., а от напругу з GRID з частотою раз на 10сек.