xkansler

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

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

Не буду Вас навертати до секти "прихильників локальних систем управління розумними будинками (РБ)" (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.