Написать в техподдержку чтобы выслали последнюю версию прошивки? Или есть ссылка на нее. Я сам могу прошить.
Да, всё, что вы написали выше - верно. Однако, согласно разделу 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 (хоть и разных моделей…)
Рискну напомнить, что до сих пор жду от вас ответов на вопросы 2 и 3 этой темы (WBE2-I-OPENTHERM проблема 1 - #12 от пользователя hamster), и вопросы в темах WBE2-I-OPENTHERM проблема 2 и WBE2-I-OPENTHERM проблема 3
Спасибо!
У меня 1 раз в 30 секунд опрашиваются постоянно изменяемые регистры:
register = "00cd"; //Статус котла
register = "00ce"; //Ошибка котла
register = "00cf"; //Температура отопления текущая
register = "00d0"; //Температура горячей воды текущая
register = "00d1"; //Уровень модуляции пламени горелки
register = "00d2"; //Давление (P*10)
register = "00d3"; //Температура внешняя ((Т+100)*10)
register = "00d8"; //Температура обратки текущая
1 раз в сутки опрашиваются редко изменяемые регистры:
register = "00cc"; //Версия прошивки
register = "00d4"; //Верхняя граница температуры ГВС
register = "00d5"; //Нижняя граница температуры ГВС
register = "00d6"; //Верхняя граница температуры котловой воды
register = "00d7"; //Нижняя граница температуры котловой воды
Соответственно, по этим данным строятся графики (по изменению значений с некоторой дельтой). Лог предоставить не могу поскольку не пишу в файл. Наверное можно выгрузить из БД intraHouse, но не думаю, что это будет информативно.
Использовать функционал регистров “прозрачного обмена” пока не планирую, поскольку у нас еще холодно, а котел при этом ведет себя очень неадекватно. Собственно, сейчас у шлюза режим после “железного” рестарта ( с тех пор как год назад закончил эксперименты с ним).
Ну и в качестве вишенки (по крайней мере для меня) - функционально-законченный модуль шлюза в корпусе 1 DIN, который по UART подключен к MegaD-2561:
1 лайк
Не замечали, что, например, значение регистра 00d0 “взбрыкивает”? Если у вас есть возможность посмотреть реальной протокол опроса - было бы интересно. Равно как и добавить в постоянный опрос регистр, например, 00d5. У меня, по наблюдениям, он чаще всего “скачет”.
@Vladimir_Nev_Sup, вы так долго молчите потому, что готовите ответ, или вообще не собираетесь отвечать?
P.S. И ещё я тут обратил внимание, что вы, судя по всему, с самого первого своего содержательного ответа WBE2-I-OPENTHERM проблема 1 - #7 от пользователя Vladimir_Nev_Sup используете у себя для проверки модуль с прошивкой 1.4, тогда как у меня прошивка 1.3, о чём я написал в самом первом посте. Это, мягко говоря, не совсем корректно…
Давайте так - у данного шлюза все регистры “взбрыкивают”! Как сказали разработчики - это от того что у меня модуль не в составе Wirenboard, соответственно, они не могут гарантировать его правильную работу… Видимо UART микроконтроллера MegaD-2561 с питанием 3.3В сильно отличается от UART ARM-процессора, ну и питание конечно же в MegaD сделали не по стандартам WB (все сарказм).
D5, как ранее писал, у меня не стоит на постоянном опросе (оно же совсем не нужно!). По графикам можно посмотреть как “взбрыкивают” регистры. Особенно меня бесит статусный регистр (обратите внимание на график там где отображен бит " Статус ГВС") - очень часто в нем не актуальная информация. Но как только использую регистры “прозрачного обмена” то статусный регистр вообще перестает нести полезную информацию.
Нда… если графики, подписанные “(OT)” - это как раз те данные, что невотоновский модуль выдаёт через свои регистры, то “пики” на них - полностью соответствуют анамнезу в моем случае. Только у меня-то никакого MegaD нет, “честный” Wirenboard. Что совершенно не мешает отмораживаться и поддержке виренборда и, особенно, невотона 
Вы абсолютно правы! Лишние кривые я отключил, остались только те, которые OpenTherm. Соответственно, там где вдруг появились экстремумы - это “взбрыкивания” в регистрах. Особо обратите на “Газовый котел - статус ГВС” - там где рыжая заливка широкая - это шел подогрев ГВС в бойлере косвенного типа, а все остальное - “артефакты”!
Тут, скорее всего, поддержка Wirenbord помочь не сможет. Судя по описанию - дело в обмене именно Opentherm.
Андрей, судя по ряду признаков (напрмер, по тому, что одинаковые симптомы проявляются в разных условиях у разных людей, и по тому, что “глючат” внутренние регистры модуля (см. пример unsolicited изменения значения “TR Command” выше), не связанные напрямую с опросом по шине opentherm), проблема именно в самом модуле, а не в окружающей его инфраструктуре. Причём, проблема, как мне сейчас кажется, скорее софтовая. Само собой, “кажется” - это слабый аргумент, но 35 лет опыта профессиональной разработки ПО дают богатую пищу интуиции. И в данной ситуации это увы, практически единственное, на что я могу рассчитывать, ибо со стороны Невотона (не поленюсь ещё раз упомянуть тут @Vladimir_Nev_Sup) стремления разобраться в проблеме и решить её я не наблюдаю. И хотя я понимаю ограниченность ваших возможностей в данном конкретном случае, модуль-то я покупал у вас, и по формальным признакам (по ГК РФ) я имею полное право на ваше участие в решении проблемы. Хотя бы в части стимулирования к решению Невотона…
P.S. И, кстати, моё письмо вам, тут, в “личных сообщениях”, на смежную тему, тоже уже больше недели остаётся без ответа
@hamster Если у вас, или у кого-то есть возможность изменить, например, скорость в меньшую сторону и проверить, будут ли такие же всплески, я буду признателен. Я не игнорирую ответы и читаю каждое сообщение. Просто физически на неделе не было возможности быть на форуме из-за основной работы. Для мониторинга modBus регистров я использую ModLook или логи WirenBoard. Даже с частотой опроса 50 мсек я не вижу там скачков данных. Добавил динамические и статические параметры в графики. Вечером сделаю скрин лога и посмотрю, увижу ли какие-либо всплески.
“скорость”, в данном случае, - это что? Baudrate? Response timeout? Read rate limit? Для порта? Для устройства? Сейчас у меня все настройки - по умолчанию. Baudrate - 19200, Response timeout 500ms,оба Read rate limit 1000ms, для всех значений Poll in queue order
Это здорово, что вы читаете мои сообщения, но но они не столько повествовательные, сколько вопросительные, и я рассчитываю, что вы будете мои сообщения не только читать, но и отвечать на вопросы, которые я там задаю…
В стандартной поставке wirenboard нет ModLook. И какие именно “логи WirenBoard” - вы ни разу не пояснили (в /var/log/messages значения wb-mqtt-serial не пишутся). А вот mosquitto_sub - есть, и он прекрасно справляется со своей функцией. Давайте, всё-таки, использовать его! В четвёртый(!) раз предлагаю вам запустить команду mosquitto_sub -v -t '#'|grep opentherm и помониторить час-два её вывод. Три предыдущих раза вы не откликнулись на мою просьбу, и не привели никаких соображений, почему… Почему?
Просто для информации: графики wirenboard webui строятся по данным wb-mqtt-db, а он их (обычно) усредняет.
Вы, кстати, всё так же продолжаете свои наблюдения за модулем с прошивкой 1.4? У меня, напоминаю, версия прошивки 1.3!
@hamster Выкладываю лог файл с записью уставки ЦО и ГВС и отключением контура через прозрачный обмен:.
Лог файл WB2-i-opentherm.xls (58 КБ)
1 лайк
@hamster Если хотите, могу запустить снова команду на другие сценарии работы котла, с другими командами прозрачного обмена или задания уставок.
А какое время после выдачи команды прозрачного обмена шло протоколирование?
P.S. Впрочем, это не очень важно. Вы снова тестируете свою прошивку версии 1.4, тогда как у меня (и я несколько раз это повторил) - версия 1.3