xkansler

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

Вибачте, я не Вам адресував це цитування - по Вашим постам і репутації я розумів що Ви знаете про ці речі... Просто пішло активне обговорення за зовнішній СТ, і було видно що нема повного розуміння нащо вони, які функції виконують. Ваш пост був останній в якому було про СТ тому я до нього "приатачив" цитату щоб народ не гортав форум сильно назад..

Вибачаюсь... але мені здається що тут є не повне розуміння для чого цей СТ. В самому інверторі (на платі) після клем GRID стоять (в однофазному стоїть) свої вимірюючі струмові трансформатори (СТ). Якщо ПЕРЕД інвертором щось підключено (наприклад бойлер) то СТ треба ставити ЗА ЦИМ підключенням для того щоб інвертор: - в разі коли він працює в режимі без "продажу до СТ" (Zero Export to CT) коли "є сонце" і його вистачає на заряд батарей (або батареї вже разяджені) + живлення усього що підключенно до LOAD він давав струм (живлення) на GRID до рівня що не буде давати перетоку струму в зовнішню мережу. От цим зовнішнім СТ він і контролює цей струм. Тобто інвертор буде "старатися" зробити так щоб на зовнішньому СТ було 0А. - в разі коли у вас ЗТ, "є сонце" інвертор за допомогою цього СТ рахує вати які він відгрузив в мережу - бо інакше він не бачить що щость і скількти споживає між ним і мережею. Якщо у вас нема ЗТ, і перед інвертором нічого не стоїть (або ви не хочете "живити сонцем" те що підключено перед інвертором) ви в налаштуваннях ставите Zero Export to Load - в цьому випадку ви можете не підключати зовнішній СТ.

Це "інтерфейс"/"перехідник" (хто як хоче нак і називає) який пересилає (в обидві сторони) данні USB <-> CAN. Причому гаджет має два незалежних канали CAN. Тут є огляд - microsin.net/programming/arm/usb-can-canalyst-ii.html Софт LVESS який використовується Deye для роботи зі своїми з аккумуляторами штатно працює з цим пристроєм. Але Вам ніхто не забороняє використовувати його будь де - наприклад сканування CAN шини та управляння через CAN в будь-якому сучасному авто, налаштування інших батарей з CAN, і т.д. - головне щоб програмне забезпечення яке Ви використовуете було сумісним з цим гаджетом.

Якщо детально все розписувати то це не на одну сторінку. Тема досить специфічна і широкому загалу мабудь не дуже цікава. Для таких речей треба створювати окрему гілку... У Томаса є, достатньо в деталях, розкладена тема по CANalyst-II USB: У людей з ПАР є непоганий форум де є така тема по інтеграції батарей Deye з HA, з розпіновками, кодом та з посиланнями на проєкти на github - powerforum.co.za/topic/20233-deye-se-g51-pro-batteries/#comment-173355 В доданих PDF є повний опис протоколів. Программу для роботи з батареями (LVESS) можна запросити в підтримці Deye - вони її без проблем дають. Modbus_Deye.pdf

Це нормальне рішення. Варіантів USB -> RS-485 є дуже багато, навіть в Україні за доступною ціною. Приклад - arduino.ua/prod2773-preobrazovatel-rs-485-na-usb-ch340 Якщо HA "поряд" (хоча для RS-485 по UTP-Сat5 100m не відстань) то все буде норм працювати. Я якщо в USB MiniPC "ткнути" - www.aliexpress.com/item/1005006462859187.htm (це доречі рекомендований підтримкою Deye гаджет) то зможете "рулити" і батареями (і через InterCAN, і через PCS)

Не всі. Ті що можливо ви вже українізували. Якщо треба феншуй то є два шляхи самому правити мовний файл компоненту "sunsynk-power-flow-card" 1-й. В теці компоненту "localize/languages" створити файл ua.json і заповнити його взявши для прикладу файл ru.json в тій же теці. Цей варіант має недолік - після кожного оновлення sunsynk-power-flow-card скоріш за все цей файл доведеться "докидати" по новому 2-й. Доєднатись до спільноти проєкту sunsynk-power-flow-card або написати в "Pull requests" проєкту, прислати їм переклад (ua.json) з метою щоб український мовний файл став "штатним" для компоненту sunsynk-power-flow-card

Так! І їх досить багато. Для прикладу: Усі власники Deye знають що у інвертора немає функціоналу обмеження рівня SoC батарей коли він заряджає від PV (принаймі мій не вміє). Від сонця (при його достатній наявності) інвертор завжди заливає до 100% SoC. Постійно "заганяти" і "тримати" SoC в 100% на LPF батареях не найкраще рішення с точки зору деградації комірок. Більш того в кінці заряду (99% -> 100% SoC) він "гонить" в батареї струм 10А що на самомому кінці заряду дає досить різке зростання напруги на комірках і як наслідок сильне розбалансування комірок (180mV і більше) - це все считує ESP прямо з батарей, а HA "малює" мені графіки. Я писав в підтримку Deye (і не тільки я) про це... Але відповідь Deye приблизно така - ми знаємо... не партесь. Але виробник комірок (в моєму впадку ЕVE, про що сповіщає сама BMS батареї) в даташтах рекомендує інше. В цьому випадку управління цим процесом можливо тільки шляхом обмеження загального струму заряду баратей в меню інвертора. Ось цей процес у мене і автоматизовано ESP постійно моніторить SoC, струм, та "розбіг" комірок. Автоматизація не дозволяє "накачувати" SoC більше 97% і зменшує струм (шляхом обмеження загального струму заряду даючи каманди інвертору) в кінці (після 94%) плавно з 10А до 4А (мої ВМS балансують 2-ма А) а після досягненна 97% встановлюється струм заряду 0А. З таким алгоритмом заряду я не бачив пік "розбігу" комірок більше 25mV. Такий рівень розбігу балансується BMS до рівня 2-3mV за 10-20 хв. Це тільки один в кейсів по автоматизації на самій ESP. Сервер HA в ній не задіяно, хоча його автоматизаціями це теж можна реалізувати P.S. Хоча мої батареї були куплені одночасно, виготовлені вони в один місяць (по шилдику) і мають досить "близькі" серійні номери, за 5 місяців експлуатації вони вже відрізняються - на скрінах - загальний заряд/розряд. Тобто вони з коробки не були ідеєнтичними а надалі будуть ще більш не однаковими. Як наслідок коли іде процесс зарядки і інвертор має встановлений загальний струм заряду 100А по батареях він розподіляється не однаково - наприклад одна забирає 55А a інша 45А. В моєму кейсі ESP відслідковує ці речі і знижує загальний струм заряду інвертора до рівня коли максимальний струм заряду, на будьякій батареї, не перестане перевищувати рекомендований струм 50А (0.5С)