И да, я, наконец-то собрался причесать свой NOTExplorer - думаю, всем, кто мучается со своими котлами и невотоновским модулем, она может оказаться полезной…
Добрый день. Вижу в логах у вас скачки. Это странно. Сейчас ставлю на сутки модуль в WB 7 и котёл Thermona:
Потом возьму логи, сравним. Длина кабеля ~12м, сигнальный, экранированный. Если не повторится, 2 варианта, либо неисправный модуль, можно прислать нам, я его поставлю и также проверю, попытаюсь повторить, либо помехи появляются ещё до вхождения данных в модуль.
Насчёт прозрачного обмена. Проверил его в Node-Red сейчас на WB. Порядок такой. Последовательно записываю 209 ячейку 2 (чтение данных) 210 - 18 (ID команды (давление)), 211 - 0 (поскольку чтение). Результат на последним скриншоте.
512/256 = 2 бар. Как на виджете выше.
Теперь сразу же запрос на чтение статуса котла:
P.S. 4 - Read Acknowledged. Согласно протоколу Opentherm.
То есть в моей связки я, к сожалению, не вижу проблем в работе прозрачного обмена. Если со стороны котла модулю ничто не мешает считывать/записывать параметры, модуль это без проблем сделает
Мн-э-э-э… может это, конечно, я как-то не так спрашиваю, но ни на одну из проблем, которые я описал, и ни на один из вопросов, которые задал, я не получил вообще никакого ответа. Попробую ещё раз, предельно конкретно.
- У меня котёл выключается (переходит в состояние OFF), при чтении с помощью прямого обмена ячейки 0, с передачей в качестве данных любого ненулевого значения. Конкретно, после выполнения команд
mosquitto_pub -t '/devices/wbe2-i-opentherm_11/controls/TR Command/on' -m '2'
mosquitto_pub -t '/devices/wbe2-i-opentherm_11/controls/TR ID/on' -m '0'
mosquitto_pub -t '/devices/wbe2-i-opentherm_11/controls/TR Data/on' -m '256'
- Модуль невотон производит неконтролируемые спонтанные действия. Отследить их у меня получается задав команду
mosquitto_sub -v -t '#'|grep opentherm
и оставив её поработать некоторое время (30-60 минут) в терминальной сессии. В моём случае выводятся изменения значений параметров управления, которые я не менял.
- Опишите, пожалуйста, логику работы модуля с ячейкой 0 ведомого устройства по протоколу opentherm. Как можно повлиять на данные, которые передаются модулем в ведомое устройство при её чтении (например, чтобы включить/выключить контуры отопления и горячего водоснабжения)?
P.S. Буду блаодарен, если другие обладатели модуля WBE2-I-OPENTHERM смогут провести эти нехитрые опыты на своём оборудовании, и поделятся результатами.
P.P.S. Сейчас между модулем и котлом используется экранированная витая пара, 24AWG, по одной паре на каждую линию (т.е. всего используется 4 провода из 8), общей длиной около 1.7 метра.
Логика работы с ID0. Вы всегда её читаете. В отличии от всех команд, даже на чтение, вы можете в Data записать желаемые значения.
Пример. Сейчас у меня на котле.
Это 0001 0011 0000 1010. Либо:
Я хочу отключить контур ГВС. Это 0001 0001 0000 1010 либо 4362
Записал. Смотрю статус.
Как видите, он изменился. Котёл принял новые данные через прозрачный обмен.
Тут описаны биты и их назначение (стр 24):
Протокол OT
Владимир, давайте всё-таки исходить из того, что я представляю себе логику работы opentherm протокола, а в этом общении пытаюсь понять логику работы вашего шлюза.
Вы как-то постоянно пытаетесь уйти от прямых ответов на мои конкретные вопросы, и это меня, честно говоря, расстраивает… Но я обещаю быть терпеливым и понятливым.
Итак, в третий раз переформулирую свои вопросы, чтобы (как мне кажется) облегчить вам их понимание, и, соответственно, увеличить свои шансы на получение ответа.
- Я хочу включить у своего котла контур отопления. Для этого я передаю в шлюз команду прозрачного обмена на чтение ячейки котла 0, с установленным битом 1 старшего байта в пакете данных на чтение. Чтобы исключить влияние посторонних программ (типа NodeRed) а также плохо контролируемых и документируемых действий в WebUI, я использую утилиты командной строки, предназначенные для отслеживания и публикации данных в mqtt. А именно: в одной терминальной сессии я запускаю команду
mosquitto_sub -v -t '#'|grep opentherm
для отслеживания обмена с модулем по интерфейсу mqtt, а в другой - последовательно команды
mosquitto_pub -t '/devices/wbe2-i-opentherm_11/controls/TR Command/on' -m '2'
mosquitto_pub -t '/devices/wbe2-i-opentherm_11/controls/TR ID/on' -m '0'
mosquitto_pub -t '/devices/wbe2-i-opentherm_11/controls/TR Data/on' -m '256'
У меня после этих действий котёл переходит в состояние 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 - это поднятый восьмой бит (0b100000000)
Драйвер запишет в регистр 0x100
То есть это нулевой бит старшего байта (CH).
Повторил, как вы и просили. Отправил 256, получил 258. Дал разрешение на использование контура и котёл тут же его включил. Повторюсь. В своей связки модуля котла (Thermona) я не вижу проблем с прозрачным обменом.
Cпасибо! На часть вопросов ответы я получил, хотелось бы прояснить и остальные (вопросы 2 и 3 из моего предыдущего сообщения в этой ветке обсуждения, и вопросы в WBE2-I-OPENTHERM проблема 2 - #5 от пользователя hamster и WBE2-I-OPENTHERM проблема 3 - #11 от пользователя hamster
В качестве замечания: в приведённом вами протоколе обмена последнее значение ‘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) модуля на протяжении часа-двух. Как после “железного” рестарта всех компонентов, так и после чтения “прозрачным обменом” нулевой ячейки котла.