Настройка uch-m141rc

EvgenyBoger · July 16, 2016, 2:59pm

Да, так и есть, эта функциональность не реализована.
В связи с общей ущербностью устройств и протокола Uniel, это сделать было технически сложно. А из-за низкого спроса на устройства, в планах этого нет.

Если вам это зачем-то нужно для дела, то можем реализовать за деньги на условиях платной техподдержки.

slex · July 25, 2016, 4:29pm

Блин жаль, выбрал этот димер основываясь на этом . Ну да ладно, работает же .
Евгений, помогите, случилось нехорошее.
Димер перестал работать из веб интерфейса, работает только из консоли через serial_tool. Я недавно прошил WB5 версией 0.25-20160708. К сожалению не могу сказать наверняка, сразу после прошивки он перестал работать или нет. Я делал с ним mqtt-delete-retained ‘/devices/uchm141rc_1/#’. Может с этим как-то связано?

EvgenyBoger · July 25, 2016, 4:45pm

Добрый день!
Проверьте в веб-интерфейсе в Configs => Serial Devices Configuration, что всё правильно заполнено: порт, модель и адрес.

Потом покажите пожалуйста /etc/wb-mqtt-serial.conf и вывод

ps aux | grep serial

и

cat /var/log/messages | grep serial

можно на почту support@.

slex · July 26, 2016, 1:30pm

Ответил на почту

EvgenyBoger · July 26, 2016, 3:51pm

Судя по логам у вас не запущен wb-mqtt-serial по каким-то причинам. Вы его сами не останавливали случайно?

Попробуйте запустить вручную:

service wb-mqtt-serial start

потом проверить, что он запущен:

ps aux  | grep wb-mqtt-serial

slex · July 29, 2016, 11:55am

Извиняюсь, я забыл запустить wb-mqtt-serial после поисков решения проблемы по теме Wb-mr11 глючит при подключении с wb-mcm16.

Но после запуска 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 начинает работать (зеленый светодиод на нем мигает).

EvgenyBoger · July 30, 2016, 4:17pm

Ну собственно тут написано, что wb-mqtt-serial запущен.

А так это всё очень странно, хорошо бы включить отладку (галочка debug в настройках Serial Devices Configuration) и посмотреть вывод из /var/log/messages.

Какое количество стоп-битов у вас кстати стоит на порту?

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

slex · August 1, 2016, 6:24am

Отладку включил, потом пощелкал выключателями в веб интерфейсе. Скинул файлы вам на почту.

В Serial Device Driver Configuration стоит Stop bits = 2.

До прошивки и у меня Uniel работал со всем остальным оборудованием.

adav · August 1, 2016, 7:52am

Ровно та же проблема.

Вроде как для Uniel необходимо этот параметр ставить в 1. Но сие мало чего меняет. Если при 2 надписи всегда остаются красными, то при 1 они изредка частично становятся черными, что говорит о том, что соединение с контроллером все же становится лучше… Переключатели в web интерфейсе работают, но как-то заторможено - где-то секунда-две на отработку команды, такое ощущение, что просто происходит многократная попытка передачи команд на Uniel.

Еще заметил следующее - изначально диммер висел на одном порту со счетчиком на modbus, счетчик вообщем-то нормально работал. Потом перенес Uniel на второй порт контроллера (где других устройств не подключено) - на нем те же проблемы остались, а вот счетчик как-то заметно шустрее стал выдавать данные, циферки заметно чаще стали обновляться.

Reroute · August 26, 2016, 7:39am

Тут явно какая-то засада с ядром. Ошибки на Serial идут по обоим портам, только чистый MODBUS это еще как-то проглатывает, а вот Uniel уже нет.
Как временное решение (жуткий костыль) перекомпилили wb-mqtt-serial, поменяв обработку ответа от диммера в uniel_device.cpp, что бы ответ с одним начальным 0xFF тоже принимался за валидный. Стала вполне приемлимая реакция на команды.

