Столкнулся с проблемой. Опишу в начале что я имел:
Котел Baxi Duo-Tec 1.24 (конденсационный), к нему подключен датчик наружной температуры, соответственно, в нем включен режим ПЗА. Котел работает на контура теплого пола и включался релюшкой по “запросу” - если был включен хотя бы один насос контуров потребителей, выключался когда отключались все насосы. Однако из-за того что эквитермальные кривые котла не сдвигаются “влево-вправо” (как это можно сделать у Valliant/Protherm), то при наружной температуре +15…-5 градусов котел на подаче имел слишком малую температуру. Как итог - дом слишком долго прогревался, иногда температура снижалась ниже уставки на 2 градуса.
Я решил что с помощью данного OT-шлюза смогу управлять котлом более гибко. Однако при его подключении понял, что:
Теперь нельзя котел отключить или включить релюшкой по “запросу”, вероятно от того, что OT-девайс является основным управляющим органом котла…? Котел всегда работает (если реле не включено, то состояние котла - 2 dec, если включено, то 74 dec).
Теперь не работает ПЗА котла - вероятно потому что OT-девайс является основным управляющим органом котла…?
ПЗА OT-шлюза использовать не могу поскольку самая “младшая” кривая даст мне 64 градуса (при -40 за бортом), когда мне нужно не более 55!!! У всех котлов есть кривые для работы на прямую с ТП, а тут - их просто нет…
При снижении температуры ГВС (в косвенном бойлере установлен выносной датчик температуры), котел не переключает трехходовый кран и не нагревает воду!
Котел нельзя принудительно выключить кнопкой питания (отображается код 303 или 100).
Возможности сброса ошибок котла нет.
Уважаемые разработчики, можете прояснить вопрос по п.1, 2. А также дать свои комментарии по п.3, 4, 5, 6?
Как итог - для моей реализации данный шлюз совершенно не подходит (вернуть уже не получится, прошло более 14 дней), имеет очень ограниченные возможности! Или же надо полностью менять подход к реализации управления отоплением (полностью завязываться на программную реализацию), что приведет к уменьшению надежности системы… Но опять же - почему котел не греет горячую воду? Пока в больших раздумьях:(
Нет, так Baxi не работает. Поэтому при подключении OT-шлюза, вся моя программно-аппаратная логика перестала работать. Собственно все это видно по графику работы за ночь (в 23 подключил шлюз, а в 12 отключил его)…я вообще не понимаю что шлюз делал с котлом, особенно в то время когда появлялся температурный “частокол”:
В документации на Baxi вычитал, что у него есть параметр 10 - “Установка температуры отопления OT/TA (Open Therm/комнатный термостат)”. Если выбрать уставку 02 - “если подсоединены пульт дистанционного управления и высоковольтный комнатный термостат (~ 230 В), используется установка температуры, заданная на пульте. Комнатный термостат дает разрешение на работу котла” - то вероятно будет работать как вы описали. Попробую, изменить параметр в котле.
В котле параметр 06 “Конфигурация входа датчика уличной температуры” по умолчанию с уставкой 00 - “при подключенном уличном датчике котел регулирует температуру подачи
отопления в зависимости от уличной температуры”. Вместо температуры на подаче контура отопления у меня выбрана 12-я эквитермальная кривая.
Если вы имеете ввиду какие параметры я устанавливал в регистрах хранения OT-шлюза, то они следующие:
Температура подачи котловой воды - 45
Температура ГВС желаемая - 55
Температура комнатная желаемая - 0
Тип датчика температуры - 0
В моем Baxi есть только две уставки в параметре 16 “Установка максимальной температуры отопления”. Поскольку в самые морозы мне не хватает максимальных 45 градусов, то у меня параметр 16 имеет уставку 00 - “номинальная 80°C”. Поэтому в данном случае ПЗА OT-шлюза у меня не применимо:(
Если вы про котел - то конечно же! А если про OT-шлюза, то в документации об этом ни слова! Только есть регистр хранения для установки желаемой температуры ГВС.
Я не использую WB). У меня intraHouse, используя MegaD-2561 в качестве Ethernet-UART ModBus-шлюза, опрашивает регистры входов и записывает данные в регистры хранения.
Boiler state в веб-интерфейсе WB - это просто опрос регистров входов:
Error Code - это ModBus code - 04, регистр - 00ce
Hot Water Temperature - это ModBus code - 04, регистр - 00d0
Heating Temperature - это ModBus code - 04, регистр - 00cf
Burner Modulation Level - это ModBus code - 04, регистр - 00d1
Water Pressure - это ModBus code - 04, регистр - 00d2
А вот что такое Boiler Status? Это регистр входа 00cd и какой-то его бит? Но как это влияет на управление бойлером? Я ведь устанавливаю температуру ГВС принудительно в регистр хранения 00сс!
К тому же я читаю регистр входа 00cd и получаю либо 0000 0010, либо 0100 1010, то есть биты, связанные с ГВС всегда равны 0.
С уставкой 2 в параметре 10 теперь связка Baxi Duo-Tec 1.24 + NEVOTON BCG-1.0.2-W работает приемлемо, но только в части “запрос” тепла и поддержания установленной котловой температуры! При отключении OT-шлюза от котла, на котле появляется ошибка E83, которую сбросить нельзя, поэтому отключать OT-шлюз нужно только при полном отключении котла (а также при возврате уставки 0 в параметре 10).
Проблемы выявляю следующие:
Котел не греет косвенный бойлер, как будто OT-шлюз не знает о бойлере или не знает какую команду дать котлу чтобы он переключился на нагрев ГВС!
Во время отсутствия “запроса” тепла с OT-шлюза считывается какая-то не понятная температура - смотрим на зону, обведенную голубым овалом (красная кривая - это DS18B20 на патрубке подачи котла, оранжевая кривая - это температура подачи котла, считанная из OT-шлюза).
В ПО OT-шлюза происходят какие-то сбои, в результате чего он время от времени отдает не актуальную информацию почти по всем параметрам - см.кривую "Температура на подаче ГК (OT) и “Температура наружная (OT)”. Также иногда приходит не верное значение статуса котла (вместо 74, например, приходят 3989, 1941). И дело явно в прошивке OT-шлюза поскольку он общается с MegaD-2561 по Modbus RTU и CRC Error за ночь было всего 6 штук. То есть именно OT-шлюз формирует сообщение Modbus RTU с не верными данными!
Кроме озвученных проблем, нужно добавить несколько “младших” кривых для ПЗА, например, которые “оканчиваются” (при самой низкой внешней температуре) на 45, 50, 55 градусах.
По результатам изучения логики работы OT-шлюза понял, что:
В режиме задания уставки температуры подачи котловой воды (регистр хранения 207 имеет значение 0, регистр хранения 205 принудительно обнуляется) внешняя система/сервер умного дома должна самостоятельно записывать в регистр хранения 203 значение требуемой температуры подачи котловой воды.
В режиме задания уставки комнатной температуры (регистр хранения 207 имеет значение 0, регистр хранения 203 принудительно обнуляется) внешняя система/сервер умного дома должна записывать в регистр хранения 208 реальное значение температуры в жилом помещении.
В режиме ПЗА (регистр хранения 207 имеет значение 1) внешняя система/сервер умного дома должна записывать в регистр хранения 208 реальное значение уличной температуры и при необходимости оперировать климатическими кривыми задавая их через регистр хранения 206.
В руководстве по эксплуатации ИГНЖ-142.00.00РЭ все эти моменты освещены не понятно даже пользователю, имеющему понимание работы подобных систем.
Скажем так - OT-шлюз “читает” из шины котла температуру с датчика ГВС и даже может передает в котел уставку ГВС (как это проверить - вопрос!), но раз именно шлюз теперь является “головой” котла, то именно он должен сказать - переключись на бойлер или переключись на отопление, но этого не происходит.
В общем нужно чтобы разработчики тут ответили, но что-то они игнорируют форум, хотя на мой запрос Невотон мне ответили следующее - “Вам уже ответили на форуме”…
Вы сейчас про какой именно - OT-шлюз или Ethernet-UART шлюз?
У меня была цель - поиметь компактный OT-шлюз с энергонезависимым режимом, который будет позволять мне как минимум устанавливать температуру отопления и ГВС, а также предоставлять возможность контролировать параметры котла без изучения OT-протокола. Ну и желательно чтобы у него интерфейс был UART, чтобы подключить к MegaD-2561 напрямую (коммутатор в щите установить не где, как и что-то большее чем 2 DIN-устройство).
Все с той точки зрения, что в любой системе умного дома самое слабое звено - это сервер (любая unix-железка) наряду с Ethernet-сетью. А вот OT-шлюз и MegaD-2561 на базе микроконтроллеров априори отказоустойчивее остального, наверное, даже отказустойчивее самого котла)
К модулю у меня вопросов нет. Он читает данные с котла, он пишет данные в котёл. Значит он исправен.
Касаемо ваших кривых для ТП я уже отвечал в другой ветке.
Модуль отправляет команды котлу по уставкам ГВС и ТО. Если вас не устраивает как они исполняются, смотрите в настройках котла.
Весь алгоритм переключения клапанов, ходовиков внешних бойлеров находится в котле, модуль только задаёт ему уставки температур и никогда не вмешивается в работу внутренних алгоритмов котла.
Есть вероятность, что модуль уставку в котел пишет не туда? Как провести траблшутинг проблемы? А вообще вы тестировали модуль с одноконтурными котлами Baxi/Bosch?
-Да, последняя проверка на Baxi Slim была.
-Касаемо плохой связи с контроллером, поскольку вы не используете контроллер WB и не используете его шаблон с его таймаутами и задержками, его правилами опроса modBus устройств, то давать гарантии на нормальную работу модуля я не могу.
Добавить несколько “младших” кривых для ПЗА, например, которые “оканчиваются” (при самой низкой внешней температуре) на 45, 50, 55 градусах. В качестве примера:
Предусмотреть сдвиг кривых влево-вправо
Добавить возможность определения есть ли “Связь между котлом и модулем (1–есть, 0 - нет)”.
Добавить возможность выявления неисправности датчика температуры (например, если в регистр хранения 208 данные не поступают на протяжении 5-10 минут), по которому модуль выставит температуру теплоносителя из регистра 203.
Добавить сброс “простых” ошибок котла (для Baxi - это E 110, E 125, E 133, E 134, E 135, E 09, E 15, E128 и E 384)
Добавить сброс блокировки котла, возникшей в результате ошибки его работы
Добавить перезагрузку модуля
Добавить регистр входа с кодом ошибки, характерным для всех котлов с OT (ID=5, HB, flag8).
Добавить регистр входа с кодами диагностики, характерными для всех котлов с OT (ID=115).
Добавить регистр входа с температурой котловой воды на обратке (ID=28)
Добавить регистр входа с данными о расходе ГВС (ID=19)
Добавить регистр хранения для max CH water setpoint (ID=57)
А еще в новых версиях платы нужно светодиоды питания сделать красным цветом, OT - оранжевым, UART - зеленым, иначе все очень не информативно и можно вообще убрать их…
В инструкции требуется:
В регистре “Статус котла” откорректировать описание битов в LB и HB (Enable != Mode)
Прописать марки и названия котлов с которыми модуль совместим практически.
Как можно провести траблшутинг проблемы? Порекомендуйте как специалист.
В шаблоне, если вы про json, никаких таймаутов и задержек не указано. Поэтому расскажите какие таймауты и задержки оптимальны для модуля? Также какие у вас правила опроса ModBus устройств? Чтобы я имел возможность ликвидировать не верные данные, которые изредка получаю с модуля.
На текущий момент за один сеанс связи, проходящий 1 раз в минуту, я опрашиваю последовательно 12 регистров входа с интервалом 1 секунда, вот лог опроса:
Я формирую запрос, а MegaD-2561 считает CRC и отправляет сообщение в модуль. То что модуль отвечает оказывается в буфере MegaD-2561. Контроллер проверяет CRC - если он верный, то возвращает данные, если нет, то ошибку вида CRC Error (эти ошибки я считаю накопительным итогом). Могу попробовать самостоятельно на программном уровне рассчитывать CRC, но думаю, что от этого ничего не изменится.
Вообще, для вашей компании было бы хорошо наладить сотрудничество с производителем MegaD и распространять свою продукцию среди пользователей в том числе портала ab-log - одного из самых продуктивных в рунете по теме автоматизации.
Update 100500:
Почему при считывании регистра хранения 205 (Read-Data Status ID=0), MB всегда = 0? По хорошему в отладочных целях иметь бы что отправил Master to Slave!
Я так полагаю, что котел не переходит на нагрев ГВС потому что модуль все же Master-устройство и в ID=0 должен сообщать котлу что он должен делать! А он отсылает DHW enable = 0 или CH2 enable = 0 (есть сведения, что в некоторых Baxi “Central Heating 2” - это как раз контур ГВС)… как итог, котел не включает нагрев ГВС. Прошу проверить мою гипотезу!
Вообще я может не понимаю в чем задумка данного шлюза? Шлюз - это штука, через которую можно получить доступ к чему-либо. В данном случае - это котел, имеющий интерфейс с протоколом OT.
Тогда по идее я должен мочь с помощью данного шлюза управлять данным котлом, исходя из протокола OT - это как минимум управление битами в HB Read-Data Status MsgID=0. Как раз биты этого сообщения в HB или Master status согласно наименования OT отвечают за управление котлом. В минимальном варианте это:
Включение/выключение Central Heating или первого контура отопления (бит 0)
Включение/выключение Domestic Hot Water или нагрева горячей воды (бит 1)
Включение/выключение Central Heating 2 или второго контура отопления (бит 4)
Я так понимаю, что если это одна из разновидностей котла Baxi, то для нагрева ГВС надо выставить и бит 1 в лог.1, и бит 4 в лог.1.
Ну а вообще раз это OT-шлюз, то в нем должен быть какой-то “прозрачный” режим - по Modbus в регистр сообщаем MSG TYPE, DATA-ID, DATA-VALUE, а он формирует и отправляет в котел фрейм в формате OT, котел отвечает и мы читаем в этом регистре что ответил котел.
Если шлюз будет работать только в “прозрачном” режиме, то обмен данными и представление их в веб-интерфейсе придется пользователям реализовывать самим, что не каждому под силу. В данном случае шлюз конвертирует данные, которые может читать, из OpenTherm в UART и обратно, что позволяет подключать его к контроллеру как и остальные Modbus-устройства. От пользователя требуется только добавить модуль в конфигурацию контроллера и выбрать необходимые для опроса регистры.
Если бы вы были инженером, то понимали бы что “другой контроллер” тут не при чем! То что я использую - это НЕ Arduino, а функционально-законченное устройство, производящееся на автоматизированной линии большим тиражом. Самое главное - UART, он и в Африке тоже UART! Поэтому раз производителем заявлен интерфейс UART с логическими уровнями 0…3.3В (питается модуль от 3.3В), то он будет совместим со всеми устройствами, имеющими UART с такими же логическими уровнями.
Как уже говорил - я не использую WB от слова совсем, так же как и “шаблон модуля”. Программная среда в которой я реализовал сценарий работы с модулем - это intraHouse. И да - по поводу регистров - мой первоисточник - это официальная инструкция по эксплуатации шлюза. И самое главное - в таблице регистров ввода находится описание регистра Boiler Status, HB которого управляют котлом, о чем я и пишу, но Вы не понимаете о чем речь, поскольку совсем этого не знаете…
Давайте так - производитель в инструкции и на сайте назвал это устройство ШЛЮЗом. Шлюз - это устройство, обеспечивающее доступ из одной среды (в данном случае UART) в другую (OpenTherm). В данном случае это обеспечивается, но только по “заранее” запрограммированным параметрам. Пусть это будет так, но для гибкости использования неплохо было бы иметь СПЕЦИАЛЬНЫЙ регистр хранения для реализации возможности “прозрачного” обмена данными с котлом. То есть функционал, который я описывал - “по Modbus в регистр сообщаем MSG TYPE, DATA-ID, DATA-VALUE, а он формирует и отправляет в котел фрейм в формате OT, котел отвечает и мы читаем в этом регистре что ответил котел.”
