Да, так и есть, эта функциональность не реализована.
В связи с общей ущербностью устройств и протокола Uniel, это сделать было технически сложно. А из-за низкого спроса на устройства, в планах этого нет.
Если вам это зачем-то нужно для дела, то можем реализовать за деньги на условиях платной техподдержки.
Блин жаль, выбрал этот димер основываясь на этом . Ну да ладно, работает же .
Евгений, помогите, случилось нехорошее.
Димер перестал работать из веб интерфейса, работает только из консоли через serial_tool. Я недавно прошил WB5 версией 0.25-20160708. К сожалению не могу сказать наверняка, сразу после прошивки он перестал работать или нет. Я делал с ним mqtt-delete-retained ‘/devices/uchm141rc_1/#’. Может с этим как-то связано?
Но после запуска wb-mqtt-serial ситуация таже, Uniel не управляется с контроллера.
Выполнил по вашей рекомендации ps aux | grep wb-mqtt-serial Ответ:
root 20407 0.0 1.9 3076 2372 ? S 06:09 0:00 /bin/bash -c exec /usr/bin/wb-mqtt-serial -c /etc/wb-mqtt-serial.conf 2>&1 | logger -t serial
root 20408 0.1 5.1 28436 6348 ? Sl 06:09 0:00 /usr/bin/wb-mqtt-serial -c /etc/wb-mqtt-serial.conf
root 20653 0.0 1.1 2036 1368 pts/0 S+ 06:20 0:00 grep wb-mqtt-serial
Мне мало что из этого понятно к сожжалению.
Заметил одну особенность: по modbus подключены WB5 -> MR11 -> Uniel, у модулей стоит галка Enable device в Serial Device Driver Configuration, MR11 не реагирует (зеленый светодиод не мигает). Убираю Enable device у Uniel и MR11 начинает работать (зеленый светодиод на нем мигает).
Ну собственно тут написано, что wb-mqtt-serial запущен.
А так это всё очень странно, хорошо бы включить отладку (галочка debug в настройках Serial Devices Configuration) и посмотреть вывод из /var/log/messages.
Какое количество стоп-битов у вас кстати стоит на порту?
Вообще наши девайсы и Uniel используют разный протокол, поэтому подключать их одновременно на один порт - это не совсем корректно: разработчики оборудования Uniel этого явно не предполагали. Наш драйвер такое поддерживает, но тем не менее это возможный источник проблем.
Другое дело, что у нас Uniel + наши железки на одном порту работали без проблем.
Вроде как для Uniel необходимо этот параметр ставить в 1. Но сие мало чего меняет. Если при 2 надписи всегда остаются красными, то при 1 они изредка частично становятся черными, что говорит о том, что соединение с контроллером все же становится лучше… Переключатели в web интерфейсе работают, но как-то заторможено - где-то секунда-две на отработку команды, такое ощущение, что просто происходит многократная попытка передачи команд на Uniel.
Еще заметил следующее - изначально диммер висел на одном порту со счетчиком на modbus, счетчик вообщем-то нормально работал. Потом перенес Uniel на второй порт контроллера (где других устройств не подключено) - на нем те же проблемы остались, а вот счетчик как-то заметно шустрее стал выдавать данные, циферки заметно чаще стали обновляться.
Тут явно какая-то засада с ядром. Ошибки на Serial идут по обоим портам, только чистый MODBUS это еще как-то проглатывает, а вот Uniel уже нет.
Как временное решение (жуткий костыль) перекомпилили wb-mqtt-serial, поменяв обработку ответа от диммера в uniel_device.cpp, что бы ответ с одним начальным 0xFF тоже принимался за валидный. Стала вполне приемлимая реакция на команды.
Добрый день, Евгений!
Железка WB5
Ядро: Linux wirenboard 4.1.15-imxv5-x0.1 #165 Fri May 27 17:21:40 MSK 2016 armv5tejl GNU/Linux
Прошивка: 201607081943
В логах постоянно сыпятся таймауты:
Aug 26 10:15:58 wirenboard user.notice serial: TSerialDevice::ReadRegisterRange(): warning: Serial protocol error: timeout [slave_id is 4(0x4)]
Aug 26 10:15:59 wirenboard user.notice serial: TSerialDevice::ReadRegisterRange(): warning: Serial protocol error: timeout [slave_id is 4(0x4)]
Aug 26 10:16:00 wirenboard user.notice serial: TSerialDevice::ReadRegisterRange(): warning: Serial protocol error: timeout [slave_id is 4(0x4)]
Aug 26 10:16:02 wirenboard user.notice serial: TSerialDevice::ReadRegisterRange(): warning: Serial protocol error: timeout [slave_id is 4(0x4)]
Aug 26 10:16:02 wirenboard user.notice serial: TSerialDevice::ReadRegisterRange(): warning: Serial protocol error: timeout [slave_id is 4(0x4)]
Aug 26 10:16:03 wirenboard user.notice serial: TModbusDevice::ReadRegisterRange(): failed to read 1 holding(s) @ 0 of slave modbus:12
Aug 26 10:16:04 wirenboard user.notice serial: TSerialDevice::ReadRegisterRange(): warning: Serial protocol error: timeout [slave_id is 4(0x4)]
Aug 26 10:16:05 wirenboard user.notice serial: TSerialDevice::ReadRegisterRange(): warning: Serial protocol error: timeout [slave_id is 4(0x4)]
Aug 26 10:16:06 wirenboard user.notice serial: TModbusDevice::ReadRegisterRange(): failed to read 1 holding(s) @ 2 of slave modbus:12
Aug 26 10:16:07 wirenboard user.notice serial: TSerialDevice::ReadRegisterRange(): warning: Serial protocol error: timeout [slave_id is 4(0x4)]
Aug 26 10:16:08 wirenboard user.notice serial: TSerialDevice::ReadRegisterRange(): warning: Serial protocol error: timeout [slave_id is 4(0x4)]
TSerialDevice - диммер Uniel UCH-M141rc
TModbusDevice - счетчик эл. энергии SDM120-Modbus RS485
Дебаг диммера через serial_tool показал, что правильный ответ от диммера приходит не часто. Почему-то проглатывается первый FF:
Очень похоже, что проблема с драйвером UART в ядре. Но у меня чего-то не получается ядро перекомпилировать, а ветка уже добралась до 4.1.30 и там есть какие-то патчи на UART.
Но я глубоко не лез в изучение патчей, их там много.
У меня есть идея в чём может быть дело, напишу более подробно сегодня или в понедельник. У вас будет возможность организовать удалённый доступ к этому WB для нас на время? К сожалению, SDM220 у нас нет, а если это то, о чём я думаю, то важно, какое именно оборудование на другой стороне .
Доступ можно закрывать, всё нужное посмотрели.
С modbus проблем нет, SDM220 отвечает всегда, второй девайс очень редко не отвечает, но симптомы совершенно другие - не приходит ответ вообще. Думаю, это проблемы девайса, такое часто бывает.
Проблему с Uniel воспроизвели у себя. Пока рабочая гипотеза в том, что Uniel слишком быстро отправляет ответ, поэтому начало ответного пакета передаётся ещё до того, как приёмопередатчик RS-485 на Wiren Board перейдёт в режим приёма. К сожалению, переключение направления передачи реализуется на нашем железе программно на уровне ядра, поэтому это происходит не мгновенно.
Из всех железок, с которыми мы работали, так ведёт себя только Uniel, которые, мягко говоря, не особо распространены и не особо полезны.
Что с этим всем делать не очень понятно. Старая реализация переключения направления в ядре работала лучше, но она использовала busy loop, т.е. могла блокировать работу системы на заметное время (сотни микросекунд), что вызывало разнообразные проблемы с другими подсистемами.
Наверное проще всего действительно обойти проблему на уровне парсинга ответа от Uniel в драйвере wb-mqtt-serial, как вы предложили.