Будинок сам обирає між сонцем, батареєю, мережею та генератором

Електрика в будинку надходить одразу з чотирьох місць

Мій будинок працює на автономній та резервній енергетиці. Удень основне джерело - сонячні панелі. Міська мережа використовується, коли вона доступна й вигідний нічний тариф. Генератор лишається резервом на період без сонця та мережі. Великий літієвий акумуляторний банк пов'язує ці джерела в часі: запасає енергію та віддає її будинку пізніше.

Мета - не максимальна автономність на гарному графіку, а електрика при відмові будь-якого окремого джерела. Ніч прибирає сонце, мережа може зникнути, генератор потребує пального й обслуговування, батарея має скінченний заряд. Стійкість з'являється лише тоді, коли вони підхоплюють одне одного.

Залізо я збирав і налаштовував для власного будинку сам. Розбирався не лише в інтерфейсі інвертора, а й у будові станції: заземленні, поведінці панелей за різного освітлення, акумуляторах і реальному виробітку. Тому програмний шар виріс поверх системи, будова якої мені знайома фізично, а не лише з документації виробника.

Три виробники показували три різні частини картини

Інвертор, система керування батареєю та лічильники споживання випущені різними компаніями. Інвертор спілкується по Modbus, батарея - по Bluetooth, лічильники - по локальній мережі. Штатний застосунок кожного виробника бачить лише власний пристрій.

З трьох екранів неможливо зрозуміти, що відбувалося в один і той самий момент. Інвертор показує потік крізь себе, батарея - свій стан, лічильник - навантаження. Для питань "чи вистачить заряду до ранку" або "скільки коштувала кіловат-година, накопичена від сонця" дані потрібно зіставити на одній часовій шкалі.

Вендорські хмари та Wi-Fi-модулі для цього не підійшли. Вони оновлюють дані рідко, залежать від інтернету, не дають вільно працювати із сирою історією та лишаються закритим контуром виробника. Тому поверх обладнання з'явився власний шар збору, зберігання та керування.

У батареї з'явився окремий перекладач

Основний збирач працює на Raspberry Pi як Python-скрипт. Він опитує інвертор по Modbus і отримує показання мережевих лічильників. Bluetooth батареї обслуговує окремий вузол на ESP32 із власною прошивкою.

ESP32 розташований поряд з акумуляторними банками, читає їхню систему керування та передає дані на Raspberry Pi. Це дало змогу не тягнути провід через увесь об'єкт і відокремити канал батарей від основного контролера. За кількох незалежних банків в обладнання з'являється локальний перекладач, а проблема одного вузла не зупиняє решту джерел.

Три протоколи перетворюються на один потік. Після цього новий розрахунок може одночасно використовувати заряд батареї, режим інвертора та споживання будинку, не намагаючись синхронізувати вивантаження з різних застосунків вручну.

Показання спершу потрапляє на диск і лише потім на сервер

Зв'язок і живлення пропадають якраз під час подій, які найважливіші для аналізу енергосистеми. Якщо датчик пише лише в хмару, блекаут лишає в історії порожнє місце й приховує поведінку обладнання в аварійний момент.

Raspberry Pi спершу зберігає всі значення в локальну базу. За доступного сервера накопичене йде в QuestDB. Якщо з'єднання зникло, запис на об'єкті триває, а після відновлення дані досилаються без дублів.

За оновленням датчиків стежить окрема перевірка. Якщо джерело перестало надсилати нові значення, система спершу перепідключається до нього. Частину пропуску можна відновити за сусідніми вимірами, тому що потоки обладнання частково перекриваються. Надлишковість тут допомагає виявляти несправність і закривати окремі прогалини.

Такий підхід дав 98% аптайму збору за перебоїв зв'язку та живлення. Решта обмежень не приховується: якщо саме джерело не виміряло значення й поряд немає достатніх даних, точне показання з нічого не з'явиться.

Секундна телеметрія живе окремо від звичайних даних

Потік з усіх датчиків за роки перетворюється на мільярди точок. Один акумуляторний банк за кілька місяців уже дав понад два мільйони записів. Зберігати цю історію як звичайні рядки застосунку й будувати за нею довгі графіки було б дорого й повільно.

Телеметрія тому надсилається в QuestDB, спеціалізовану базу часових рядів. Вона швидко будує графіки за місяці на доступному залізі. Налаштування, довідники та інші дані застосунку не змішуються із секундними вимірами.

