Комментарии 43
Попробуйте расширение написать для хром. API для работы есть. https://web.dev/serial/
Давно лет так двенадцать отправлял смс через usb модем. Ставил на комп denwer. и уже в нем через php отправлял команды в порт.
Ну а так зачем брать кота в мешке. Купить на али плату Wemos D1 и дисплей. Все быстро соединяется, пишется небольшая програмка и можно все через вай фай отправлять. Не каких проводов. По цене будет раза в два дешевле.
Тоже слышал от наших админов наших историю, что во времена до повсеместногo мобильного интернета, для экстренной отсылки sms сообщений сотрудникам в интранете был веб интерфейс связаный скриптом с нетленной Нокией, которая физически лежала в серверной.
А корпус? А если десяток таких штук надо сделать? Это же не для домашнего использования.
Мы решали подобну задачу через регистрацию своего URI в Windows (типа callto: или mailto:). Менеджер в Браузере нажимает на ссылку, система запускает программу на С++, которая принимает параметр из браузера и работает с COM портом соответствующтм образом.
Впринципе тоже нужно писать софт по Windows, но оно запускается каждый раз без необходимости слушать порт и висеть онлайн постоянно, что на Windows не всегда хорошо работает...
Могу в личку скинуть .reg файл для создания URI с параметром, если нужно.
Это если локально и под Windows и если под Windows у юзера есть права записи в реестр. А если требуется весь "зоопарк" браузеров\операционок, тут уж без "локального\удаленного" микро-сервиса никак. Более универсально, даже на C# можно почти под все ОС и так далее.
Про такую возможность не подумал... Спасибо за наводку
Мне вспомнилось, есть ведь еще e-ink дисплеи. Что было бы, возможно, практичнее, потому что нет привязки к программно-аппаратной части. Накроется эта фирма делающая такие дисплеи и привет, а если у тебя софт на ардуинке (или т.п.), то оно никуда не денется. А корпус, да его один раз смоделировать и на 3д принтере распечатать/заказать, да еще и забрендировать можно. И стоит e-ink дисплей от 20 долларов. Контраста для считывания должно хватать в типовых условиях освещения.
Мне приходит на ум WebUSB, только на Windows перед этим скорее всего надо установить Zadig Libusbk драйвер чтобы с устройством можно было работать напрямую (только для Windows).
Также можно подцепить к экрану Arduino c Bluetooth рисивером и управлять устройством в браузере с помощью WebBluetooth. Для этого драйверов ставить не нужно.
Тут говорят что можно писать через Serial API, но это делают через расширение для Chrome.
Занятно.
Автору дали последовательный порт, дали протокол к нему (не очень сложный).
И... автор недоволен, ругается, требует ещё какой-то "API или приложение для интеграции" и обзывает "полурабочим девайсом, вокруг которого нужны еще танцы с бубном чтобы он заработал".
Я ни разу не представитель производителя экрана, но... искренне не понимаю (мягко говоря) причину такой негативной реакции автора. Тем более, ему никто и не обещал сопряжения устройства с браузером. А устройтство, управляющееся через последовательный порт -- просто мечта, мне кажется. К нему не нужно какой-то специфический драйвер ставить, у которого свой программный интерфейс, который только со своей библиотекой работает, и т.д. и т.п.
Если уж так плохо, можно под специфическую задачу сопряжения устройства с браузером свою небольшую программку написать, которая открывает сокет на localhost, и транслирует данные из него в последовательный порт.
ну почти мечта... этот виртуальный компорт небось будет прыгать с номерами порта...
Пока ни разу не замечал, чтобы номер порта менялся спонтанно. Т.е. если одно и то же устройство подключать к одному и тому же порту USB, то номер порта стабильно один и тот же.
В принципе, если напрячься, можно сделать поиск устройства по VID/PID/SN, и находить соответствующий ему номер порта, но это уже перебор, на мой взгляд.
Смотря на чём писать. В питоновской библиотеке serial получение VID/PID есть "из коробки", постоянно так и делаю, не задумываясь о номерах портов вообще. Пример:
import serial
ports = serial.tools.list_ports.comports()
print(ports[0].vid, ports[0].pid)Хм, интересно. Я "автоматически" мыслю в категориях C++/Win32 API.
А что будет, если питоновская библиотека встретит честный железный последовательный порт? Какие VID/PID она покажет?
Тоже интересно стало, но ни на одном из имеющихся PC железных портов не нашлось. Но у объектов портов кроме числовых vid, pid есть атрибут hwid в виде строки более вольного формата (пример для USB порта: USB VID:PID=1915:C00A SER=E67672362BEB LOCATION=1-5:1.1), возможно там будет что-то осмысленное.
Или так:
from serial.tools.list_ports import comports
for comp in comports():
print(f'{comp = }')
print(comp)
print(f'{comp.vid = :04X}, {comp.pid = :04X}')
prt, desc, hwid = comp
print(f'{prt = }\n{desc = }\n{hwid = }')
print('comp.__dict__ = {')
for k, v in comp.__dict__.items():
print(f' {k}: {v},')
print('}')
Вы когда покупаете телефон или монитор проводите еще специальные действия для того чтобы начать с ним работать, пишите софт или может ищите решения для того чтобы устройство запустилось, привлекаете специалистов для этого...
К тому же это мое личное мнение, что продавая девайс надо либо предупреждать о режимах работы данного устройства либо предоставлять готовое к работе устройство "из коробки"
Ещё недавно, покупая сотовый телефон, нужно было думать, для работы в сетях какого стандарта (GSM или CDMA) и частотного диапазона (а это и сейчас актуально) он предназначен. А когда покупаю монитор, я смотрю, какие интерфейсы на нём есть, и сравниваю с тем, что есть на видеокарте моего ПК.
Фокус в том, что "готовое к работе устройство из коробки" в Вашем представлении -- одно, в представлении производителя экрана -- совсем другое. И мне кажется, производитель и помыслить не мог, что "выводить данные изнутри браузера" -- это вот прямо обязательная функция, без которой его устройство не может считаться полноценным.
О каких режимах стоило предупреждать? Подключаете к компу и спокойно с ним работаете, в чем проблема?
По-моему вы плохо смотрели про web api для com порта. Мы ещё до карантина написали интеграцию с кассовым аппаратом через COM из браузера напрямую. И там спокойно работал двухсторонний обмен через com порт.
Вот ведь как бывает. А я только вчера GSM модемный пул написал с REST API. Он правда под линукс, но зато на еpoll + FastAPI. В принципе если выкинуть модемную обертку, то получится асинхронный доступ к кучке USB - TTY устройств прямо из http клиента. Можно и под форточку переделать.
Тоже делали аналогичным образом, только у нас касса была подключена к ПК.
В той компании уже не работаю, но схема - работает.
Как из браузера отправлять команды в COM порт?
Так как мы в браузере и так работаем с JS, думаю несложно будет написать API на NodeJS, которое будет принимать HTTP запросы, и отправлять на COM порт.
npm i serialport
Помню игрался с МК и пользовался espruino. Там прошивка на МК летела прям с WebIDE (страничка браузера по сути), возможно там вы сможете найти ответ на свой вопрос)
@Struam собственно API так и называется WebSerial
https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_API
Тут такие темы уже обсуждались...я там писал свое решение(работаем через браузер со всем POS оборудованием через rs-232 причем в соновном в линуксе...Надо сделать прогу которая запускается на компе и прослушивает WebSocket и перекидывает пакеты в драйвер нативный для данной ОСИ(У нас драйвере на java поэтому нет разницы) ...Почему имеенно websoket? Потому что вы можете обратится из него к localhost
В бразузере в JS
var socket = new WebSocket("ws://localhost:7081");
socket.send(Ваши команды и ваш пакет);Прога шлюз прослушивает порт websoket 7081 и выполняет задачу.
Если ваша система загружена c url типа mycrm.com,то к localhost проблемно обычным REST обратится из-за CORS ,Same Origin Policy...а WebSocketом можно ходить на любой URL...
Всё... когда мы получили уже задачу и данные от браузера,то нативными решениями или по низкоуровневому протоколу rs-232 (я его предпочитаю ибо ИС кроссплатформенная) либо используюя решение производителя(обычно оно только под винду по технологии ActiveX объекта) выполняем задачу и по websoket "кричим" в браузер о стадии выполнения.
Это то,что будет работать(и работает)во всез браузерах во всех ОСях.
Странное впечатление от статьи. Я таки не понял, что хотел сказать автор. Он просит совета или рассказывает как написал интеграцию с COM портом, не приведя ни строчки кода?
https://wicg.github.io/serial/#writable-attribute
Давно уже есть спецификация на serial.
Не понимаю в чём проблема найти
Проще купить самый дешевый телефон. Выключить отключение экрана. Открыть фулскрином специальную страницу в браузере и слать в неё по вебсокетам нужное содержимое. Нажали в црм сгенерить код - отобразился код. Покупатель оплатил, процессинг прошел, отобразилась зелёная галочка)
Может быть можно как-нибудь "расшарить" девайс на USB порту в сеть и тогда слать в него команды с какого-нибудь сервера. Мы так билеты в киосках самообслуживания печатаем. Приложение в киоске работает в обычном браузере, а печать на принтер в киоске происходит с сервера в облаке. Правда у нас принтеры билетов с сетевым интерфейсом, а не с COM.
Есть ещё вариант, но древний, поэтому думаю, что вряд ли станете связываться.
Была аналогичная задача общаться из браузера по ком порту, но вместо описания протокола был код на Дельфи. Самым простым оказалось сделать обёртку в виде ActiveX и через него получать данные от устройства в js.
Как из браузера отправлять команды в COM порт?