xkansler

В цій темі форуму вже було достатньо розгорнуто обговорення цього кейсу -

Ось як працює 3-х фазна Deye (добовий графік потужності) Верхні графіки це те що "проходить" з/на Grid (зовнішня мережа). Як Ви можете побачити на всіх трьох фазах графіки абсолютно тотожні (насправді відхилення по фазах +/- 50Wt). Нижні графіки це те що "йде" на Load. Як Ви можете побачити графіки поживання на фазах сильно відрізняються. За цю добу (по графіках видно) було і споживання з мережі (плюсові значення), і продаж в мережу PV (від'ємні значення) - але Deye 3-х фазна все збалансувала "рівненько" на всіх 3-х фазах за рахунок опції налаштування - "Asymmetric phase feeding" * На усіх графіках є значення Min і Max (за добу) для розуміння рівня відхилень споживання і генерації

Я вже тут рекомендував - досить детально стосовно "upgrade/controll/tuning" батарей Deye розкладено на Південно-Африканському форумі. Там і схеми підключення "через" ESP (включно з варіантом ESP посередині для оптимізації зарядно/розрядних характеристик), і підключення додаткових балансирів (там якраз NEEY) з обґрунтуванням, схемами, графіками і т.д. powerforum.co.za/topic/20233-deye-se-g51-pro-batteries/page/2/

Так з версії за серпень 2025 року ESPNow є штатним компонентом ESPhome - esphome.io/components/espnow/ Попробував "на зуб" в сценарії ESP32+DS18B20 (зліпив вуличний датчик) який передає вуличну температуру контроллеру який керує газовим котлом Vaillant через eBus (esp32 + eBus adapter) - 2 неділі працює стабільно, далі спостерігаю

Дивна поведінка. Схоже що о 13:02 було перепідключення до WiFi. Спробуйте в конфігу yaml (для вашого Kincony) включити більш детальний лог саме WiFi компонента, десь так: logger: level: VERBOSE initial_level: ERROR logs: wifi: VERBOSE Також включіть сенсор Uptime щоб точно знати що не відбувається загального перезавантаження ESP: sensor: - platform: uptime type: seconds name: Uptime Sensor P.S. Якщо Ваш роутер працює в сильно "загаженому" радіо середовищі (багато сусідських роутерів, zigbee концентраторів, блютуз пристроїв та інше) то рівень RSSI (рівень сингалу) мало-інформативний. RSSI - це показник потужності Wi-Fi сигналу, що надходить до вашого пристрою. Набагато важливіше, і сильніше впливає на стабільність передачі данних - SNR (Signal to Noise Ratio - співвідношення сигнал/шум) - www.wireless-nets.com/resources/tutorials/define_SNR_values.html Якщо, для прикладу у вас роутер працює на 6-му каналі (частота 2.4Ghz) і ваша ESP показує RSSI -40dbi а за "стінкою" працює інший роутер теж на 6-му каналі (його сигнал для вашого роутера являється шумом) і в точці знаходження вашої ESP рівень сигналу цього роутера -45dbi то при начебто високому (-40dbi) сигналу ваш SNR усього 5dbi і при такому SNR передача данних майже неможлива. Це як ніби багато людей, в одній локаціЇ, одночасно дуже гучно розмовляють. Гучність є, а от розібрати про що йде мова майже неможливо. Так і з RSSI.

Тут досить детально розписано все що стосується OneWire, якраз на прикладі Dallas - mischianti.org/dallas-ds18b20-with-esp32-and-esp8266-all-onewire-topologies-long-stubs-and-more-devices/ В своєму випадку (оскільки використовую ESP32 то пінів вистачає) вішаю по даласу на пін. В принципі по 2-3 даласи на пін у мене теж стабільно працює на звичайній витій парі сигнального кабелю. Конфіги виглядають так: one_wire: - platform: gpio pin: GPIO14 id: heat_floor_temp_1 - platform: gpio pin: GPIO13 id: heat_floor_temp_2 - platform: gpio pin: GPIO32 id: heat_floor_temp_3 - platform: gpio pin: number: 33 mode: input: true output: true pullup: false id: heat_floor_temp_4 sensor: # Температура подачі з котла - platform: dallas_temp address: 0xEE3C01D0758DC828 name: ${upper_devicename} Temp Flow one_wire_id: heat_floor_temp_1 resolution: 12 unit_of_measurement: "°C" filters: - round: 2 - filter_out: nan - sliding_window_moving_average: window_size: 7 send_every: 4 send_first_at: 3 ........................................... # Температура подачі в контури теплої підлоги - platform: dallas_temp address: 0x863C01D075E43328 name: ${upper_devicename} Temp Floor Flow one_wire_id: heat_floor_temp_4 resolution: 12 unit_of_measurement: "°C" filters: - round: 2 - filter_out: nan - offset: -0.1 - sliding_window_moving_average: window_size: 7 send_every: 4 send_first_at: 3

Доречі ethernet на Kincony (LAN8720) дуже стабільний. За більше трьох років експлуатації їх серії Kincony KC868 жодного траблу і відвалу. Я Kincony по ethernet використовую в критичних інтеграціях - опалення, електроспоживання, ... все стабільно

У мене теж раніше ніяких траблів з ESP по WiFi небуло. А от десь 2-3 місяці тому виникли, при тому що обладнання WiFi не змінювалось і налаштування Mikrotik теж. Я не зафіксував з якої версії ESPhome це почалось, тому що після оновлення ESPhome я перекомпілюю не усі модулі, а тільки ті які використовують компоненти які є в оновлені, або коли є серйозні зміни в API ESPhome. Але на тих що перекомпілював з часом помітив періодичні "відвали". На форумах по ESPhome з'явилися повідомлення про трабли в стеку WiFi і різні варіанти рішення. Те яке я навів вирішило мою проблему. Я не стрерджую що у Вас такий самий трабл, але якщо перезапуску ESP не стається то скоріш за усе щось не так з WiFi. Як варіант сусіди могли заспамити канал який використовує ваша AP. Загалом в налаштуваннях WiFi ESPhome є досить багато параметрів - esphome.io/components/wifi/

В моєму випадку це не так. У мене декілька AP (точок доступу) Mikrotik які "тримають" мережу WiFi під керуванням контроллеру CAPs від тієїж Mikrotik. Контроллер CAPs в сучасній версії RouterOS V7 підтримує стандарти WiFi Roaming 802.11k/v/r (безшовний роумінг Wi-Fi). В інеті є багато інфи про 802.11k/v/r. Якщо дуже спрощено то це взаємодія клиентів і AP для підключення (перепідключення) до найбільш оптимальної AP з точки зору якості зв'язку і завантаженості AP які "тримають" WiFi мережу. Стек WiFi в ESPhome наразі не підтримує 802.11k/v/r тому в моєму випадку ESPшки іноді "чіпляються" до неоптимальної AP і тримаються за неї "до останнього". Спроби скидати коннект такої ESP на стороні контроллера CAPs не завжди (майже ніколи) не призводять до переконекту ESPшки до більш оптимальної AP. А от перезавантаження ESP або вимкнення->включення WiFi на ESP як правило, в моєму випадку, призводить до того що ESPшка підкючається до більш оптимальної AP. Але при перезавантаженні окрім перепідключення до нової AP скидаються стани усіх змінних, включно з globals, скидаються усі локальні лічильники і локальні автоматизації які працюють на ESP і т.д. При вимкненні->включенні WiFi цього не стається, після перепідключення ESP, HA, в моєму випадку, навіть "не помічає" цього, це видно тільки в логах ESP (logger.log: WiFi signal is too weak or not connected. Reconnecting...). Якщо у вас мережу WiFi "тримає" декілька AP (MikroTik/Kinnetic/TP-LINK/Ubiquiti etc.) то мій кейс може вам стати в нагоді.

Наскільки пам'ятаю у Вас Kincony A2 підключено по WiFi а не по UTP. У мене при оновленні HA та ESPhome з оновленням (перекомпіляцією) прошивок еспішок з якогось моменту (десь з 2-3х місяці назад) деякі еспішки теж почали іноді втрачати зв'язок (cумарно, наразі в моєму будинку "живе" 64 модулі на базі різних ESP). Трохи досліджував цю тему. Там щось трохи "накрутили" в WiFi стеку. Не вдаваючить в подробиці пристрій "тримається" за WiFi AP до "останнього". В моєму випадку (WiFi побудовано на 8-ми AP Mikrotik з використанням CAPs з доволі детальним моніторінгом усієї інфраструкрути) аналіз і експерименти привели до того що тепер в усіх конфігах ESPhome для пристроїв які підключені по WiFi я використовую локальну автоматизацію яка перезапускає WiFi на ESP у разі зниження рівня RSSI нижче -78dBi або втрати "коннекту". Виглядає це так: wifi: ssid: !secret wifi_ssid password: !secret wifi_password fast_connect: false power_save_mode: none manual_ip: static_ip: ${device_ip} gateway: 192.168.10.1 subnet: 255.255.255.0 dns1: 192.168.10.1 ap: ssid: ${upper_devicename} Fallback password: !secret ap_password sensor: - platform: wifi_signal name: ${upper_devicename} Wifi Signal Strength id: wifi_signal_sensor update_interval: 60s interval: - interval: 60s then: - if: condition: or: - not: wifi.connected - lambda: 'return id(wifi_signal_sensor).state < -78;' then: - logger.log: WiFi signal is too weak or not connected. Reconnecting... - wifi.disable - delay: 2s - wifi.enable В моєму випадку такий підхід вирішив проблему. Зараз усе стабільно.

😅... Мережевий є, як ви мабудь здогадались - SUN-15K-G05

Стосовно мережевих інверторів інших виробників (відмінних від Deye/Sunsynk), у мене немає точної інфи, хоча в інеті бачив подібні кейси з інверторами інших брендів. Наскільки ця інфа реальна важко стверджувати... Стосовно того що керування мережевим інвертором Deye/Sunsynk підключеним до Gen порту гібрида Deye/Sunsynk, який працює в режимі Microinvertor то це штатний функціонал, який описаний в документації інверторів Deye. Цей функціонал підтверджений діючою інсталяцією, конфігурацію якої я навів вище. Оскільки ми тут начебто в гілці "Deye інвертори гібридні", то мені видається, можливо, що починати досліджувати які "розклади" на цю тему у інших брендів не зовсім правильно, для цього є профільні гілки на цьому форумі або на інших. Мережеві інвертори Deye досить "бюджетні" відносно гібридів. ~$750 за трифазний SUN-15K-G05 доволі прийнятна ціна на якісний виріб для розширення гібридної системи

Не зовсім так. Там набагато цікавіше - гібрид при підключені мережевого інвертора на порт Gen (порт Gen режимі Microinvertor) за допомогою частоти доволі плавно може обмежувати або "відпускати" генерацію мережевого (при відсутності Grid) в залежності "потреби яка виникає" на Load або для заряду батарей: Зараз в такому режимі працює одна з інсталяцій (у мого товариша): три 5K гібридних однофазних в трифазній схемі (з синхронізацією фаз) + 15K мережевий трифазний у котрого фази відповідно розведені по портам Gen на 5К - все працює як швейцарський годинник

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