WBE2-I-OPENTHERM проблема 3

Загадки “прямого обмена”.
Ввводные те же (см. WBE2-I-OPENTHERM проблема 1)

В документации (OpenTherm_Modbus_BCG-1.0.2-W.pdf) работа с регистрами 40209, 40210, 40211 описана как “…В случае прохождения проверки валидности данных регистр обнуляется и в нем записывается ответ от котла/ID отправленной команды/возвратные данные от котла”
В действительности, всё происходит не совсем так, или совсем не так. Вот, например, вывод команды “mosquitto_sub -v -t ‘#’|grep opentherm” запущенной параллельно подаче команд на чтение из ячейки 0:

/devices/wbe2-i-opentherm_11/controls/TR Command/on 2
/devices/wbe2-i-opentherm_11/controls/TR ID/on 0
/devices/wbe2-i-opentherm_11/controls/TR Data/on 4864
/devices/wbe2-i-opentherm_11/controls/TR Command 2
/devices/wbe2-i-opentherm_11/controls/TR Data 4864
/devices/wbe2-i-opentherm_11/controls/TR Data 0
/devices/wbe2-i-opentherm_11/controls/TR Command 0
/devices/wbe2-i-opentherm_11/controls/TR Data 65
/devices/wbe2-i-opentherm_11/controls/TR Command 4

тут видно, что после отсылки данных в топики, ‘TR Data’ и ‘TR Command’ действительно обнулились, а от ‘TR ID’ не пришло никакого отклика. Затем в Data пришли данные, а в Command - 4/READ-ACK. Очень похоже на описание.

однако, если послать команду чтения ячейки 0, передав параметр 0, получим

/devices/wbe2-i-opentherm_11/controls/TR Command/on 2
/devices/wbe2-i-opentherm_11/controls/TR ID/on 0
/devices/wbe2-i-opentherm_11/controls/TR Data/on 0
/devices/wbe2-i-opentherm_11/controls/TR Command 2
/devices/wbe2-i-opentherm_11/controls/TR Command 0
и тишину…

т.е. “обнуление” произошло только для ‘TR Command’. Ни ‘TR ID’, ни ‘TR Data’ о своём обнулении не сообщили, равно как и не прислали никаких данных.
Можно было бы заподозрить, что “пропадают” повторяющиеся данные (т.е. если в регистре был 0, запись туда 0, или следующее по описанию “обнуление”, не приводит к публикации в соответствующем топике нуля, но в последнем случае в ‘TR Command’ должно было, в итоге, оказаться значение, отличное от 0 (либо 4/READ-ACK, либо 6/DATA-IVALID, либо 7/UNKNOWN-DATAID)…
Аналогичные проблемы происходят и другими ячейками. Например, у меня не читается (по полному циклу) ячейка 5 (Boiler faults) если из неё, предположительно, должен считываться 0 (нет ошибок).

P.S. Про то, что результаты “обнуления” и данные могут приходить в произвольном порядке (т.е. сначала ‘TR Command’ c ACK, а потом уже ‘TR Data’ с данными, или наоборот, сначала ‘TR Data’ а за ними ‘TR Command’; а иногда даже данные вперёд “обнуления”) я уже и не говорю… С этим можно как-то жить.

Стоит пригласить @Vladimir_Nev_Sup

Очень интересно будет узнать результат… просто у себя дома тоже хочу подсоединить Baxi ECO4S 1.24 F по opentherm

Да уж… мне самому интресно… К сожалению, @Vladimir_Nev_Sup c 20 февраля тут не появлялся, и заменить его, похоже, некому :frowning:

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

Попрошу обратить внимание, благодарю за то что написали.
По механизму работы внутри самого шлюза - да, скорей всего так.

Доброе утро! Ну так проблема то будет решена? А то у меня сейчас, как в Нашей Раше, “…чего-то я очкую Славик…” =))

Владимир уже онлайн, думаю ответит.

