Теплый пол как единственное отопление: как мы спроектировали когнитивную систему на виртуальных термостатах

Почему обычные термостаты не справляются с водяным полом, и как архитектура из четырёх слоёв абстракций решает эту проблему

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

Первый — физический. Тёплый пол обладает огромной тепловой инерцией. Стяжка толщиной 7 см прогревается часами. Обычный термостат работает по простому принципу: «стало холодно → включили на полную → перегрели → выключили → остыли → повторить». Для радиаторов это работает. Для тёплого пола — это постоянные качели температуры, создающие ситуации горячий пол, холодный воздух, либо прогретый теплый воздух, остывший холодный пол. Это всё создаёт перерасход энергии и риски для финишного покрытия.

Второй — логический. Когда пол — единственное отопление, от его работы зависит всё. Не «чуть прохладно в спальне», а «в доме холодно». Ошибка в настройках, неучтённая инерция, неправильно работающий котёл — и вы это почувствуете всей семьёй, причём довольно быстро. Поэтому настройка системы должна быть абсолютно доступной и гибкой. Если вдруг что-то не было учтено или работает не так как предполагалось, надо не менять оборудование, а делать более тонкую настройку.

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

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

В этой статье я расскажу, как система устроена, может пригодиться кому-то, кто строит дом с тёплым полом как основным отоплением. Основная супер амбиция сделать систему по стоимости дешевле решения “везде хороший умный термостат”.

В программировании есть фундаментальный принцип — слои абстракции (layers of abstraction) и разделение ответственности (separation of concerns). Суть в том, что сложная система разбивается на уровни, каждый из которых решает свою задачу и не лезет в дела других.

Применительно к отоплению это означает: не надо пытаться сделать «умный термостат, который умеет всё и сразу». Надо разделить систему на слои, каждый из которых делает своё дело очень хорошо.

У нас получилось четыре разрабатываемых слоя. Пойдём снизу вверх — от физического железа к глобальной логике.

Самый низкий уровень — это то, что мы используем, учитываем, но не изменяем в условиях эксплуатации, у этого есть интерфейсы взаимодействия, мы их учитываем, осознаём, знаем, но никак не программируем, не пишем каких-то прошивок для устройств, используем то что они умеют из коробки. Частая ошибка реализация управления пользователем на этом слое. Пользователь как бы знает о том что включено, что работает и ходит и управляет именно этим, не желаемым состоянием, а включить/выключить котёл, включить/выключить насос, включить/выключить подачу тепла в зону. Так выглядят теплые полы без автоматизации, ходишь, крутишь руками, включаешь котёл, насосы, краны контуров открываешь, закрываешь сам. Как бы логика удалённого управления, а не автоматизации. Обычные термостаты уже этот слой позволяют преодолеть, но они нужны тогда в каждой зоне теплого пола, иначе остальными зонами остается управлять без автоматизации.

Итак, в каждой зоне у нас:

У нас 12 зон, включая микрозоны в кухне-гостиной. Каждая зона — это независимый физический контур со своим набором оборудования.

Почему на этом уровне уже возникают сложности?

Потому что физическое оборудование имеет свои ограничения, которые нельзя игнорировать:

Сервопривод инерционен. STOUT STE-0010 открывается и закрывается 3-5 минут. У него ресурс около 10 000 циклов. Если дёргать его каждые 2 минуты (как это делает обычный гистерезисный термостат), с него вообще никакого толка не будет.

Стяжка инерционна. Она не реагирует на команды мгновенно. Между подачей напряжения на сервопривод и изменением температуры в комнате проходят десятки минут.

Кварцвинил чувствителен к перегреву. Выше 28°C — уже риск. Нужен жёсткий аппаратный лимит, который нельзя обойти никакой логикой.

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

То есть уже на уровне железа мы понимаем: нельзя просто «подать 230В на сервопривод, когда стало холодно». Нужна более умная логика.