void TUnielDevice::ReadResponse(uint8_t cmd, uint8_t* response)
{
uint8_t buf[5];
for ( ;; ) {
if (Port()->ReadByte() != 0xff) {
std::cerr << “uniel: warning: resync” << std::endl;
continue;
}
buf[0] = Port()->ReadByte();
if(buf[0] == 0xff) { buf[0] = Port()->ReadByte(); }

    uint8_t s = buf[0];

    for (int i = 1; i < 5; ++i) {
        buf[i] = Port()->ReadByte();
        s += buf[i];
    }

    if (Port()->ReadByte() != s)
        throw TSerialDeviceTransientErrorException("uniel: warning: checksum failure");

    break;
}

if (buf[0] != cmd)
    throw TSerialDeviceTransientErrorException("bad command code in response");

if (buf[1] != 0)
    throw TSerialDeviceTransientErrorException("bad module address in response");

for (int i = 2; i < 5; ++i)
    *response++ = buf[i];

}

EvgenyBoger · August 26, 2016, 8:34am

Добрый день,

вы имеете в виду, что у вас контроллер теряет первый байт приходящего пакета?
Можете выложить логи с модбасом?

Какое у вас железо и версия ядра?

Reroute · August 26, 2016, 10:28am

Добрый день, Евгений!
Железка 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:

.>> FF FF 05 04 00 03 00 0C
.<< FF FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF FF 05 00 FF 03 00 07
.>> FF FF 05 04 00 03 00 0C
.<< FF 05 00 FF 03 00 07

Правильный ответ выделен.

Очень похоже, что проблема с драйвером UART в ядре. Но у меня чего-то не получается ядро перекомпилировать, а ветка уже добралась до 4.1.30 и там есть какие-то патчи на UART.
Но я глубоко не лез в изучение патчей, их там много.

EvgenyBoger · August 26, 2016, 11:28am

Ядро у нас своё, там много изменений, в т.ч. с UART-ом: https://github.com/contactless/linux

У меня есть идея в чём может быть дело, напишу более подробно сегодня или в понедельник. У вас будет возможность организовать удалённый доступ к этому WB для нас на время? К сожалению, SDM220 у нас нет, а если это то, о чём я думаю, то важно, какое именно оборудование на другой стороне .

EvgenyBoger · August 26, 2016, 11:42am

Скорее всего проблема в медленном RTS, патч вот этот https://github.com/contactless/linux/commit/eb4b32355ba63d9ff077552aa2822f2d2d079a5d .

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

Reroute · August 26, 2016, 12:24pm

Дайте e-mail скинуть параметры доступа к контроллеру.

EvgenyBoger · August 26, 2016, 2:00pm

support@contactless.ru

Reroute · August 26, 2016, 2:28pm

Отправил

Reroute · August 31, 2016, 5:46am

День добрый, Евгений!
Удалось что-нибудь выяснить?

EvgenyBoger · August 31, 2016, 9:22am

Доступ можно закрывать, всё нужное посмотрели.
С modbus проблем нет, SDM220 отвечает всегда, второй девайс очень редко не отвечает, но симптомы совершенно другие - не приходит ответ вообще. Думаю, это проблемы девайса, такое часто бывает.

Проблему с Uniel воспроизвели у себя. Пока рабочая гипотеза в том, что Uniel слишком быстро отправляет ответ, поэтому начало ответного пакета передаётся ещё до того, как приёмопередатчик RS-485 на Wiren Board перейдёт в режим приёма. К сожалению, переключение направления передачи реализуется на нашем железе программно на уровне ядра, поэтому это происходит не мгновенно.

Из всех железок, с которыми мы работали, так ведёт себя только Uniel, которые, мягко говоря, не особо распространены и не особо полезны.

Что с этим всем делать не очень понятно. Старая реализация переключения направления в ядре работала лучше, но она использовала busy loop, т.е. могла блокировать работу системы на заметное время (сотни микросекунд), что вызывало разнообразные проблемы с другими подсистемами.

Наверное проще всего действительно обойти проблему на уровне парсинга ответа от Uniel в драйвере wb-mqtt-serial, как вы предложили.

Reroute · August 31, 2016, 10:15am

Понятно.
Добавите патч в wb-mqtt-serial для последующих релизов?

Спасибо!