Дом сам выбирает между солнцем, батареей, сетью и генератором
Лаборатория

Дом сам выбирает между солнцем, батареей, сетью и генератором

Электричество в доме приходит сразу из четырёх мест

Мой дом работает на автономной и резервной энергетике. Днём основной источник - солнечные панели. Городская сеть используется, когда она доступна и выгоден ночной тариф. Генератор остаётся резервом на период без солнца и сети. Большой литиевый аккумуляторный банк связывает эти источники во времени: запасает энергию и отдаёт её дому позже.

Цель - не максимальная автономность на красивом графике, а электричество при отказе любого отдельного источника. Ночь убирает солнце, сеть может исчезнуть, генератор требует топлива и обслуживания, батарея имеет конечный заряд. Устойчивость появляется только тогда, когда они подхватывают друг друга.

Железо я собирал и настраивал для собственного дома сам. Разбирался не только в интерфейсе инвертора, но и в устройстве станции: заземлении, поведении панелей при разном освещении, аккумуляторах и реальной выработке. Поэтому программный слой вырос поверх системы, устройство которой мне знакомо физически, а не только по документации производителя.

Три производителя показывали три разные части картины

Инвертор, система управления батареей и счётчики потребления выпущены разными компаниями. Инвертор общается по Modbus, батарея - по Bluetooth, счётчики - по локальной сети. Штатное приложение каждого производителя видит только собственное устройство.

Из трёх экранов невозможно понять, что происходило в один и тот же момент. Инвертор показывает поток через себя, батарея - своё состояние, счётчик - нагрузку. Для вопросов "хватит ли заряда до утра" или "сколько стоил киловатт-час, накопленный от солнца" данные нужно сопоставить на одной временной шкале.

Вендорские облака и Wi-Fi-модули для этого не подошли. Они обновляют данные редко, зависят от интернета, не дают свободно работать с сырой историей и остаются закрытым контуром производителя. Поэтому поверх оборудования появился собственный слой сбора, хранения и управления.

У батареи появился отдельный переводчик

Основной сборщик работает на Raspberry Pi как Python-скрипт. Он опрашивает инвертор по Modbus и получает показания сетевых счётчиков. Bluetooth батареи обслуживает отдельный узел на ESP32 с собственной прошивкой.

ESP32 находится рядом с аккумуляторными банками, читает их систему управления и передаёт данные на Raspberry Pi. Это позволило не тянуть провод через весь объект и отделить канал батарей от основного контроллера. При нескольких независимых банках у оборудования появляется локальный переводчик, а проблема одного узла не останавливает остальные источники.

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

Показание сначала попадает на диск и только потом на сервер

Связь и питание пропадают как раз во время событий, которые важнее всего для анализа энергосистемы. Если датчик пишет только в облако, блэкаут оставляет в истории пустое место и скрывает поведение оборудования в аварийный момент.

Raspberry Pi сначала сохраняет все значения в локальную базу. При доступном сервере накопленное уходит в QuestDB. Если соединение исчезло, запись на объекте продолжается, а после восстановления данные досылаются без дублей.

История переживает отсутствие сервера

Локальный сбор не зависит от интернета. Показания остаются на Raspberry Pi и переходят в центральную базу после восстановления связи.

За обновлением датчиков следит отдельная проверка. Если источник перестал присылать новые значения, система сначала переподключается к нему. Часть пропуска можно восстановить по соседним измерениям, потому что потоки оборудования частично перекрываются. Избыточность здесь помогает обнаруживать неисправность и закрывать отдельные пробелы.

Такой подход дал 98% аптайма сбора при перебоях связи и питания. Оставшиеся ограничения не скрываются: если сам источник не измерил значение и рядом нет достаточных данных, точное показание из ничего не появится.

Секундная телеметрия живёт отдельно от обычных данных

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

Телеметрия поэтому отправляется в QuestDB, специализированную базу временных рядов. Она быстро строит графики за месяцы на доступном железе. Настройки, справочники и другие данные приложения не смешиваются с секундными измерениями.

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

Возможность Собственный контур Облако производителя
Частота данных Секундное разрешение Обновление через минуты
Работа без интернета Локальная запись продолжается Зависит от внешней связи
Владение историей Сырые данные остаются у владельца Доступ определяет вендор
Сопоставление устройств Инвертор, батарея и счётчики на одной шкале Каждое приложение видит своё устройство
Управление Команды возвращаются на инвертор В основном просмотр штатных показаний

Ночью решение принимает батарея, а не напряжение инвертора

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

Так банк добирает недостающее ночью и встречает утро с запасом, а днём дорогая сетевая энергия не расходуется без необходимости. Команда отправляется инвертору по Modbus - тому же каналу, через который читается его состояние.

Ключевая деталь находится в источнике уровня заряда. Решение использует данные системы управления батареей и её кулонометра, а не напряжение, которое видит инвертор.

Судить о заряде литий-железо-фосфатной батареи по напряжению - всё равно что определять уровень топлива по звуку двигателя.

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

Между 20% и 90% разница измеряется сотыми долями вольта. По такому сигналу трудно отличить наполовину заряженный аккумулятор от почти пустого. Инвертор точно знает прошедший через него поток энергии, но остаток внутри батареи надёжнее оценивает BMS, и это разделение ролей защищает автоматику от ошибки каждую ночь.

Порог в 70% сам по себе является настройкой. Инженерный смысл имеет то, с чем он сравнивается.

У запасённой энергии появилось происхождение и цена

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

Это позволяет оценить долю солнечной энергии в текущем банке и честную стоимость киловатт-часа, который прошёл через аккумуляторный буфер. Ни одно отдельное устройство не видит такую картину, потому что она складывается на стыке генерации, заряда и потребления.

Новый расчёт или правило добавляется небольшим скриптом поверх общей телеметрии. Не нужно ждать функции в облаке производителя или менять ядро сбора. Собственная история становится материалом для ответов на практические вопросы: хватает ли банка до утра, нужны ли дополнительные панели и как меняется экономика режимов.

Домашняя система показывает не только красивый дашборд

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

Дом получил непрерывную общую картину источников и нагрузки. Режим переключается автоматически, решения о расширении панелей и банка опираются на измерения, а разница ночного тарифа становится дополнительной экономией. При этом система остаётся у владельца и допускает новые правила без зависимости от дорожной карты вендора.

4
источника страхуют друг друга: солнце, сеть, генератор и батарея
1 сек
разрешение телеметрии против минут в облаке производителя
98%
аптайм сбора при перебоях связи и питания

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

Следующее правило уже не требует новой платформы

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

К оборудованию можно подключить небольшой экран или индикатор для мониторинга на месте. Датчики температуры внутри и снаружи дома и освещённости позволят искать связи с выработкой и потреблением. На накопленной истории возможны счётчик экономии, прогноз генерации, оценка износа банков по циклам и обнаружение аномалий.

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

Есть и практическая граница моей работы. Эту станцию я смонтировал для себя, чтобы понимать систему изнутри, но монтаж энергетических установок как услугу не предлагаю. Моя профессиональная часть здесь - программный сбор данных, мониторинг, расчёты и автоматика поверх существующего оборудования.

Александр

Александр

Fullstack-разработчик с 8+ годами опыта - от промышленной автоматизации и работы с оборудованием до электронного документооборота и чат-ботов. Сейчас фокус на прикладном ИИ - от RAG-платформ для диалоговых ботов до компьютерного зрения.

Наш собственный проект

Это наш проект, поэтому показываем его внутреннее устройство без оговорок - вплоть до архитектуры и кода.