Плагин Modbus
-
Вошел в череду прерываний связи.
Оператор на даче с весной не справляется. видимо.
и ни разу сама связь сервера с контроллером не восстановилась.
Я, конечно, в перспективе увезу сервер на дачу, и проблема станет не актуальной.
Но если ее не решить, доверять серверу управлять географически распределенными объектами будет боязно.
Это важный момент. Решите его, пожалуйста.
-
Вошел в череду прерываний связи.
Оператор на даче с весной не справляется. видимо.
и ни разу сама связь сервера с контроллером не восстановилась.
Я, конечно, в перспективе увезу сервер на дачу, и проблема станет не актуальной.
Но если ее не решить, доверять серверу управлять географически распределенными объектами будет боязно.
Это важный момент. Решите его, пожалуйста.
Добрый день.
На гитхабе опубликован новый релиз плагина 0.0.7 https://github.com/intrahouseio/intraHouse.plugin-Modbus/releases/tag/v0.0.7
Изменения касаются только логики работы при потере связи.
Параметр плагина "Ожидание ответа на запрос (ms)" для нелокальных соединений желательно увеличить с 1 сек (1000 ms) до 5 и более сек.
-
Спасибо.
Установил.
-
Выдергивание патчкорда пережил нормально.
Осталось дождаться сбоя у оператора. Надеюсь, оператор не обманет в ожиданиях
-
Произошло.
Вижу разницу в поведении наглядно.
Видно, что плагин отключается, и включается, попытки повторяются, пока не прилетит хоть какой нибудь ответ, видимо.
После восстановления связи плагин это заметил, и перезапускаться перестал. Но работа не восстановилась. Ошибки дебагера видны - это ошибки связи.
В информации на микротике видно, что висит старое соединение, с таймаутом 23 часа, и второе новое, которое не может начать работать по каким то причинам.
Убивание старого соединения на микротике не помогло. Заработало в этот раз только после перезапуска контроллера.
Перед тем, как написать в поддержку контроллера, есть последний вопрос.
Этот таймаут соединению - 23 часа - не плагин ли устанавливает? Нет возможности уменьшить его до стандартных 10 минут?
-
Произошло.
Вижу разницу в поведении наглядно.
Видно, что плагин отключается, и включается, попытки повторяются, пока не прилетит хоть какой нибудь ответ, видимо.
После восстановления связи плагин это заметил, и перезапускаться перестал. Но работа не восстановилась. Ошибки дебагера видны - это ошибки связи.
В информации на микротике видно, что висит старое соединение, с таймаутом 23 часа, и второе новое, которое не может начать работать по каким то причинам.
Убивание старого соединения на микротике не помогло. Заработало в этот раз только после перезапуска контроллера.
Перед тем, как написать в поддержку контроллера, есть последний вопрос.
Этот таймаут соединению - 23 часа - не плагин ли устанавливает? Нет возможности уменьшить его до стандартных 10 минут?
Нет, конечно. Плагин не может так держать соединение, чтобы не давать контроллеру его сбросить.
Тем более он сам перезагружается, то есть закрывает со своей стороны.
Судя по логу - TCP соединение устанавливается, а вот по Modbus контроллер не отвечает.
Возможно, нужно радикально увеличить таймаут со стороны плагина, чтобы не дергать контроллер так часто.
В контроллерах обычно есть такой параметр - таймаут для Modbus соединения (и даже иногда его можно настроить, но это не обязательно, хотя бы знать).
-
В моем контроллере на виду его нигде нет.
Описал проблему на форуме поддержки контроллера. Посмотрю, что скажут.
Пока могу по факту значка "авария" на модбас-актуаторе и наличию пинга до контроллера принимать решения о его перезагрузке автоматически.
Но не могу пока смоделировать в каких еще ситуациях такие условия могут совпасть.
Контроллер то работает, климатом управляет, только отображение работы "отваливается".
Будет неправильно свалить его в череду перезагрузок.
-
В моем контроллере на виду его нигде нет.
Описал проблему на форуме поддержки контроллера. Посмотрю, что скажут.
Пока могу по факту значка "авария" на модбас-актуаторе и наличию пинга до контроллера принимать решения о его перезагрузке автоматически.
Но не могу пока смоделировать в каких еще ситуациях такие условия могут совпасть.
Контроллер то работает, климатом управляет, только отображение работы "отваливается".
Будет неправильно свалить его в череду перезагрузок.
Перезагрузка контроллера - это не решение. Нужно попытаться решить вопрос штатно.
Хорошо бы логировать трафик с помощью tcpdump (wireshark, etc.) и затем проанализировать.
-
микротиком собрал в packet sniffer начало взаимодействия (включение плагина). 2 раза.
https://yadi.sk/d/ZOGm_D1kwDq84g
https://yadi.sk/d/A7l6akA5DD9Tpg
смотрелка
192.168.88.46 - сервер IH
192.168.13.25 - контроллер
88.99.91.165 - облачный сервис, контроллер с ним по MQTT взаимодействует.
-
Видно, что время IH задает, а контроллер соглашается (первые пакеты на картинке).
-
Покажите, где IH задает время для контроллера
-
первый пакет.
Источник 192.168.88.46 - это IH.
задает TSVal = 602011810. В милисекундах это 167 часов.
А, наоборот.
Источник контроллер.
Извиняюсь.
-
Убивание старого соединения на микротике не помогло. Заработало в этот раз только после перезапуска контроллера.
Перед тем, как написать в поддержку контроллера, есть последний вопрос.
Этот таймаут соединению - 23 часа - не плагин ли устанавливает? Нет возможности уменьшить его до стандартных 10 минут?
Добрый день, данное время вы можете настроить самостоятельно нажав кнопку "Tracking"
Из документации микротика:Timeout - Time after connection will be removed from connection list. Этот параметр нужен микротику для трекинга.
-
@dev:
Добрый день, данное время вы можете настроить самостоятельно нажав кнопку "Tracking"
w.png
Из документации микротика:
Timeout - Time after connection will be removed from connection list. Этот параметр нужен микротику для трекинга.
Очень здорово.
Если это только микротик использует, значит оно и на ситуацию не влияет.
Потому, что убивание соединения на микротике к работоспособности не приводило.
Куда тогда копать?
Может сервер послать контроллеру перед попыткой установить соединения команду FIN от своего IP адреса для закрытия существующих соединений, если они есть?
-
первый пакет.
Источник 192.168.88.46 - это IH.
задает TSVal = 602011810. В милисекундах это 167 часов.
А, наоборот.
Источник контроллер.
Извиняюсь.
Да, приходит с обеих сторон. Но используется на транспортном уровне TCP
RFC 4433: TSVal - Поле Timestamp Value (TSval) содержит текущее значение временной метки передавшего опцию модуля TCP…..
Одной из важных причин использования временных меток является детектирование повторного использования порядковых номеров.
-
первый пакет.
Источник 192.168.88.46 - это IH.
задает TSVal = 602011810. В милисекундах это 167 часов.
А, наоборот.
Источник контроллер.
Извиняюсь.
Да, приходит с обеих сторон. Но используется на транспортном уровне TCP
RFC 4433: TSVal - Поле Timestamp Value (TSval) содержит текущее значение временной метки передавшего опцию модуля TCP…..
Одной из важных причин использования временных меток является детектирование повторного использования порядковых номеров.
Здесь лучше описано
https://www.freesoft.org/CIE/RFC/1323/9.htm
даже с автопереводом понятно
-
Куда тогда копать?
Можно попробовать использовать фиксированный порт на стороне плагина.
Если не поможет - переходить на mqtt, он у нас есть
-
там mqtt только для облачного сервиса.
Настроек в интерфейсе нет, т.е. переназначить на другой брокер без хакерства не получится.
Можно только отключить передачу, или включить.
С фиксированным портом должно помочь. Если таймштамп не помешает.
В идеале нужно запоминать время начала последнего таймштампа, чтобы при обрыве/восстановлении связи встроиться в него, или послать fin, если он не истек.
-
С фиксированным портом должно помочь. Если таймштамп не помешает.
В идеале нужно запоминать время начала последнего таймштампа, чтобы при обрыве/восстановлении связи встроиться в него, или послать fin, если он не истек.
У timestamp нет начала и нет конца.
timestamp - это всего лишь метка времени когда произошло событие (в рамках TCP - когда передан пакет, когда получен пакет …)
Она принципиально не может мешать кому либо
-
https://www.freesoft.org/CIE/RFC/1323/9.htm
Тут написано что оно изменяется пропорционально паузам.
Или что тогда не дает восстановить связь?
Если "Она принципиально не может мешать кому либо", значит причина в чем то другом.
Попробуйте начинать соединение с отправки fin. Вдруг есть хвост от старого. Если этому ничто мешать не может.
???
Можно попробовать использовать фиксированный порт на стороне плагина.
Как это сделать? Не нашел настройки порта на стороне плагина.
