Плагин Modbus



  • @Viktor, добрый день, спасибо за тестирование!

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

    Попробовали воспроизвести ситуацию.
    У WB шлюза есть флаг - Сбрасывать старые соединения:
    wb-mge.jpg

    Если этот флаг убрать, то действительно со второго раза соединение не восстанавливается.
    При установленном флаге переподключение к существующим адресам у нас происходит нормально.

    1. Не запускается V14.

    Там добавлен новый параметр в настройках плагина:
    "Позиция байта в слове (для 1-байтовых значений)"
    Если его оставить пустым, то происходит вот это: unit8undefined
    Поправим, чтобы было значение по дефолту, но плагин должен работать.

    Ну а сообщение modbus1: undefined просто означает, что плагин в текущий момент запущен, но еще не прислал сообщений с момента открытия отладчика 😞



  • @intrapro Про флаг в настройках шлюза WB - да, так и есть. Спасибо, заработало.
    А вот с параметром "позиция байта в слове для 1-байтовых значений" вопрос: там в настройках плагина выпадающий список из двух значений, по дефолту значение есть и убрать его мы не смогли.
    Есть вопрос с параметром канала "смещение" - это что? и как это должно работать? Просто у нас ничего не меняется от этого параметра.
    И еще вопрос стабильности возникает, который возможно и является причиной ложных ошибок: например сегодня однобайтовые в тех же устройствах берет без ошибки, но зато через раз лог выглядит так: (с задвоениями)

    20.12 05:31:23.090 modbus1: READ: unitId = 2, FC = 3, address = 0x9C40 (0x9c40), length = 2
    20.12 05:31:23.090 modbus1: READ: unitId = 2, FC = 3, address = 0x9C40 (0x9c40), length = 2
    20.12 05:31:23.120 IH: get [ { id: 'ch17', value: 33620271 } ]
    set { parse_kdl: { aval: 1, err: 0 } }
    20.12 05:31:23.120 IH: get [ { id: 'ch17', value: 33620271 } ]
    set { parse_kdl: { aval: 1, err: 0 } }
    20.12 05:31:23.320 modbus1: READ: unitId = 2, FC = 3, address = 0x9C87 (0x9c87), length = 1
    20.12 05:31:23.320 modbus1: READ: unitId = 2, FC = 3, address = 0x9C87 (0x9c87), length = 1
    20.12 05:31:23.348 IH: get [ { id: 'ch18', value: 187 } ]
    set { ch71: { aval: 187, err: 0 } }
    20.12 05:31:23.348 IH: get [ { id: 'ch18', value: 187 } ]
    set { ch71: { aval: 187, err: 0 } }
    20.12 05:31:23.549 modbus1: READ: unitId = 1, FC = 4, address = 0x5000 (0x5000), length = 2
    20.12 05:31:23.549 modbus1: READ: unitId = 1, FC = 4, address = 0x5000 (0x5000), length = 2
    20.12 05:31:23.610 IH: get [ { id: 'ch10', value: -223084544 } ]
    set {}
    
    

    В чем причина?



  • Участник @Viktor написал в Плагин Modbus:

    А вот с параметром "позиция байта в слове для 1-байтовых значений" вопрос: там в настройках плагина выпадающий список из двух значений, по дефолту значение есть и убрать его мы не смогли.

    Убирать не надо. Проблема была, что там как раз не было значения (undefined) при обновлении плагина, так как до 14 версии параметра "порядок для 1-байтовых значений" не было.
    В целом, важно проверить порядок байт в параметрах. Для WB все настройки порядка байт должны быть BigEndian (в том числе 4-байтовое значение, там по умолчанию стоит swap BE).

    Есть вопрос с параметром канала "смещение" - это что? и как это должно работать? Просто у нас ничего не меняется от этого параметра.

    Смещение планировали использовать, если задавать адрес внутри регистра, а не чистый адрес Modbus. Но отказались от этой идеи, поэтому смещение в новой версии убрали совсем.

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

    Пытались у себя смоделировать задвоение, но не удалось.
    Это не двойной опрос по модбас, время совпадает до милисекунд.
    Вероятно, это связано не с плагином, а с подпиской на сообщения отладчика, просто сервер отдает каждое сообщение дважды 😞

    Опубликован новый релиз плагина v0.0.16:
    https://github.com/intrahouseio/intraHouse.plugin-Modbus/releases/tag/v0.0.16

    • убрано смещение
    • изменена функция записи
    • исправлена ошибка: в случае ошибки плагин не останавливался командой Stop, а продолжал Try reconnect.


  • Коллеги, помогите!
    Пытаюсь подружить связку DHT22/18b20 на пин Mega2560 -> (RX1/TX1) передача по modbusRTU через max485 и RS485/USB) -> Raspberry pi4 с установленной IntraHouse light v4.7.0 (11.11.19).

    Выдаю в Serial в Arduino IDE (на Rpi, в которую по USB воткнута Mega2560) - все хорошо - данные показываются корректно! Принимаю в плагине Modbus в IntraHouse light - белиберда какая-то показывается (ниже), но прием в отладке идет без ошибок...
    в Serial
    в интре в настройках плагина
    в интре на экране
    Что смущает: со стороны Mega2560 значение формируется в два регистра типа float, а кода в IntraHouse light я на AI ставлю принять во float, указывая номер первого регистра - приходит чушь.

    Прошу помочь...



  • Добрый день! Что можно проверить

    1. Порядок байтов для 4-байтного значения в настройке плагина

    modbus_float.png

    Тип float занимает 4 байта или 2 слова, т.е. 2 регистра modbus, возможно 4 варианта. Можно посмотреть в документации, либо просто перебором проверить. По умолчанию идет swap слов, так работают контроллеры Wago, Овен
    2. Адрес регистра. В IH адрес - это фактический адрес, который будет передаваться в запросе Modbus, нумерация идет с нуля.



  • @intrapro пасибо, все заработало!



  • @kostinanton А в чем была причина? Чтобы ваши последователи были в курсе 🙂



  • @intrapro дело в том, что лучше, когда работаешь с float, не забывать перед выводом в любой протокол его преобразовывывать в integer с увеличением разрядности, т. к. каждое оборудование/софт себя по разному ведет (в своём случае я вначале значение датчиков dht22 и 18b22 перед передачей в протокол умножил на 100, чтобы на выходе получить два знака после запятой), а уже на конечной скаде вернуть обратно (в своём случае - в интре в настройках плагин modbus в обработке параметра датчика выполнил value/100 )... В плагине в настройках канала устройства - аналоговый вход, uint16, fc4-read... Вроде все)))
    И ещё - при работе с modbus надо не забывать про типы используемых регистров, конечно же))



  • @kostinanton понятно, спасибо



  • Новая итерация плагина стабильнее. Не уходит в стоп, в случае не ответа какого-либо устройства. Спасибо.



  • А у меня последняя версия плагина дважды теряла соединение с модбас устройством.
    Помогает перезапуск плагина руками.
    Все версии до этого работали стабильно.



  • @Erik согласно просмотренным логам, ни одного обрыва после установления соединения у мня не было...



  • У меня останавливается в среднем раз в неделю.
    Сегодня утром обнаружил очередной сбой.

    08.03 07:03:37.165 IH: get [ { id: 'TPSuStatus', value: 0 } ]
    set { ACTORA34: { aval: 1, err: 0 } }
    08.03 07:03:37.168 modbus1: undefined
    08.03 07:03:40.443 modbus1: READ: unitId = 1, FC = 3, address = 4166 (0x1046), length = 1
    08.03 07:03:43.826 IH: get [ { id: 'TPKuMin', value: 250 } ]
    set { ACTORA24: { aval: 25, err: 0 } }
    08.03 07:03:47.235 modbus1: READ: unitId = 1, FC = 3, address = 4167 (0x1047), length = 1
    08.03 07:03:52.063 IH: get [ { id: 'TPKuMax', value: 270 } ]
    set { ACTORA25: { aval: 27, err: 0 } }
    08.03 07:03:54.400 modbus1: READ: unitId = 1, FC = 3, address = 4174 (0x104e), length = 1
    08.03 07:03:57.734 IH: get [ { id: 'Sdvig.RO.Ku', value: 10 } ]
    set { ACTORA76: { aval: 1, err: 0 } }
    08.03 07:04:01.220 modbus1: READ: unitId = 1, FC = 3, address = 4176 (0x1050), length = 1
    08.03 07:04:04.775 IH: get [ { id: 'TKuOFF', value: 50 } ]
    set { ACTORA21: { aval: 5, err: 0 } }
    08.03 07:04:08.128 modbus1: READ: unitId = 1, FC = 3, address = 4186 (0x105a), length = 1
    08.03 07:04:11.523 IH: get [ { id: 'TKuComf', value: 230 } ]
    set { ACTORA19: { aval: 23, err: 0 } }
    08.03 07:04:16.348 modbus1: READ: unitId = 1, FC = 3, address = 4187 (0x105b), length = 1
    08.03 07:04:19.667 IH: get [ { id: 'TKuEco', value: 100 } ]
    set { ACTORA20: { aval: 10, err: 0 } }
    08.03 07:04:22.850 modbus1: READ: unitId = 1, FC = 3, address = 4188 (0x105c), length = 1
    08.03 07:04:26.271 IH: get [ { id: 'RezKu', value: 0 } ]
    set { ACTORA4: { aval: 0, err: 0 } }
    08.03 07:04:31.082 modbus1: READ: unitId = 1, FC = 3, address = 4189 (0x105d), length = 1
    08.03 07:04:34.644 IH: get [ { id: 'TKuTreb', value: 230 } ]
    set { ACTORA26: { aval: 23, err: 0 } }
    

    перезапуск плагина помогает.



  • Зависает. Плагин не в стопе. Лог плагина пишет : Network error: ETIMEDOUT.
    Перезапуск плагина помогает. Начинает работать.



  • Из темы про сценарии

    Пользователь @intrapro написал в Сценарии - новая версия API:

    @Erik
    Спасибо за тестирование, действительно, есть проблема с записью отрицательных целых значений в библиотеке modbus-serial.
    В новой версии библиотеки эта проблема исправлена. Проверим у себя и на следующей неделе выпустим новый релиз плагина

    Не получилось, или забыли?



  • Пользователь @Erik написал в Плагин Modbus:

    Не получилось, или забыли?

    Не забыли. Нашли еще баг в плагине. Надо с ним разобраться.



  • Сегодня утром опять все актуаторы обновляемые по модбас были в ошибках.
    Запустил отладчик. Он сначала тупил (очень медленно выдавал инфу), а потом вдруг сам справился с ситуацией и начал работать. Без перезагрузки плагина.

    20.03 07:53:55.531 IH: get [ { id: 'GK.T.Obr', value: 255 } ]
    set { ACTORA56: { aval: 25.5, err: 0 } }
    20.03 07:53:59.666 modbus1: undefined
    20.03 07:53:59.667 modbus1: Port is not open! TRY RECONNECT
    20.03 07:53:59.667 modbus1: Connecting options = { port: 502 }
    20.03 07:54:03.821 modbus1: READ: unitId = 1, FC = 3, address = 0431 (0x1af), length = 1
    20.03 07:54:11.471 IH: get [ { id: 'Tobr', value: 258 } ]
    set { ACTORA2: { aval: 25.8, err: 0 } }
    20.03 07:54:19.019 modbus1: READ: unitId = 1, FC = 3, address = 434 (0x1b2), length = 1
    20.03 07:54:26.545 IH: get [ { id: 'GK.Stup1', value: 0 } ]
    set { ACTORA54: { aval: 0, err: 0 } }
    20.03 07:55:16.572 IH: Plugin exit with code null
    20.03 07:55:16.575 IH: restart timer 5
    20.03 07:55:22.137 IH: Run /var/lib/intrahouse-c/plugins/modbus/modbus.js modbus1
    20.03 07:55:22.889 modbus1: Modbus Master plugin has started.
    20.03 07:55:22.896 modbus1: Received params...
    20.03 07:55:22.906 modbus1: Received 72 channels...
    20.03 07:55:22.914 modbus1: Requested channels update. Get channels: no
    20.03 07:55:22.929 modbus1: Connecting options = { port: 502 }
    20.03 07:55:22.943 modbus1: Connected to 192.168.13.25:502
    20.03 07:55:22.944 modbus1: READ: unitId = 1, FC = 3, address = 144 (0x90), length = 1
    20.03 07:55:22.960 IH: get [ { id: 'TUl', value: 29 } ]
    set { ACTORA1: { aval: 2.9, err: 0 } }
    20.03 07:55:23.159 modbus1: READ: unitId = 1, FC = 3, address = 407 (0x197), length = 1
    20.03 07:55:23.164 IH: get [ { id: 'GK.T.Max', value: 850 } ]
    set { ACTORA52: { aval: 85, err: 0 } }
    20.03 07:55:23.365 modbus1: READ: unitId = 1, FC = 3, address = 408 (0x198), length = 1
    20.03 07:55:23.371 IH: get [ { id: 'GK.T.Min', value: 200 } ]
    set { ACTORA53: { aval: 20, err: 0 } }
    20.03 07:55:23.571 modbus1: READ: unitId = 1, FC = 3, address = 430 (0x1ae), length = 1
    20.03 07:55:23.575 IH: get [ { id: 'GK.T.Pod', value: 274 } ]
    set { ACTORA55: { aval: 27.4, err: 0 } }
    20.03 07:55:23.777 modbus1: READ: unitId = 1, FC = 3, address = 431 (0x1af), length = 1
    20.03 07:55:23.782 IH: get [ { id: 'GK.T.Obr', value: 255 } ]
    


  • ПОдскажте, где взять старую версию плагина (до поддержки Modbus RTU).
    У меня в ней все работало без остановок. Я бы лучше на ней исправления ошибок подождал. Все чаще останавливается плагин.



  • @Erik Добрый день
    Версии плагина есть на github: https://github.com/intrahouseio/intraHouse.plugin-Modbus/releases
    v0.0.9 была без ModbusRTU совсем
    Далее добавлялся функционал ModbusRTU, но без переделки ModbusTCP
    v0.0.15 - значительные изменения кода, добавлен TRY RECONNECT



  • При долгой работе плагина modbus и одном отвалившемся устройстве остальные работают, но вот оперативная память заполняется. При чем за двое суток -500МБ памяти. Остановка-запуск плагина решают эту проблему, память освобождается. Как обойти проблему или организовать перезапуск плагина по расписанию? плагин v16


Авторизуйтесь, чтобы ответить