Эту логику реализуют следующие слои, а управление этим всем оборудованием осуществляет Wirenboard 8 и реле WBIO-DO-R1G-16. Именно через wb-rules скрипты вайренборда, будут осуществлять подачу фазы на сервоприводы, включение/выключение циркуляционных насосов и котла, получение информации с датчиков температуры стяжки по 1-wire, воздуха по RS-485 и данные с котла по EBUS интерфейсу.

Режимы — это ответ на вопрос «как именно мы регулируем отопление в одном контуре». Это чистая инженерия.

Мы выделили 5 режимов, каждый со своим алгоритмом, вот описание их предназначения чтобы понять зачем они нужны разные и немного о реализации:

Комфорт. Плавное, точное поддержание комфортной температуры воздуха, не перегревая пол. Пол — ограничитель (не выше 28°C, защита кварцвинила). Реализация практически PID-регулятор по температуре воздуха, практически потому что для настоящего PID нужны и PID сервоприводы, которые основаны на другом совершенно физическом принципе и стоят категорически дороже обыкновенных. Но инерционность пола превосходит по времени уровень реакции в течении секунд настоящего PID. Это для какого-нибудь инкубатора с эффективным нагревом будут важны настоящие PID-сервоприводы, для инерционного пола в этой переплате нет никакого смысла, мы можем простым сервоприводом управлять не напрямую, а через time-proportional control: 30-минутный или 20-минутныый цикл, серво открыто пропорционально мощности PID. Это бережёт ресурс сервопривода и с учетом инерции реализует PID-регулирование, создавая комфорт оптимально используя ресурс системы.

Эконом-день. Режим пониженного приоритета и неважности точности. Главное не запускать котёл ради поддержания температуры для зоны с таким режимом. Поясню на примере. Вы открыли входную дверь в прихожей, когда отопление было выключено и в основных комнатах комфортная температура. Что происходит, если в прихожей режим комфорт. Резко упала температура воздуха, запускается котел, греется прихожая. Но в реальности это не требуется, можно спокойно подождать. Если вот уже температура воздуха понизилась в основных комнатах и там уже требуется нагрев, то тогда греть и прихожую. Понимаете, такой режим ожидания прогрева основных помещений и вместе с ними второстепенных. Так как здесь точность не важна, здесь не нужен PID регулятор, здесь нужен именно обычный гистерезис по воздуху с широкой температурной зоной (±1°C). Точность не важна, главное — не запускать котёл ради одного коридора, но при этом тут тоже должно работать отопление, когда котёл работает.

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

Сон. Режим зоны, в которой спит человек, для комфортного сна важен прохладный воздух и теплый пол, главное грея пол не начать греть воздух, для комфорта сна. Гистерезис по полу, но с учетом температуры воздуха, с обратной логикой “не давать прогреваться”.

Преднагрев. Условный запуск на полную мощность. Цель — не «нагреть пол до максимума», а достичь целевой температуры воздуха. Как только воздух прогрелся — автоматический переход в Комфорт. Это физически корректно: нам важен воздух, а не пол сам по себе. Пол — средство, а не цель.

Важный нюанс — каскадная логика с котлом. Режимы Комфорт, Сон и Преднагрев имеют право запускать котёл. Режимы Эконом-день, Эконом-ночь — не имеют. Если все зоны в экономе — котёл не запустится, даже если их десять и все просят тепла. Эконом-зоны просто «подхватывают» тепло, когда котёл уже работает для комфортных зон. Это даёт расчётно 15-25% экономии и резко снижает тактование котла.

Режимы — это уровень инженера. Пользователь их не видит и не настраивает. Это написанные wb-rules скрипты на js, доступные из админ панели wirenboard. Обычному пользователю туда не надо, он видит только результат их работы. Они работают на аппаратном уровне, не зависят от наличия интернета, связи каких-то элементов системы умного дома, максимально стабильны.

