Приведение значений в шаблонах к нужному диапазону

Здравствуйте. Есть задача привести диапазон 1-100, передаваемый в MQTT к диапазону 85-255, который пойдет в Modbus. Я подобрал коэффициенты для шаблона:
“offset” : -48,
“scale” : 0.585
Но мне нужно, чтобы при получении 0 в MQTT, в Modbus тоже передавался 0.
Средствами шаблонов мне не удастся это реализовать?
И еще сразу вопрос, что значит, если в web-интерфейсе строка ввода значения у устройства подсвечена красным цветом? Хотя все работает правильно.

Есть задача привести диапазон 1-100, передаваемый в MQTT к диапазону 85-255, который пойдет в Modbus. Я подобрал коэффициенты для шаблона:
“offset” : -48,
“scale” : 0.585
Но мне нужно, чтобы при получении 0 в MQTT, в Modbus тоже передавался 0.

Здравствуйте! На данный момент решить такую задачу с передачей нуля помощью шаблона не получится. Это преобразование (когда передается 0) нужно делать либо с помощью написания правила в контроллере Wirenboard либо уже на стороне получателя.

И еще сразу вопрос, что значит, если в web-интерфейсе строка ввода значения у устройства подсвечена красным цветом? Хотя все работает правильно.

Возможно для канала указано поле error_value. При получении из устройства значения регистра равное error_value в веб-интерфейсе параметр будет подсвечен красным цветом, обозначая ошибку устройства (не чтения данных): Драйвер wb-mqtt-serial: шаблоны — Wiren Board

Либо у канала топик …/meta/error не равен null. Либо он равен r (ошибка чтения), либо w (ошибка записи). Это можно посмотреть на вкладке Settings->MQTT Channels. То есть проблема может быть в считывании или записи регистра.

.
Также при проблемах со связью будут выведены сообщения в лог. Просмотреть сообщения от драйвера за последний час можно командой в bash:

journalctl --since "1 hour ago" | grep wb-mqtt-serial

В данном случае можно попробовать подобрать (увеличить) таймауты и интервалы настроек связи (описаны на странице шаблонов):

  • poll_interval — минимальный интервал опроса регистров устройства в миллисекундах.
  • response_timeout_ms — максимальное время ожидания ответа от устройства в миллисекундах. Если в течение этого времени ответ не будет получен — драйвер продолжит опрос других регистров и устройств.
  • frame_timeout_ms — минимально необходимая задержка между посылками в миллисекундах.
  • guard_interval_us — дополнительная задержка перед каждой отправкой данных в порт в микросекундах. Если при работе с устройством теряются пакеты — попробуйте увеличить значение этого параметра.
  • device_timeout_ms — интервал, по истечении которого (а также device_max_fail_cycles) устройство будет помечено отключенным и будет опрашиваться в ограниченном режиме.

Возможно poll_interval установлен слишком малым, контроллер не успевает его так часто опрашивать или надо увеличить guard_interval_us.

Да, действительно, проблема с чтением из регистра. На запрос чтения из регистра устройство возвращает ответ с кодом ошибки 3 (Illegal Data Value), но это и не страшно, т.к. данный регистр предназначен для записи в него новых значений. Как сделать так, что бы WB не реагировал на эту ошибку чтения? “enabled”: false в параметрах канала не решает проблему

Это довольно странно, что регистр можно записывать, но нельзя читать. Вы уверены в этом? Видимо, это не совсем соответствует стандарту Modbus.

Если у вас этот регистр описан каналом в шаблоне, то контроллер всегда будет пытаться его считать. А если при этом будет выдаваться ошибка, то поле будет подсвечиваться красным.

Покажите, пожалуйста, весь шаблон. Тип регистра (reg_type) указываете “holding”, формат (format) “u16”? Можно попробовать считать и записать его утилитой modbus_client, будет ли ошибка?

config-dali_gw2.json (735 Байт)
Шлюз_DALI_GW2_Руководство_пользователя.pdf (1.7 МБ)
Это шлюз от ECODim DALI GW2. Сейчас пытаюсь выяснить этот вопрос у производителя

Вот ответ производителя.
В РЭ эти регистры обозначены как доступные для записи. К сожалению, в Modbus отсутствует класс регистров “write only”, но их создание для нашего шлюза было вынужденной мерой.

Дело в том, что шлюз при обращении к регистрам старше 1000 сразу же пишет команды в линию DALI. Поэтому для того, чтобы избежать лишних обращений в линию пришлось разнести это по разным регистрам: два регистра для команд и три регистра для статусов.

Потом выяснилось, что это приводит к ошибочной трактовке происходящего: разработчик записал регистр 2000 и его же читает, трактуя это как результат запроса QUERY ACTUAL LEVEL. Тогда пришлось сделать регистры для команд “write only”, чтобы при неправильной работе это сразу выдавало ошибки, а не давало себя знать на объекте в виде “все контролы показывают 100%, а света нет”

Соответственно, мне необходимо предпринять что-то на стороне WirenBoard для того, чтобы логи не забивались не имеющими значения записями об этих ошибках. Что я могу предпринять?

Я вижу следующие варианты:

  1. Можно только для этого канала установить большой интервал опроса, например, 600000 мс (10 минут) или даже 3600000 (1 час). Тогда этот регистр будет читаться один раз в течение заданного интервала времени, и сообщение об ошибке будет в логах появляться только раз в этот интервал. На время записи это не повлияет. Однако в веб-интерфейсе этот параметр все равно будет помечен красным цветом.
		{
			"name" : "G1_valSet",
			"reg_type" : "holding",
			"address" : 2005,
			"type": "dimmer",
			"scale" : 0.583,
			"offset" : -48,
			"format": "u16",
            "poll_interval": 3600000	
		}
  1. Подключить устройство на отдельный порт и не использовать сервис wb-mqtt-serial для этого порта (снять галочку Enable port). Для отображения и изменения значения регистров в веб-интерфейсе использовать виртуальное устройство. Чтение и запись регистров можно осуществлять с помощью движка правил по таймеру, используя команду runShellCommand(cmd, options), как описано здесь: https://github.com/wirenboard/wb-rules. В качестве команды использовать утилиту modbus_client (https://wirenboard.com/wiki/Modbus-client). Соответственно в проблемный регистр только записывать данные, но не читать.

Мы поддержали шлюз ECOdim DALI GW2 в ПО контроллера, подробнее читайте в документации.

1 лайк