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

ну подключил, теперь rfcomm на него и будет com порт

"популярное пояснение"

подключаем сканер через специальную программу, которая как я понимаю пробрасывает данные с подключенного к «свистку» по bluetooth сканера на созданный этой програмкой COM-порт и обратно, а 1С уже работает с данным COM-портом.

у тебя сложились неверные представления. com-порт «создает» ОС (точнее драйвер устройства; но эти детали тебе не нужны). программа работает с устройством через этот виртуальный com-порт. Как там и что делал в windows в связке программа <-> 1C не так важно сейчас для тебя.

В linux
После сопряжения сканера и адаптера bluetooth создаётся устройство /dev/rfcomm0 (это не точно). Посмотреть как именно называется sdptool browse <адрес твоего устройства> или сразу после сопряжения искать в выхлопе dmesg|tail

для использования сканера необходимо ПО под linux (его нет?) или описание системы команд/протокола для обмена через com-порт для написания такого ПО (ну или скриптов). Если такой документации нет (производитель/продавец же не предоставляет?), то возможно поискать в открытом ПО для сканеров (есть такое?)... На крайний случай wine (такое возможно?) или реверсинженеринг ПО из windows...

Как уже писали выше, с точки зрения linux сканер это COM-порт к которому подключено некое устройство. Все что нужно это читать данные из этого порта.

1С в linux может работать c этими данными только через внешнею компоненту(ВК) с типом Native.

В стандартных конфигурациях есть такая Драйвер1СУстройстваВводаNative. См там должны быть два SO, например: ScanOPOSNativeLin64_8_1_9_1.so ScanOPOSNativeLin32_8_1_9_1.so

Нашел такую конфигурацию БПО (библиотека подключаемого оборудования) буду через неё пробовать. Там есть такой драйвер оборудования как «1С:Сканеры штрихкода (NativeApi)», попробую его.

Вообщем настроил следующим образом

/etc/bluetooth/hcid.conf

options {
    autoinit yes;
    security auto
    pairing multi;
    passkey "0000";
}
device {
    name "%h-%d";
    class 0x4a010c;
    iscan enable; pscan enable;
    lm accept, master;
    lp rswitch,hold,sniff,park;
}

/etc/bluetooth/rfcomm.conf

rfcomm0 {
    bind yes;
    device 00:20:e0:7f:43:0a;
    channel 1;
    comment "SF51 Bluetooth device";
}

У меня появился файл /dev/rfcomm0.
Потом я удалил /dev/ttyS3 и сделал Линк с /dev/rfcomm0 на /dev/ttyS3

ln -s /dev/rfcomm0 /dev/ttyS3

Это поведение соответствует заявленному производителем? Режим энергосбережения или что-то похожее.

lp rswitch,hold,sniff,park;

мне тут подсказывают, что возможно нужно убрать park

мне тут подсказывают, что возможно нужно убрать park

Убрал, но ничего не изменилось, все так же отключается. Причем в Windows с той же конфигурацией 1С и сканером, такого не наблюдается. Какие еще настройки могут на это влиять?
И еще вопрос. Можно как то сделать чтобы сканер сам подключался на ttyS3? А то приходится каждый раз вручную делать симлинк с rfcomm0.
И rfcomm0 почему то появляется только после ручного

rfcomm bind rfcomm0

#!/bin/sh
rfcomm bind rfcomm0
rm /dev/ttyS3
ln -s /dev/rfcomm0 /dev/ttyS3

Есть преобразователи USB<>bluetooth последовательного порта. Они появляются как /dev/ttyUSBx. Возможно, как раз то, что надо. Около двух-трех баксов на али.

А чего, этот сканер клавиатурой не умеет работать?

мне тут подсказывают, что возможно нужно убрать park

Убрал, но ничего не изменилось, все так же отключается.

Вот по этому ману получается, что это никак не отключается — бред, наверное я не разобрался. Также sniff, как я понял, может быть причиной; но как это изменить непонятно. Есть идея добавить discovto 0 — хотя, это вроде бы «о другом»; я бы попробовал... На крайний случай придётся «костылять» некий сервис, который будет проверять наличие порта и если его нет подключать сканер автоматически — мне такое не нравится. Но если, через конфиг не получится, я не вижу других средств...

А действительно необходимо держать сканер постоянно соединённым с ПК?

Можно как то сделать чтобы сканер сам подключался на ttyS3? А то приходится каждый раз вручную делать симлинк с rfcomm0.

Да, через правила udev. Опять же я бы

• сначала посмотрел что происходит при спаривании сканера и ПК в dmesg
• посмотрел текущие правил для сканера в /etc/udev/rules.d/
• создал/модифицировал правило

И rfcomm0 почему то появляется только после ручного