Профиль — это ответ на вопрос «когда какой режим применять». Это программный слой, который меняется редко, но всё же это уже уровень пользователя, именно пользователь не вникая в инженерию режимов, но понимая их предназначение, опираясь на аналитику, может настроить расписание для зоны смены режимов по будням/выходным/внутри дня.

Профиль — это JSON-расписание, которое хранится в MQTT-топике виртуального термостата. Его можно менять из Home Assistant, из SprutHub, из любого интерфейса, не трогая wb-rules, но менять его относительно сложно, это не сделать на бегу, это важно делать осознано и подумав, плюс он должен быть устойчив к перезапускам системы и прочим сбоям, например, в случае отключения электричества, его мы бэкапим и храним, в случае чего-то восстанавливаем систему в состояние расписания профилей.

У нас получилось 6 базовых профилей:

Спальня. Ночью — сон по полу. Утром - преднагрев. Днём — эконом-день (никто не бывает). Вечером — комфорт. Перед вечером преднагрев.

Детская. Ночью — сон по полу. Утром - преднагрев. Школьное время - “эконом-день”. Перед возвращением “преднагрев”. Затем до отхода ко сну - “комфорт”

Консервация. Постоянный режим “эконом-ночь”.

Второстепенный. Днём — эконом-день. Ночью — эконом-ночь.

Зал. Ночью - “эконом-ночь”. Ранним утром “преднагрев”. “Комфорт” утром. Днём - “эконом-день”. “Комфорт” вечером.

Кабинет. Комфорт в рабочее время, перед этим “преднагрев”, “эконом-день” утром и вечером, и “эконом-ночь” ночью.

Профиль содержит не только расписание, но и модификаторы — условия, которые меняют его поведение в зависимости от глобального контекста (о нём ниже). Например, для “Детская”: «ЕСЛИ режим каникулы = ВКЛ, ТО “комфорт” весь день». Для зала, в котором может кто-то спать на диване, например, Если режим “сон в зале” = ВКЛ, то ночью “сон”, вместо “эконом-ночь”.

Профили — это уровень администратора системы. Их настраивают редко, но они определяют всю базовую логику работы дома.

Самый верхний пользовательский слой — это интерфейс взаимодействия с зоной. Здесь зона предстаёт перед пользователем как объект управления с набором параметров.

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

Активный профиль. Какой профиль сейчас работает в зоне. По умолчанию — базовый (например, «Спальня»), но пользователь может временно переключить на другой (например, «кабинет» до вечера, если остался сегодня работать дома).

Срок действия профиля. Когда зона вернётся к базовому профилю. Например, важно для зоны “гостевая-спальня”. Которая может иметь базовый профиль “консервация” или “второстепенная”. А при наличии гостей на несколько дней получать активный профиль “спальня” или стать “кабинетом” на какое-то время.

Ручной оверрайд. Пользователь может временно задать свою уставку температуры. Система запоминает, что это ручной ввод, и через заданное время (например, 2 часа) автоматически возвращается к профилю. Это защищает от ситуации «я забыла вернуть настройку».

Временные события. Пользователь может активировать сценарий: «Мне жарко/холодно» (снижает/увеличивает текущую уставку на 1 градус), «Быстрый прогрев» (выставляет режим “прогрев” на 1 час), «Вечеринка» (продлевает действие режима “комфорт” до 1 ночи). Каждое событие имеет свою логику и время действия.

Текущие температуры. Воздух и пол — в реальном времени.

Текущий режим. Какой алгоритм сейчас работает: Комфорт, Эконом-день, Сон, Преднагрев. Пользователь видит не просто «22 градуса», а «сейчас режим Комфорт, система держит 22°C по PID».

Активный и базовый профили. Пользователь видит, какой профиль сейчас работает и какой является базовым (к которому система вернётся после оверрайдов).

