У меня Uniel UCH-M131RC/0808 подключен к WB5 (аппаратная версия 5.5). Стоит последняя прошивка (0.32-20170113), все пакеты обновлены - в т.ч. wb-mqtt-serial с последними патчами под Uniel. Uniel подключен к ttyAPP4, он один на шине. Настроено обычным образом - протокол Uniel, номер девайса 1, тип UCH-M141RC.
Когда параметры порта стоят обычные (9600, 8 bits, 2 stop bits) то на странице Devices я вижу виджет UCH-M141RC со всеми полями красными, и в лог валятся кучи ошибок двух типов:
wirenboard user.notice serial: TSerialDevice::ReadRegisterRange(): warning: Serial protocol error: timeout [slave_id is uniel:1] wirenboard user.notice serial: TSerialDevice::ReadRegisterRange(): warning: Serial protocol error: uniel: warning: checksum failure [slave_id is uniel:1]
но при этом когда я пишу в топик или двигаю в движки в виджете то все команды на устройство проходят. Т.е. чтение данных с устройства не работает, но запись на него работает нормально.
Когда параметры порта стоят такие: 9600, 8 bits, 1 stop bits (попробовал потому что вроде как для Uniel рекомендуется 1 стоп бит) то на странице Devices я вижу виджет UCH-M141RC со всеми нормальными (черными) полями, все изменения корректно отражаются в виджете, но при этом в обратном направлении проходит может быть одна из 10. Когда команда не проходит, то в логе появляется
wirenboard user.notice serial: TRegisterHandler::Flush(): warning: Serial protocol error: timeout for device uniel:1
Больше сообщений относящихся к Uniel в логах нет.
Прочитал всё что было на форуме про управление Uniel по RS-485, решений не нашел. Я понимаю что у Uniel кривой протокол и он не очень поддерживается WB - но на данный момент у меня он уже есть и хорошо бы заставить его работать. Что бы я мог посмотреть и попробовать?
Версия 1.24 из вашего репозитария, полученная при последнем обновлении.
Я пробовал брать wb-mqtt-serial с гитхаба, собирал сам (убедившись что там процедура получения ответа от uniel обновлена чтобы работать одинаково с одним и двумя 0xFF) и заливал на устройство - эффект тот же.
Да, именно так. Двигаю движок скажем на LED 0 - он немедленно откатывается назад как только отпускаю, заголовок “LED 0” краснеет, команда не уходит, в логах появляется
wirenboard user.notice serial: TRegisterHandler::Flush(): warning: Serial protocol error: timeout for device uniel:1
Иногда (один раз на 10-20 попыток) команда уходит и отрабатывается, в логах чисто.
То же самое когда я пробую отправить сообщение в топик из командной строки.
Пока искал проблему c 1wire- решил обновить софт в надежде, что это поможет (хоть и зарекался этого не делать больше), ну и как водится… появилась старая проблема с UNIEL, которая уже озвучена давно. Но какое-то время назад решение было найдено, хоть и не окончательное. Но так хоть более-менее работал, теперь же всплыли все те же проблемы
Итак, с обновлением стало опять все плохо, откатывал назад на старые версии wb-mqtt-serial (когда работало) - без результата. Я понимаю, что заниматься этим у разработчика нет большого желания, но хоть подскажите что еще надо откатить назад чтобы вернулась работоспособность. Меня это устроит, я не планирую что-либо развивать на WB5, лишь бы работало как раньше. Подозреваю, что у автора темы случилось ровно то же самое. И старый serial уже не помогает.
С Uniel у меня сейчас всё более-менее живет в режиме write-only, команды надёжно проходят на девайс, но при любых получениях данных идут постоянные ошибки обмена. Чтобы не переполнять логи ошибками и не убить флешку я поставил rsyslogd вместо дефолтного логгера и в конфигах запретил логгировать ошибки от Uniel. Стабильность меня сейчас устраивает.
Аа, ну, собственно добавил UCH-M131RC по инструкции (как 141-й), появились нужные топики. Лучше если он один на шину, параметры интерфейса 9600-N-8-2. Дальше если в скрипте что-то пишу в dev[“uchm141rc_1”][“LED N”] - то команда отправляется в устройство. Ну, не очень удобно что не видно состояний, но я не нашел другого варианта.
Попробовал установить 131, но что-то не увидел я его в темплейтах. Поставил 121 не думая и в результате получил неработающий 141. Ладно… я уже сталкивался с подобным год назад - настройки некоторых параметров (LowThr и HighThr) слетели, которыми я не пользуюсь, установив когда-то один раз и навсегда. Отмечу, что в свое время, пытаясь побороть проблемы, я сделал свой теплейт на это устройство путем вычищения всего ненужного - опроса входов и этих параметров. Чтобы меньше запросов было и как следствие - ошибок. Так и работало (разумеется, с патченным serial). Теперь же пришлось вернуть “комплектный” теплейт для восстановления работы. Вернул, восстановил и обнаружил странную вещь - работать стало заметно лучше, “покраснения” стали эпизодическими. Начал изучать “комплектный” темплейт и обнаружил отличие - появилась строчка в заголовке “guard_interval_us”: “3500”, которой раньше не было и как следствие - не было у меня. Что это такое и зачем - без понятия. Добавил в свой темплейт. В результате похоже поллинг стал работать как-то совсем иначе. В логах постоянных ошибок warning: Serial protocol error: timeout не стало совсем. Отображения состояния ламп работает идеально (просто включаю-выключаю кнопкой самого диммера и смотрю что на компе) - ошибок нет совсем (в логах тоже). Зато когда идет команда с компа на управление лампой - опять не всегда срабатывает (хотя и стало в разы лучше, чем было до этого, хотя и хуже, чем было до моего обновления софта). При этом как раз и появляются ошибки в логе warning: Serial protocol error: timeout То есть получается теперь ошибки работы с портом появляются исключительно при командах на изменение состояния уровня диммера. Уже большой плюс.
Продолжу дальше изучать, может что и получится.
И еще - все вышеуказанное было с wb-mqtt-serial версии 1.24. Установка последней 1.26.6 все портила и в логах начинали идти постоянные ошибки.
Попробовал 1.25 - тоже самое что и 1.24 - ошибок при опросе совсем нет, только при изменении уровня идут ошибки.
Конечно. И все это работало более-менее до обновления. Не идеально, но устраивало. Субъективно процентов 10 команд не проходило. Просто сделал в скриптах повторы с задержкой. После обновления все стало ужасно. Наверное уже 90 процентов команд не проходило.
Евгений, а что за параметр “guard_interval_us”: “3500” появился в темплейте на 141 uniel? Бегло поглядел другие темплейты, но нигде больше его не увидел. И абсолютно точно уверен, что раньше его не было. Как я выше писал - он оказывает существенное положительное влияние, хоть и не до конца.
// Минимальный интервал между опросом индивидуальных регистров
// данного устройства в микросекундах
“guard_interval_us”: 0,
Поигрался с величиной, получается она должна быть больше 2000, при 1500 уже начинают идти ошибки в логе при опросе состояний диммера. Когда жмешь кнопку на собственном входе диммера - все отлично работает, состояния моментально отображаются, ошибок нет. Но, повторяю, при записи в регистр (когда даются команды на изменение яркости) ошибки все равно остаются. Может можно как-то решить и этот вопрос?
