Владимир, давайте всё-таки исходить из того, что я представляю себе логику работы opentherm протокола, а в этом общении пытаюсь понять логику работы вашего шлюза.
Вы как-то постоянно пытаетесь уйти от прямых ответов на мои конкретные вопросы, и это меня, честно говоря, расстраивает… Но я обещаю быть терпеливым и понятливым.
Итак, в третий раз переформулирую свои вопросы, чтобы (как мне кажется) облегчить вам их понимание, и, соответственно, увеличить свои шансы на получение ответа.
Я хочу включить у своего котла контур отопления. Для этого я передаю в шлюз команду прозрачного обмена на чтение ячейки котла 0, с установленным битом 1 старшего байта в пакете данных на чтение. Чтобы исключить влияние посторонних программ (типа NodeRed) а также плохо контролируемых и документируемых действий в WebUI, я использую утилиты командной строки, предназначенные для отслеживания и публикации данных в mqtt. А именно: в одной терминальной сессии я запускаю команду mosquitto_sub -v -t '#'|grep opentherm для отслеживания обмена с модулем по интерфейсу mqtt, а в другой - последовательно команды
У меня после этих действий котёл переходит в состояние OFF, и статус его (как правило) становится 0. Повторите, пожалуйста, у себя эти действия, и напишите тут, какой будет результат (конкретно, как прореагировал котёл, и какой вывод дала команда в первой терминальной сессии)
Оставьте, пожалуйста, эту самую первую терминальную сессию с командой mosquitto_sub -v -t '#'|grep opentherm поработать 60 минут (само собой, при условии, что котёл включен, и подключен к модулю WBE2-I-OPENTHERM). Приведите тут, пожалуйста, результаты её работы.
Опишите, пожалуйста, логику работы модуля с ячейкой (data-id) 0 ведомого устройства (котла) по протоколу opentherm. Конкретно, меня интересует, какое значение (DATA-VALUE) передаётся модулем в котёл при чтении (выполнении команды READ-DATA) ячейки (DATA-ID) 0 сразу после подачи питания на модуль (т.е. до любых операций с модулем по шине modbus)? Запоминает ли модуль данные, передававшиеся через команду прозрачного обмена на чтение ячейки 0? Если нет, то как можно проинструктировать модуль включить/выключить контуры отопления и горячего водоснабжения (а также Cooling, OTC и CH2, которые тоже управляются через старший байт DATA-VALUE при чтении DATA-ID 0)? Если да, то где хранится запомненное значение (оперативная память/энергонезависимая память)?
Повторил, как вы и просили. Отправил 256, получил 258. Дал разрешение на использование контура и котёл тут же его включил. Повторюсь. В своей связки модуля котла (Thermona) я не вижу проблем с прозрачным обменом.
В качестве замечания: в приведённом вами протоколе обмена последнее значение ‘TR Data’ == 0, хотя должно было быть 258 (если предположить, что input регистр CD/0205 (aka топик “Boiler Status”) соответствует значению ячейки 0 котла). Это, на мой взгляд, всё-таки свидетельствует либо о том, что модуль работает не совсем так, как описано в документации, либо в документации описано не всё, и не совсем так, как оно есть на самом деле…
P.S. Я уже понял, что в ваших условиях и на ваших тестах вы никаких аномалий не замечаете. Теперь я пытаюсь систематизировать разницу в условиях, тестах и понимании аномалий, чтобы максимально сузить круг потенциальных причин своеобразной, скажем там, работы модуля у меня.
P.P.S. Было бы, конечно, здорово, чтобы сюда заглянули, и попробовали воспроизвести мои тесты, другие обладатели модулей Невотон. Например, @borg, @Alex_Jet, @vpiyanov, @Shurup, @zelenenkiy, @blog, @vaprol, @bzzeke, @svipsa, @Haggard (это только некотороые ники пользователей, которые писали сюда, на форум поддержки, о схожих проблемах с модулями Невотона…)
Насчёт этого момента. TR Data и Boiler Status это не одно и тоже. Если все данные обнулились (Command и Data), это значит, что пакет прошёл валидность и отправился в котёл. Этот момент указан в инструкции:
@hamster, я рад бы повторить и воспроизвести Ваши “нехитрые” тесты, но у нас на объекте установлен модуль с прошивкой 1.05, там прозрачного обмена ещё не было. Может, я ошибаюсь, не уверен. На команды “TR Command” и остальные две модуль не реагирует, а если принудительно новый шаблон загрузить, они не работают.
При выводе mosquitto_sub -v -t '/devices/wbe2-i-opentherm_11/#'
не наблюдается хаотичных значений, всё ровно и чётко работает. Да и вообще в логах не было проблем.
У нас другая проблема: периодически (раз в пару дней - раз в неделю) связь отваливается. Модуль при этом якобы работает, команды якобы отправляются, но котёл на них не реагирует, переходит в ручной режим. Но если отключить шину на 30 и более секунд, то котёл уходит в ошибку E31, которая решается перезагрузкой котла по питанию. Связь “приваливается” снова через час (или пять часов, или день, по-разному). Либо если быстро переткнуть шину или перезагрузить WB.
Я тоже думал попробовать прозрачный обмен, но модуль на этой прошивке его, к сожалению, не поддерживает.
Если я чем-то могу помочь в плане тестов - пишите, буду рад поспособствовать. Но подобных проблем как у Вас не наблюдалось у нас от слова совсем.
У меня модуль Невотон работает в связке с Baxi Luna Duo-Tec 1.24 (отопление и бойлер косвенного нагрева). Честно - я намучился с модулем, а более менее он стал работать в связке с моим котлом только с прошивкой 1.3.
От функционала использование регистров “прозрачного обмена” отказался из-за того что котел не адекватно реагировал на команды, а регистр 205 начинал выдавать совершенно не актуальные данные. В итоге - управлять температурой теплоносителя могу, включать/отключать нагрев бойлера - только косвенным образом (изменяя температуру ГВС - либо 55 градусов, либо 25). А “артефакты” в считывании данных очень напрягают!!!
Но я никого не смог убедить в проблемах с прошивкой модуля поскольку не использую WB - у меня связка intraHouse + MegaD-2561 + WBE2-I-Opentherm. Соответственно, разработчики списали на то что я, построив профессиональную систему умного дома, не могу разобраться с помехами/подключить нормально модуль к котлу/плохо работает MegaD-2561 как шлюз UART-HTTP.
Вообще, разочаровался в модуле - архитектура выбрана очень ограниченная, прошивку тестировали плохо (с ограниченным числом котлов), клиентоориентированность - на 3 балла, а сейчас еще и модуль стоит как крыло от самолета!
Добрый день. Да, прошивка старая. В ней ещё много не реализовано. В последней версии есть регистр потери связи с котлом (1 когда нет связи более 5 секунд). Если у вас есть возможность прислать модуль, я могу обновить до 1.4. Да и в целом новая версия должна быть более стабильной. Да, к сожалению возможности самостоятельного программирования пока нет.
Был у меня модуль ОТ только внешний, попытался использовать в связке baxi eco4s-овен. При использовании прямых регистров выкл-вкл котла, горячей воды итд прибор нереагировал, отключение котла можно было только уставкой температуры 5градусов, притом контур отопления был всегда на “взводе”. Dwh отключить так и не получилось, Регистры прозрачного обмена работали но через какоето место если честно, т.е если мы ему отправляли команду на отключения, котел отключается показывал off и через какоето время заново включался, было очень много мусора, что просто свело на нет все идеи. Тех поддержка да это что с чемто, даже писать не стоит.
Да, всё, что вы написали выше - верно. Однако, согласно разделу 4.4 спецификации Opentherm, котёл обязан ответить одиним из Slave-to-Master Messages, среди которых сообщение с msg-type равным 0 - отсутствует.
Ещё раз: согласно вашей же документации ответ от котла должен попасть в регистр D1/0209 и дальше в топик ‘TR Command’, а согласно документации Opentherm там не может оказаться 0, который я наблюдаю как на своей инсталяции, так и в вашем примере.
Отчего так?
Тут, увы, уже я не в силах помочь… Если бы у вас был логический анализатор, или прибор типа такого OpenTherm Adapter - Hobby Projects, можно было бы посмотреть, кто именно глючит: или модуль перестаёт правильно запрашивать по шине, или котёл - правильно отвечать. Наверное, если бы у вас был “прозрачный обмен”, было бы больше возможностей “потыкать палкой” в эту нерабочую ситуацию, но и без того, и без этого…
Может быть вам поможет моё наблюдение: мой невотон модуль железно сбрасывается после выдачи на WB команды shutdown -P, но продолжает “глючить” после обычного мягкого reboot (уж не знаю, какие схемотехнические особенности дают такой результа). Соответственно, если у вас после первой процедуры обмен будет восстанавливаться, а после второй - нет, то я, с вероятностью ~98% буду склонен считать это именно проблемой модуля.
Спасибо за предложение, но без прозрачного обмена - пока не могу предложить содержательного теста. С другой стороны, ваш опыт повышает условную вероятность того, что проблемы в модуле (по крайней мере те, с которыми я мучаюсь) появились именно в прошивке 1.3, и IMHO как-то связаны именно с особенностями реализации прозрачного обмена.
Я почитал некоторые ваши сообщения тут, и на форуме ab-log.ru, и для меня ваши проблемы с невотоновским модулем выглядят точно также, как и мои. Не знаю, насколько это сложно на MegaD, был бы вам благодарен, если бы вы помониторили состояние всех modbus регистров (особенно holding) модуля на протяжении часа-двух. Как после “железного” рестарта всех компонентов, так и после чтения “прозрачным обменом” нулевой ячейки котла.
P.S. Интересное наблюдение: судя по вашему опыту, модули глючат и внутренние и внешние, а вот котлы, которые в этом принимают участие, я вижу пока только Baxi (хоть и разных моделей…)
1 раз в сутки опрашиваются редко изменяемые регистры:
register = "00cc"; //Версия прошивки
register = "00d4"; //Верхняя граница температуры ГВС
register = "00d5"; //Нижняя граница температуры ГВС
register = "00d6"; //Верхняя граница температуры котловой воды
register = "00d7"; //Нижняя граница температуры котловой воды
Соответственно, по этим данным строятся графики (по изменению значений с некоторой дельтой). Лог предоставить не могу поскольку не пишу в файл. Наверное можно выгрузить из БД intraHouse, но не думаю, что это будет информативно.
Использовать функционал регистров “прозрачного обмена” пока не планирую, поскольку у нас еще холодно, а котел при этом ведет себя очень неадекватно. Собственно, сейчас у шлюза режим после “железного” рестарта ( с тех пор как год назад закончил эксперименты с ним).
Ну и в качестве вишенки (по крайней мере для меня) - функционально-законченный модуль шлюза в корпусе 1 DIN, который по UART подключен к MegaD-2561:
Не замечали, что, например, значение регистра 00d0 “взбрыкивает”? Если у вас есть возможность посмотреть реальной протокол опроса - было бы интересно. Равно как и добавить в постоянный опрос регистр, например, 00d5. У меня, по наблюдениям, он чаще всего “скачет”.
@Vladimir_Nev_Sup, вы так долго молчите потому, что готовите ответ, или вообще не собираетесь отвечать?
P.S. И ещё я тут обратил внимание, что вы, судя по всему, с самого первого своего содержательного ответа WBE2-I-OPENTHERM проблема 1 - #7 от пользователя Vladimir_Nev_Sup используете у себя для проверки модуль с прошивкой 1.4, тогда как у меня прошивка 1.3, о чём я написал в самом первом посте. Это, мягко говоря, не совсем корректно…
