WBE2-I-OPENTHERM добавить функционал в прошивку

Был очень рад, когда увидел анонс данного модуля и купил его на старте продаж особо не вчитываясь в документацию. Ожидал, что он будет достаточно универсален как и остальные модули WB. Но оказалось, что мой сценарий использования не поддерживается :(.

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

Вопрос №1
У меня котел Baxi EcoHome, который работает как одноконтурный котел с внешним бойлером, подключенным через штатный трехходовой клапан.

В настоящий момент моя система отопления управляется комнатными термостатами, объединенные зональным коммутатором. Коммутатор управляет котлом замыкая/размыкая “перемычку” котла. Все нормально работало до подключения WBE2-I-OPENTHERM - котел отключался полностью, когда отопление не нужно и включался, когда падала температура в бойлере или термостаты давали запрос на нагрев.

После подключения WBE2-I-OPENTHERM котел не отключает контур отопления даже если перемычка разомкнута. Насос всегда включен, периодически включается горелка и почти сразу отключается, так как тепло забирать некому - все контуры отопления закрыты термостатами.

Я заметил, что при замыкании/размыкании перемычки меняется opentherm статус котла - при замыкании выставляется бит №6 - “diagnostic event”.

Можно ли сделать так, чтобы шлюз включал отопление только, когда котел выставляет флаг “diagnostic event”, и выключать, когда флаг снимается котлом? Тогда бы котел корректно работал и включался/выключался по команде стандартного внешнего термостата.

Описание подобной логики я нашел в OpenTherm интеграции Tasmota - OpenTherm - Tasmota

У них есть две отдельных настройки:

  • “OH” - контур отопления всегда включен. Этот режим аналогичен текущему режиму WBE2-I-OPENTHERM - “Direct Heating Setpoint Control”.

  • “CHOD” - контур отопления включается, когда у котла замыкается перемычка (флаг “diagnostic event”)

Получается, что это вполне стандартный сценарий, который поддерживается другими шлюзами.
Было бы здорово, если WBE2-I-OPENTHERM тоже позволял так сделать.

Вопрос №2
Хотелось бы иметь возможность задавать температуру теплоносителя по температурной кривой от внешнего датчика подключенного непосредственно к котлу.

Добрый день.

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

Это, как по мне сильно зависит от реализации в конкретной модели, позвал разработчика.

Не хочется делать это программно. ИМХО такие критичные вещи как отопление должны быть реализованы максимально надежно, желательно “в железе”. Логика на JS не кажется достаточно надёжным решением.

Большинство котлов имеют “перемычку термостата” и умеют работать в двух режимах:

  • Режим 1. Перемычка всегда замкнута. В этом режиме насос котла всегда включен. Котел просто поддерживает заданную температуру теплоносителя периодически включая и выключая горелку. Это самый простой сценарий использования котла. И это самый неэкономичный режим работы: постоянно включенный насос потребляет электроэнергию, а в межсезонье котел “тактует” - включается и быстро выключается, так как его мощность избыточна. Летом обычно котел переводят в “летний режим” - принудительно выключая отопление.
  • Режим 2. К перемычке подключается комнатный термостат (или сразу много комнатных термостатов объединённых зональным коммутатором). Когда температура в доме выше заданной на термостате, то термостат размыкает перемычку и котел гасит горелку и останавливает насос. Когда температура в доме падает, то термостат замыкает перемычку и котел включает насос и начинает греть теплоноситель до заданной температуры - по сути переходит в первый режим работы. Это более экономичный и щадящий для котла режим - котел включается только, когда фактически нужен. Летом принудительно выключать отопление не нужно - оно само перестанет включаться весной и автоматически начнет включаться осенью.

У меня в данный момент как раз реализован второй сценарий. Без модуля WBE2-I-OPENTHERM
котел отлично управляется комнатными термостатами через перемычку. А с модулем WBE2-I-OPENTHERM котел не обращает внимание на перемычку и не хочет останавливать насос.

Модуль WBE2-I-OPENTHERM мне по сути нужен для удаленного мониторинга котла и установки температуры теплоносителя. А основное управление котлом должно идти через комнатные термостаты и перемычку как и раньше.

Если котел в режиме управления по шине не умеет (нет соответствющей настройки) включаться и выключаться по “перемычке” - то через opentherm это не включить.

Да, я знаю, что некоторые более современные котлы имеют отдельную настройку, которая позволяет включить управление котлом перемычкой при подключении OpenTherm.

Мой котел такой настройки не имеет. Но он умеет сигнализировать о состоянии перемычки через флаг OpenTherm "diagnostic event”.

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

Было бы здорово иметь подобный функционал и в шлюзе WBE2-I-OPENTHERM.

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

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

Я согласен, что в железе должен быть реализован базовый функционал, а в скриптах можно делать дополнительную обработку и интеграцию между устройствами. Но в данной конкретной ситуации для меня это как раз базовый функционал без которого отопление не будет работать. Будет очень неприятно если я реализую логику в скриптах, но после очередного обновления WB что-то сломается в правилах и отопление перестанет функционировать.
Можно купить отдельный контроллер WB чисто под отопление (и не трогать его настройки и софт) в дополнение к основному контроллеру WB (который я часто обновляю). Но это слишком расточительно.

Если разработчики модуля не имеют времени заниматься эти, может можно получить доступ к исходникам прошивки?
Я мог бы сам попробовал добавить нужный функционал.
Программатор для модуля у меня уже есть.
Необходимые NDA могу подписать.

Здравствуйте, модули разрабатываются и производятся компанией НЕВОТОН, тут мы не сможем вам помочь.

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

У меня BAXI Eco Four (довольно древний, не думаю, что у EcoHome хуже реализация OT)

Без OT при разомкнутой перемычке термостата котел отключается (как и должно работать)
При подключении OT(через Tasmota) котел полностью игнорирует перемычку в режиме CH и включается при замыкании перемычки термостата, как без ОТ в режиме CHOD.

НО! Режим CHOD это чисто программная фишка, которая реализована в Tasmota. Котёл отдает флаг (diagnostic indication), а адаптер по нему включает режим отопления. “Внутри” протокола OT нет такой фичи, там раздельно команда на включение отопления и отдельно возврат флага термостата.

Т.е. никаких проблем, повторить эту же логику в скрипте вроде нет. Более того, можно использовать несколько 1-wire датчиков в разных комнатах и более сложную логику их обработки… (Например, ПИД регулирование вместо кривых уличной температуры)

Да все так, описанная логика реализована на уровне прошивки Tasmota.
Но, например, модуль WBE2-I-OPENTHERM сейчас позволяет устанавливать температуру по температурным кривым. Это тоже программная логика, которую теоретически можно было бы реализовать правилами WB. Но она сейчас реализована именно в прошивке модуля. Не вижу принципиальной разницы.
Можно привести аналогичный пример про модули реле WB. Обработка двойных нажатий и антидредребезга реализованы в прошивке модуля. Теоретически это все тоже можно было бы реализовать програмно в правилах WB.

Для меня это нежелательно. Принципиально строил систему УД состоящую из отдельных компонентов, которые могут работать полностью независимо от центрального контроллера WB.
В целом большинство модулей WB отлично вписываются в данную идеологию: один раз настроил модуль через регистры ModBus, а дальше он спокойно работает даже если нет связи с центральным контроллером.
Но WBE2-I-OPENTHERM как-то выбивается из общей картины: с одной стороны казалось бы позволяет легко подключить котел к WB, а как начинаешь реально использовать, то оказывается, что нужно к нему писать какую-ту внешнюю логику на JS.
Хотелось бы, чтобы WBE2-I-OPENTHERM был тоже максимально самостоятельным.

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

Я для себя решил, что “этим устройством” будет WB. У меня по датчику температуры в каждом помещении и ПИД регулирование целевой температуры котла (при необходимости включение/выключение). Для меня включение-выключение через термостат - слишком грубая регулировка. Особенно зимой очень явно заметно греет сейчас батарея или котел выключился, т.к. нагрел помещение…

Но, сама идея про автономные элементы умного дома мне близка и понятна… Даже думал утащить логику ПИД-регулирования в тасмоту, чтобы получить автономность от wb. Но, пока надежность wb меня устраивает (живет автономно в доме, где я бываю раз в несколько недель)

1 лайк

Если один раз настроить и больше не трогать WB, то это вполне рабочее решение. Но если вы регулярно его обновляете и ставите какой-то дополнительный софт типа SprutHub или zigbee2mqtt (как я), то как-то страшно обновлять его. Если контроллер навернется - останешься без отопления.

Ну термостаты бывают разные, есть супер-умные типа Google Nest thermostat, которые и прогноз погоды учитывают. :slight_smile:

@Vladimir_Nev_Sup , вы можете ответить?

Ну термостаты бывают разные, есть супер-умные типа Google Nest thermostat, которые и прогноз погоды учитывают. :slight_smile:

Не, речь не про это!

Речь про то, что регулировка через целевую температуру котла правильнее, чем вкл/выкл котла

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

Но этого недостаточно, обычно мощность котла избыточна, особенно в межсезонье. Например у всей линейке котлов Baxi Eco Home (модели 10F, 14F, 24F) одинаковая минимальная мощность - 10квт. А у меня, например, согласно проекту отопления, у дома максимальные теплопотери 8квт. Это при температуре -35 на улице!

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

Вроде тактование - штатный режим котла и целевая температура теплоносителя 30-35 градусов не хуже (а может и лучше), чем 60 градусов + термостат…

Это точно комфортнее (температура в помещении стабильнее), а для котла это вроде как нормальный рабочий режим…

А летом котел тоже должен поддерживать температуру теплоносителя 35 градусов и тактовать? :slight_smile:
Или он все таки должен выключаться? И если он должен выключаться, то вы его вручную выключаете или это логика на wb делает? Если через wb, то это разве не управление температурой через вкл/выкл? :slight_smile:

Ну… тут каждому своё…

В моей картине мира - управляем температурой помещения через целевую температуру котла, пока это возможно и выключаем котёл если достигли минимальной целевой температуры, но все равно теплее, чем нужно…

Было бы странно реализовывать такой функционал в интерфейсном модуле (как минимум, ему нужна температура помещения для обратной связи)

У всех разные подходы. Я проектировал свой УД таким образом, чтобы максимально использовать стандартные самодостаточные компоненты, которые могут работать полностью самостоятельно без участия центрального контроллера WB и которые легко заменить в случае поломки.

Система отопления у меня состоит из банального газового котла, комнатных термостатов, зонального коммутатора, термоголовки, насос ТП. Все стандартное, все можно купить в локальном магазине или маркетплейсе. Все работает с минимальной настройкой без дополнительного программирования. Если вдруг что-то сломается, когда я буду отсутствовать (например в командировке), то близкие могут вызвать обычного электрика/сантехника/газовщика и он починит или поменяет сломанный компонент.

Можете считать меня ретроградом, но JS cкрипты, которые управляют отоплением не вписываются в мою картину мира :slight_smile: .

Мне не нужна какая-та сложная навороченная логика в WBE2-I-OPENTHERM. Нужно, чтобы он банально не мешать работать существующей системе отопления. Чтобы котел включался и выключался по состоянию перемычки.
Когда это заработает, то я буду думать о погодо-зависимой автоматике и прочих “красивостях”. А пока меня блокирует невозможность использования WBE2-I-OPENTHERM в моей системе отопления.