про rfcomm0 я по памяти писал, возможно это и необязательно. Но мне это странно, может же быть несколько устройств с rfcomm и с разными настройками... Решается через правило udev

А чего, этот сканер клавиатурой не умеет работать?

Умеет, но как мне кажется это более медленный и менее надежный способ.

Есть преобразователи USB<>bluetooth последовательного порта. Они появляются как /dev/ttyUSBx. Возможно, как раз то, что надо. Около двух-трех баксов на али.

Т.е.поставить преобразователь с Али, а в него уже «свисток» пихать? Чего то фигня какая то получается, Будет ли вообще такая связка работать?

«Свисток» в данном случае не понадобится. Будет эмуляция последовательного порта на bluetooth

Почему это? Драйвер клавиатуры простой и оттестированный. Какие-то непонятные драйверы фиг пойми кем писанные - явно хуже. Я бы использовал как клавиатуру и не заморачивался.

«Свисток» в данном случае не понадобится. Будет эмуляция последовательного порта на bluetooth

Я может не понимаю чего, можно ссылку? Поискал и не могу понять о чем речь.

А как спаривание делать, вручную? При com порте происходит автоматически при обращении к нему (вроде бы).

Ищи HC-05 или HC-06 на Али. Пишу с планшета, поэтому ссылки дать не могу.

Вот по этому ману получается, что это никак не отключается — бред, наверное я не разобрался. Также sniff, как я понял, может быть причиной; но как это изменить непонятно. Есть идея добавить discovto 0 — хотя, это вроде бы «о другом»; я бы попробовал...

Добавил, но ничего не произошло. А может как то влиять постфикс приходящего со сканера? У меня после кода идет 'CR'+'LF' на win, а на Линуксе, почему-то, 'LF'+'LF'.

А действительно необходимо держать сканер постоянно соединённым с ПК?

Мне он не нужен постоянно подключенный, логика такая. Когда 1С лезет в COM порт происходит подключение самого сканера, а когда отключается то соединение рвется, по крайней мере в Windows было так. Тут же получается что устройства rfcomm0 не видно вообще пока не сделаешь

rfcomm bind rfcomm0
или
rfcomm connect 0

Решается через правило udev

Сейчас как раз ковыряю его. Пока сделал через скрипт при старте.

При помощи AT-команд модуль настраивается как мастер и подключается к заданной железке. Далее он просто проксирует поток между синезубом и виртуальным портом.

А, блин, да: к модулю понадобится usb-ttl, что-то я ступил!

Добавил, но ничего не произошло.

