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), не заметно стремления “довести устройство до ума”…

2 лайка

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

1 лайк

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

1 лайк

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

Поскольку никакой реакции на этот пост от @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 исправлены баги “прозрачного обмена”…