Поскольку никакой реакции на этот пост от @Vladimir_Nev_Sup я не получил, попробую ещё раз задать тот вопрос, ответ на который я хотел бы узнать:

У меня последовательность команд

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 '0'

приводит к такой реакции модуля (проверяется запуском в другой терминальной сессии команды mosquitto_sub -v -t '#'|grep opentherm перед выдачей в основной сессии команд mosquitto_pub)


/devices/wbe2-i-opentherm_11/controls/TR Command/on 2
/devices/wbe2-i-opentherm_11/controls/TR ID/on 0
/devices/wbe2-i-opentherm_11/controls/TR Command 2
/devices/wbe2-i-opentherm_11/controls/TR Data/on 0
/devices/wbe2-i-opentherm_11/controls/TR Command 0

Почему в топик /devices/wbe2-i-opentherm_11/controls/TR Command не публикуется 1,4,5,6 или 7, как это должно быть, согласно документации (OpenTherm_Modbus_BCG-1.0.2-W.pdf стр. 10) ?

Никогда не пишите в ID 0 значение 0, даже на чтение. Потому что вы сделали так. Сформировали технически правильный для модуля пакет. Отправили котлу. Котёл на него никак не отреагировал. И ничего не ответил. В лучшем случае он его просто проигнорировал. В худшем 0 - это все биты статуса котла в 0. 0 = отключить.
Поскольку 1,4,5,6,7 - это значения, полученные от котла. Модуль их сам не формирует. Проверьте прозрачный обмен так. Измените ID на любой другой, параметр которого можно получить: 17, 18, 26, 25, 27. Либо оставьте ID 0, но Data измените, согласно битовому описанию.

Пример прозрачного обмена с ID 0 я вам привёл в : Проблема 1.

Чего-то я не понимаю… Ни в вашей инструкции (OpenTherm_Modbus_BCG-1.0.2-W.pdf) ни в спецификации протокола (Opentherm Protocol v2-2.pdf), никаких ограничений на чтение ячейки 0 (а именно data-id 0, насколько я понимаю вашу инструкцию, соответствует публикация ‘0’ в топик ‘TR ID’) не наблюдается. И то, что должно, после выполнения модулем переданной команды, оказаться в регистре D1/0209 и/или mqtt топике ‘TR Command’, может быть как ответом самого модуля (‘1’) так и ответом котла (‘4’, ‘5’, ‘6’, ‘7’). По крайней мере так я понимаю вашу документацию. И прошу ответить, почему в данном конкретном случае в регистре D1/0209 и/или mqtt топике ‘TR Command’ не появляется ни один из результатов, которые описаны в вашей документации, на странице 10: В случае прохождения проверки валидности данных регистр обнуляется и в нем записывается ответ от котла: 4,5,6,7 (согласно спецификации Opentherm 4.2.2 Message Type). В случае непрохождения проверки валидности – записывается 1.

Ограничений нет, просто если вы записываете 0, вы должны понимать что вы отключаете все контура. И я хочу быть уверен, что вы в этом разбираетесь) Просто есть люди, которые могут отключить контура, просто записав 0, а потом не могут построить побитово команду для их включения. Это я так, по привычке написал.

Ок, разобрались. Ограничений нет, и я - не те “люди, которые могут отключить контура”.
Но ведь и значения, которое должно быть, согласно документации, тоже нет! И вы этот факт упорно отказываетесь и признавать, и комментировать!

Вы так и не воспроизвели последовательность действий из моего поста за 26 марта WBE2-I-OPENTHERM проблема 3 - #9 от пользователя hamster
Было бы очень интересно узнать, насколько в версии 1.4 исправлены баги “прозрачного обмена”…

Добрый день. Сообщите статус вашей проблемы.

В версии прошивки 1.7.3 проблема не решена. Прозрачный обмен работает крайне не стабильно, а, в некоторы ситуациях, не работает вообще.