Это ожидаемый результат :(, но ведь проверить надо было...

меня после кода идет 'CR'+'LF' на win, а на Линуксе, почему-то, 'LF'+'LF'.

Думаю «да», это влияет. Про сканер не скажу, а модемы «вешаются» если не получают 'CR'+'LF'. Для модемов понимающих AT-команды (и windows-а) комбинация 'CR'+'LF' разделяет строки. В линуксе принято просто 'LF'. А где ты наблюдаешь эти коды?

ут же получается что устройства rfcomm0 не видно вообще пока не сделаешь

для USB-модемов (да и не только) создаются устройства /dev/ttyUSB<цифра> (или /dev/ttyACM<цифра>; есть ещё варианты). А вот для виртуального порта через Bluetooth разрабы отчего-то приняли просто rfcomm (мне вот непонятно). Если других виртуальных портов через Bluetooth у тебя не предвидится, то можешь не создавать rfcomm0 — сразу rfcomm привязывай к /dev/ttyS*

Хочется уточнить проблемы именно при работе через 1C?

если работать с этим портом через терминал (например CuteCOM) проблема есть?

Ничего уже не понимаю. :( После запуска minicom, он тут же крашится.. НО зато после этого сканер ведет себя так как нужно, на конце 'CR'+'LF' и не отваливается.
Не понимаю в чем проблема, возможно при старте minicom что то донастраивает, а вот что и где посмотреть пока непонятно. Ну не запускать же его при старте системы..

stty поможет проверить настройки порта.

Нет только, например если сделать

cat /dev/ttyS5

то тоже вылетает через 5 сек. По выводу видно что передается два 'LF'

[root@lserver]# cat /dev/ttyS5
92A23013D38

92A23013D38

а должно быть
[root@lserver]# cat /dev/ttyS5
92A23013D38
92A23013D38

stty поможет проверить настройки порта.

Я уже туплю наверное. Подскажите как посмотреть то? :(

Да, вот этот момент как-то ускользнул от внимания. Вероятно, просто привязать rfcomm* к ttyS* мало, нужна и «наладка»... Если не ошибаюсь, то параметры порта можно подсмотреть в inf-файле его виндового драйвера. В скрипт, который «дергается» правилом udev для rfcomm добавить команду настройки через stty.

Разобрался.
До запуска minicom

[root@lserver]# stty --file=/dev/ttyS5
speed 9600 baud; line = 0;
min = 1; time = 0;
-brkint -imaxbel
-icanon

[root@lserver]# stty --file=/dev/ttyS5
speed 9600 baud; line = 0;
min = 1; time = 5;
ignbrk -brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

В паре написано, я до ноутбука только вечером доберусь. После обхода и прогулки.

s:паре:мане:

Долбаная автозамена!!

Нашел какие два ключа были нужны

-icrnl -echo

Погуглив вроде это файл, rc.serial. Но у меня в CentOS нет такого, а его создание ни к чему не приводит.

Нашел какие два ключа были нужны

-icrnl -echo

после привязки rfcomm* к /dev/ttyS3 выполни

 stty -icrnl -echo </dev/ttyS3

stty -icrnl -echo </dev/ttyS3

Да так работает, но при этом происходит активация сканера и он пищит. А нельзя это как то без спаривания сделать? Ну типа правил udev.

я и подразумевал (после проверки) добавить эту команду в правило udev: настройка бы выполнялась при подключении сканера.

Чего то не выходит у меня. Я правильно понял, что правило типа такого?

KERNEL=="rfcomm0", SUBSYSTEM=="tty", ATTR{address}=="00:20:E0:7F:43:0A", ATTR{ch
annel}=="1", SYMLINK+="ttyS5", RUN+="/etc/bluetooth/stty_SF51.sh"

#!/bin/sh
stty -icrnl -echo -F /dev/ttyS5

Может в другое место надо запихать?

Но если сделать скрипт таким то все работает, правда выглядит как костыль.

#!/bin/sh
sleep 2
stty -icrnl -echo -F /dev/rfcomm0

KERNEL==«rfcomm0», SUBSYSTEM==«tty», ATTR{address}==«00:20:E0:7F:43:0A», ATTR{ch annel}==«1», SYMLINK+=«ttyS5», RUN+=«/etc/bluetooth/stty_SF51.sh»

да, примерно так оно и должно выглядеть. разве что, я бы добавил ACTION=="add"

KERNEL=="rfcomm0", SUBSYSTEM=="tty", ATTR{address}=="00:20:E0:7F:43:0A", ATTR{ch
annel}=="1",  ACTION=="add", SYMLINK+="ttyS5", RUN+="/etc/bluetooth/stty_SF51.sh"

Не срабатывает скорее всего потому, что на момент выполнения команды порт ещё не связан с симлинком — т.е. нет устройства /dev/ttyS5. Я уже обращал твоё внимание, что команда должна применяться после появления устройства в /dev/ttyS5. Или добавить ACTION=="add" в правило или модифицировать скрипт. Например, как ты поставить задержку или вот так как-то

#!/bin/sh
while [ "$RES" != "0" ]
do
  if [ "$ACTION" == "add" ]
  then RES=`stty -icrnl -echo -F /dev/ttyS5`
 fi
done

Причем если сканер находится в энергосберегающем режиме то вообще ничего не получается. И к тому же происходит активация сканера и он пищит. Может все таки можно как то более красиво сделать?

Всё дело в том, что американцы программы «тупые». Сканер и так скорее всего находиться в требуемом режиме, но stty делает ему принудительную настройку, причём при каждом его появлении в системе. Хотя нам этого как бы и не нужно. По умолчанию последовательный порт в линукс имеет установки отличающиеся от настроек в сканере (коряво сказал) — тебе бы только «принимающий» интерфейс настроить, а там мы настраиваем всю цепочку. Вот не знаю можно ли такое сделать. Точнее сказать: не знаю как это сделать.

P.S. Ты же взаимодействуешь со сканером через какие-то компоненты 1С? Там нет конфигов для настройки портов/устройств?

1с может читать с fifo? Сделай fifo, да отформатируй выхлоп туда. Что ему вообще надо? Может через xdotool накостылись можно.

Но если сделать скрипт таким то все работает, правда выглядит как костыль.

У меня был скрипт типа такого, он до сих пор там работает. Сканер штрихкодов штука тупая. Он просто передаёт код и endline в конце. Я его просто замыкал на xdotool и все были счастливы. Я из треда не понял кто кому что передаёт, опиши весь процесс еще раз.

#!/bin/sh
while [ "$RES" != "0" ]
do
  if [ "$ACTION" == "add" ]
  then RES=`stty -icrnl -echo -F /dev/ttyS5`
 fi
done

Не знаю что с этим кодом не так но у меня при старте сканер вошел в бесконечный цикл (включался-выключался) и система при попытке перегрузится наглухо висла, помогало только по питанию выключить.

Добавление ACTION==«add» ничего не меняет все равно нужен sleep 1

Сканер и так скорее всего находиться в требуемом режиме, но stty делает ему принудительную настройку, причём при каждом его появлении в системе.

Да вроде как достаточно только один раз сделать, а потом само работает.

P.S. Ты же взаимодействуешь со сканером через какие-то компоненты 1С? Там нет конфигов для настройки портов/устройств?

Да вроде нет стандартных, но буду что то колхозть тогда. :)

Я из треда не понял кто кому что передаёт, опиши весь процесс еще раз.

Если я правильно понял, то примерно так. Сканер bluetooth Подключается к USB-bluetooth, создается порт /dev/rfcomm0 на который создается линк /dev/ttyS5. А 1С, через драйвер NativeAPI подключается к COM6. Или не так?

Не знаю что с этим кодом не так но у меня при старте сканер вошел в бесконечный цикл (включался-выключался) и система при попытке перегрузится наглухо висла, помогало только по питанию выключить.

ну так аффтар «перла» как бы намекал

я не проверял работоспособность этого «кода»
«кода»

Сообщаю для тех кто может тоже захотеть попробовать. :)

kernel: usb 1-4: new full speed USB device number 23 using ohci_hcd
kernel: usb 1-4: device descriptor read/64, error -62
kernel: usb 1-4: device descriptor read/64, error -62
kernel: usb 1-4: new full speed USB device number 24 using ohci_hcd
kernel: usb 1-4: device descriptor read/64, error -62
kernel: usb 1-4: device descriptor read/64, error -62
kernel: usb 1-4: new full speed USB device number 25 using ohci_hcd
kernel: usb 1-4: device not accepting address 25, error -62
kernel: usb 1-4: new full speed USB device number 26 using ohci_hcd
kernel: usb 1-4: device not accepting address 26, error -62
kernel: hub 1-0:1.0: unable to enumerate USB device on port 4

Еще одна проблема нарисовалась. Если вытащить «свисток», а потом его снова поставить то подключиться к сканеру уже не получается, только перезагрузка. Что может быть за проблемма?

Опишу еще раз чего удалось достичь.
Сканер Intermec SF51, свисток BU-2050-J, система CentOS 6.10, 1C 8.3.11-3133.i386 (БиблиотекаПодключаемогоОборудования 2.1.1.22)

/etc/bluetooth/hcid.conf

# HCI daemon configuration file.
options {
    autoinit yes;
    security auto
    pairing multi;
    passkey "0000";
}
device {
    name "%h-%d";
    class 0x4a010c;
    iscan enable; pscan enable;
    lm accept, master;
    lp hold,sniff;
    discovto 0;
}

/etc/bluetooth/rfcomm.conf

# RFCOMM configuration file.
rfcomm0 {
    bind yes;
    device 00:20:e0:7f:43:0a;
    channel 1;
    comment "SF51 Scanner 0020e07f430a";
}

/etc/bluetooth/stty_SF51.sh

Этот файл нужен для передачи настроек в терминал для правильной передачи постфикса. Было 'LF'+'LF', а надо 'CR'+'LF'. Иначе сканер отключается при первом жа считывании.
Не знаю на всех так сканерах или нет, но у меня по другому не работало.

#!/bin/sh
sleep 1
stty -icrnl -echo -F /dev/rfcomm0

/etc/udev/rules.d/97-bluetooth-scaner-SF51.rules

Этот файл задает правило UDEV, чтобы при создании порта создавался и link на /dev/ttyS5 (COM6), т.к. 1С может видеть через NativeAPI только COM порты, а система создает rfcomm.

KERNEL=="rfcomm0", SUBSYSTEM=="tty", ATTR{address}=="00:20:E0:7F:43:0A", ATTR{channel}=="1", ACTION=="add", SYMLINK+="ttyS5", RUN+="/etc/bluetooth/stty_SF51.sh"

После всех этих манипуляций, просто выбираем в 1С COM6 и сканер подключается. Единственный момент в том что при старте системы сканер не должен быть в режиме энергосбережения, иначе не применятся настройки для порта и надо будет вручную (или из 1С) запустить скрипт

/etc/bluetooth/stty_SF51.sh

Это проблема «плохого контакта» обычно бывает с USB-устройствами подключаемыми с помощью кабеля. Переподключение обычно помогает. В поисковой выдаче встречаются сообщения о «программном» переподключении — не пробовал, не проверял.

Про скрипт: да, моя вина — неверное условие проверки, скрипт зацикливается...

За итоги/решение отдельное спасибо! Если можешь добавь в стартовое сообщение ссылку с описанием на то сообщение.

«Программно» переподключить несложно, у меня на гитхабе образец кода где-то был. Если надо, могу вечером поискать. А то с утра за ноутом сидеть - врач ругаться будет...

Выложи когда сможешь, думаю не только ТС будет полезно.