Візуалізація також винесена в окремий шар. Збирач відповідає за отримання та зберігання, QuestDB - за історію, дашборд - за подання. Зміна графіка не втручається в опитування обладнання, а новий датчик не потребує переробляти весь інтерфейс.

Уночі рішення приймає батарея, а не напруга інвертора

Графіки самі по собі не роблять будинок автономним. Поверх історії працює правило нічної підзарядки. Поки фактичний заряд нижчий за 70%, система дозволяє інвертору брати енергію з мережі за дешевим тарифом. Після досягнення порога підзарядка вимикається, і будинок знову використовує сонце та акумулятор.

Так банк добирає нестачу вночі й зустрічає ранок із запасом, а вдень дорога мережева енергія не витрачається без потреби. Команда надсилається інвертору по Modbus - тим самим каналом, через який читається його стан.

Ключова деталь міститься в джерелі рівня заряду. Рішення використовує дані системи керування батареєю та її кулонометра, а не напругу, яку бачить інвертор.

У LiFePO4-комірки більша частина робочого діапазону виглядає як майже горизонтальна полиця напруги:

Між 20% і 90% різниця вимірюється сотими частками вольта. За таким сигналом важко відрізнити наполовину заряджений акумулятор від майже порожнього. Інвертор точно знає потік енергії, що пройшов крізь нього, але залишок усередині батареї надійніше оцінює BMS, і цей розподіл ролей захищає автоматику від помилки щоночі.

Поріг у 70% сам по собі є налаштуванням. Інженерний сенс має те, з чим він порівнюється.

У запасеної енергії з'явилися походження та ціна

Коли всі потоки перебувають в одній системі, поверх них можна будувати власні розрахунки. Так з'явився "енергетичний склад": заряд від сонця та від мережі обліковується окремо, а запас у батареї зберігає інформацію про походження.

Це дає змогу оцінити частку сонячної енергії в поточному банку та чесну вартість кіловат-години, яка пройшла крізь акумуляторний буфер. Жоден окремий пристрій не бачить такої картини, тому що вона складається на стику генерації, заряду та споживання.

Новий розрахунок чи правило додається невеликим скриптом поверх спільної телеметрії. Не потрібно чекати функції в хмарі виробника чи змінювати ядро збору. Власна історія стає матеріалом для відповідей на практичні питання: чи вистачає банку до ранку, чи потрібні додаткові панелі та як змінюється економіка режимів.

Домашня система показує не лише гарний дашборд

Найважливішими рішеннями виявилися довіра до кулонометра BMS замість зручної напруги та локальний запис замість прямого надсилання в хмару. Обидва майже непомітні в інтерфейсі, але саме вони визначають, чи прийме автоматика правильне рішення та чи лишиться історія після аварії.

Будинок отримав неперервну спільну картину джерел і навантаження. Режим перемикається автоматично, рішення про розширення панелей і банку спираються на виміри, а різниця нічного тарифу стає додатковою економією. При цьому система лишається у власника й допускає нові правила без залежності від дорожньої карти вендора.

Це особистий полігон, але його технічні частини застосовні й поза домом: Python-збирач, різнорідні протоколи, локальний буфер, часові ряди та зворотний контур керування. На промисловому обладнанні змінюються пристрої, масштаб і ціна помилки, а питання довіри до даних і поведінки без зв'язку лишаються знайомими.

Наступне правило вже не потребує нової платформи

Нічна підзарядка за 70% - один сценарій на готовій зв'язці "дані, рішення, команда". Поверх неї можна додати розклад режимів інвертора, email-сповіщення та локальну сигналізацію через ESP32.

До обладнання можна підключити невеликий екран чи індикатор для моніторингу на місці. Датчики температури всередині та зовні будинку й освітленості дадуть змогу шукати зв'язки з виробітком і споживанням. На накопиченій історії можливі лічильник економії, прогноз генерації, оцінка зносу банків за циклами та виявлення аномалій.

Це доробок, а не перелік уже готових функцій. Основа дає змогу підключати нове залізо й правила без заміни збору, буфера, QuestDB і керування.

Є й практична межа моєї роботи. Цю станцію я змонтував для себе, щоб розуміти систему зсередини, але монтаж енергетичних установок як послугу не пропоную. Моя професійна частина тут - програмний збір даних, моніторинг, розрахунки та автоматика поверх наявного обладнання.