Статусы оборудования. Обогрев включен/выключен, кондиционер включен/выключен, сервопривод открыт/закрыт, насос работает/остановлен.

Целевая температура (уставка). Какую температуру система сейчас стремится достичь (от активного профиля или оверрайда).

Выход PID. Насколько сильно система сейчас греет (0-100%). Полезно для понимания, почему в комнате может быть прохладно — например, «PID на 15%, система ждёт, пока пол прогреется».

Самый верхний слой — это ситуация, в которой находится весь дом целиком. Не отдельная комната, а дом.

Примеры:

Глобальный контекст — это «переключатель», который меняет поведение всех/части профилей/зон сразу. Он влияет на абстракцию профилей, например, в случае каникул, как я писал выше, а может и влиять на абстракцию зон, например, “мы в отпуск”, должен выставить текущий профиль “Консервация” всем зонам в доме.

Обычные термостаты об этом не знают. Они просто видят «стало холодно — надо греть» и включают пол даже в мае, когда на улице +15 и никого дома нет.

В нашей системе глобальный контекст меняется администратором один раз в сезон — и все 12 зон корректно перестраиваются. Не нужно обходить дом и крутить каждый термостат.

Утро. В 6:00 включается преднагрев родительской спальни. К 7:00, когда вы встаёте, пол уже прогрет, воздух 22°C. Не потому что термостат «догнал» температуру, а потому что система настроена на инерцию вашего пола и начала греть заранее.

День. Вы уехали на работу. Спальня, кабинет, зал перешли в эконом. Гостевая — в глубоком экономе. Котёл не тактует.

Вечер. В 14:00 включается преднагрев детских, а в 18:00 зала, в 20:00 родительской. К вашему приходу в нужную комнату дом уже тёплый. Не «начинает прогреваться», а уже прогрет заранее.

Ночь. В 22:30 все спальни переходят в режим «Сон». Пол держит 22°C, воздух остывает до комфортных 19-20°C. Прохладный воздух, тёплый пол — идеально для сна.

Голосовое управление. Жене стало холодно: «Алиса, мне холодно в спальне». Система на 2 часа увеличивает уставку. Через 2 часа — возврат к профилю.

Несколько технических решений, без которых система не работала бы:

Защита кварцвинила. Жёсткий лимит 28°C по датчику в стяжке, в реализации каждого режима. Если пол перегрелся — серво закрывается мгновенно, игнорируя PID и температуру воздуха. Никакая логика не может это обойти.

eBUS-телеметрия котла. Мы читаем не просто «включен/выключен», а модуляцию горелки, температуру подачи/обратки, давление в системе, коды ошибок. Если давление падает — уведомление в Telegram ещё до того, как котёл уйдёт в аварию.

Когнитивная система отопления — это не какая-то «маркетинговая фишка». Это попытка ответить на вопрос: как должна работать система, которая учитывает инерцию стяжки, чувствительность кварцвинила, гидравлику котла и привычки людей одновременно?

Ответ:

Разделить систему на слои абстракции, где каждый слой решает свою задачу

Это даёт:

Мы не претендуем на то, что это единственно правильный путь. Но мы уверены: если тёплый пол — единственное отопление, обычные термостаты не справятся. Они не учитывают ни инерцию, ни котёл, ни контекст.

Отличная новость: описанная архитектура реализуема на абсолютно доступном железе (Wiren Board 8). Не нужно заводов, не нужно промышленных контроллеров за миллионы. Нужна только правильная идея и терпение в проектировании. Ну и теперь вишенка на торте, стоимость на 12 контуров умных термостатов, управляемых телефоном/голосом и чем угодно, которые в свою очередь управляют сервоприводами обойдётся в 106.000р = 8000(минимальная стоимость термостата с умными функциями)*12 + 10.000 (умное реле). Против 52.000 (WB (с EBUS и спрутстиком) +реле).

Если статья зашла — пишите в комментариях, что было бы интересно разобрать подробнее.