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" і тоді файл "в студію"