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-ти років