Как веб-страница может считываться из пользовательского последовательного порта - в 2017 году?

Мне нужно повторно внедрить существующую систему с нуля.

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

В настоящее время веб-страница имеет элемент управления ActiveX; при загрузке страницы элемент управления ActiveX вызывает COM-DLL на ПК пользователя, который считывает данные из последовательного порта.

Системе 10 лет. Есть ли "лучший" способ, которым я мог бы это реализовать?

Например, технология продвигается в течение последних десяти лет. И это решение, похоже, работает только в MS IE, у которого сейчас доля рынка составляет около 26% (в 2013 году, когда я последний раз обновлял этот вопрос. В феврале 2107 MS IE имеет 3-4%, а Edge имеет 1-2%. Поскольку Edge также является продуктом MS, он может поддерживать Active X - я еще не пробовал. Otoh, поскольку он новичок с нуля, есть хороший шанс, что он нет).

Есть ли у HTML 5 новые возможности? Как насчет таких продуктов, как Cordova?

Есть ли другие возможности?

Могу ли я добавить Raspberry Pi для чтения через последовательный порт и связать с ним приложение браузера с сервисом RESTful?


[Update] @EuroMicelli сказал: "Я собираюсь предположить, что у вас есть все основания для запуска вашего приложения из веб-браузера, а не из собственного приложения". Я не знаю, как меня окружало, когда был запланирован первоначальный проект (и компания, которая его спроектировала, теперь не функционирует).

Возможно, они не хотели, чтобы конечный пользователь напрямую взаимодействовал с базой данных? Может быть, "основанный на браузере" был тогда новым словом? У меня лично нет проблем с настольным приложением (поскольку я нахожу их более легкими в реализации), но, возможно, нам стоит подумать о том, чтобы оставаться на другом браузере? (кроме того, я могу справиться с настольным приложением самостоятельно, это только чтение на основе браузера из COM-порта, которое заставляет меня предлагать бонус; -)

Ответы

Ответ 1

Просто, чтобы назвать другой (более похожий на "веб-вещи" ) вариант: внешнее оборудование.

В зависимости от используемого варианта вы МОЖЕТЕ использовать внешнее недорогое устройство, такое как микроконтроллер arduino или встроенный ПК с малиной-пи.

Не очень сложно построить простой сериализованный мост веб-сервиса на таких устройствах. Вы можете использовать некоторые проекты, подобные этому, например.: https://code.google.com/p/serwebproxy/

В таком сценарии все материалы низкого уровня обрабатываются внешним оборудованием и предлагаются вам с помощью веб-сервиса, такого как интерфейс (через get/post).

Дополнительным преимуществом является то, что на ПК, где выполняется приложение, не требуется последовательный порт (который становится довольно редкими в некоторых системах).

В своем приложении-браузере вы можете запросить веб-сервис на встроенном устройстве с помощью простого вызова ajax. В браузере вообще не потребуется никакого плагина, решение работает с перекрестными формами и в ближайшем будущем является общим и независимым от разработки браузеров.

Ответ 2

Конечно, вы никогда не сможете общаться с местным аппаратным оборудованием, не устанавливая некоторые специальные двоичные файлы (и запуская их с соответствующими правами) на локальном компьютере. Однако это не означает, что вам необходимо использовать компонент ActiveX и оставаться в обозревателе Internet Explorer. Конечно, вы могли бы также разработать компонент для каждого браузера на рынке.

Я предлагаю другой подход:

  • Напишите службу Windows (я предполагаю, что ваш компьютер работает под управлением Windows), настройте ее с необходимыми привилегиями. В любом случае вам придется что-то устанавливать на машине. Услуга может быть реализована на любом языке.
  • Добавьте к нему возможности сервера HTTP (S). Вы можете использовать множество технологий здесь из WCF в WebAPI.
  • Создайте свой собственный протокол связи через HTTP. Вы можете использовать JSON, Ajax, WebSockets, SignalR и т.д.
  • Напишите файл Javascript, который будет совместим с большинством браузеров на рынке, поэтому вам нужно только написать это один раз - это станет вашим Serial COM API. Вы можете поддерживать все браузеры с возможностями Javascript и Ajax (XmlHttpRequest), только с одной базой кода.

Вот как это будет выглядеть: enter image description here

Ответ 3

Чтобы свести к минимуму требования к внешней библиотеке или плагину на клиентских компьютерах, я бы написал Java Applet.

Резюме (включая ссылки на большую часть документации, которая вам понадобится для ее выполнения) :

Подробнее:

Согласно StatOwl, около двух третей всех машин уже установлены необходимые фреймворки Java, поэтому вам может и не понадобиться попросить ваших клиентов предоставить дополнительную инфраструктуру. И если вы это сделаете, по крайней мере, вы просите (по большей части) хорошо сохранившееся программное обеспечение, которое люди знают и выигрывают ' Слишком скептически относитесь. И, большинство браузеров должны иметь возможность предлагать вашим пользователям возможность автоматически устанавливать инфраструктуру Java, если она отсутствует.

Существует несколько различных библиотек, которые вы можете использовать в Java для доступа к последовательному порту. PureJavaComm, по-видимому, является одним из немногих, которые не требуют внешнего кода для запуска. В частности, в Windows их WinAPI класс Java дает вам прямой доступ к COM-портам, включая все их настройки, просто используя вызовы уже установленной Windows библиотеки. Поскольку PureJavaComm является библиотекой только для Java, вы можете упаковать ее с помощью своего апплета в один .jar файл, который автоматически загружается браузером, поэтому устанавливать нечего.

Затем вы можете написать минимальный Java-апплет (возможно, всего около 50-100 строк), который определяет общедоступные методы для доступа к последовательному порту, который вам нужен, который вы можете легко вызвать из JavaScript напрямую: Вызов методов апплета из кода JavaScript

Единственное, что вам нужно убедиться, это то, что вы подпишите свой апплет и завершите свой код последовательного порта doPrivileged (...), чтобы ему был предоставлен необходимый системный доступ из JVM Sandbox. Для этого вы можете либо приобрести приобретенный SSL-сертификат (который у вас может уже иметь, если ваша служба использует https), либо создать собственный. Если вы создадите свой собственный, пользователям будет предложено указать, хотят ли они доверять вашему аплету, но они могут выбрать "всегда доверять", и поэтому это просто одноразовый флажок и "ОК". Но помимо этого, это должно быть полностью прозрачное решение, которое минимизирует влияние на ваш пользовательский опыт.

Альтернатива 1:

Другим вариантом было бы просто полностью отключить веб-интерфейс и вместо этого предоставить программу Java, которую пользователи могут легко запускать (с или без ее установки) непосредственно с вашего сайта, используя JNLP (Java Web Start).

Альтернатива 2 (возможно, только для Windows):

Я думаю, вы могли бы также использовать Microsoft Silverlight, который также кажется довольно широко развернуто:

Последовательная связь с Silverlight 5 (COM-порт)

Некоторые могут считать это более "современным", чем Java-апплеты, но, вероятно, он менее кросс-платформенный.

Также кажется, что вам больше нравится называть код Silverlight кодом JavaScript, но это возможно:

Создание Silverlight Scriptable с помощью JavaScript

Ответ 4

Возможно, нет.

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

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

Может быть какая-то специализированная среда, где это возможно (это Chrome OS?), но это не будет общее решение. Не существует существующего или предлагаемого стандарта, который я знаю, чтобы открывать последовательные порты через тег браузера или скрипты. Это означает, что вам понадобится какая-то довольно низкоуровневая подключаемая технология, например ActiveX. ActiveX - это действительно хорошее решение, если вы поддерживаете поддержку только IE, особенно если он уже написан и работает.

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

Если вы все еще хотите посмотреть более широкую поддержку браузера, попробуйте найти предлагаемое решение для этого вопроса: Общение с последовательным портом с помощью Adobe Flash. У меня нет опыта работы с этим продуктом, но если он работает, он должен позволить большинству браузеров делать то, что вы хотите делать с одной кодовой базой, и это так хорошо, как вы можете надеяться.

Независимо от того, что вы делаете, он, безусловно, будет включать в себя сторонний плагин.

Ответ 5

Вы можете использовать Web USB - но совместимость браузера (в настоящее время) очень низкая - Chrome 61, похоже, об этом.

Основное преимущество этого подхода заключается в том, что устройство USB подключено к браузеру. Поэтому очень маловероятно работать с мобильным телефоном.

API находится в https://wicg.github.io/webusb/.

Для учебника см. https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web.

Ответ 6

Использование пакета serialport через Node JS как сервер является опцией. Это работает на Windows, и, видимо, на Linux и OSX. См. https://github.com/node-serialport/node-serialport.

Это решение, которое я использовал для чтения микробитовых сообщений через USB в браузере. Мне пришлось перестроить драйвер для окон (10) с помощью:

  • npm install --global --production windows-build-tools
  • npm установить serialport --build-from-source

Я добавил следующий код для ссылки ниже:

const serialport = require('serialport')

// list serial ports:
const find_microbit = (error, success) => {
  serialport.list((err, ports) => {
    if (err) {
      error(err)
    } else {
      let comName = null
      ports.forEach((port) => {
        if ((port.vendorId == '0D28') && (port.productId == '0204')) {
          comName = port.comName
        }
      })
      if (comName != null) {
        success(comName)
      } else {
        error('Could not find micro:bit.')
      }
    }
  })
}

exports.get_serial = (error, success) => {
  find_microbit(error, (comName) => {
    let serial = new serialport(comName, {baudRate: 115200, parser: serialport.parsers.readline('\n')}, (err) => {
      if (err) {
        error(err)
      } else {
        success(serial)
      }
    })
  })
}
/* e.g.
get_serial((err)=>{console.log("Error:" + err)},
    (serial)=>{
        serial.on('data', (data) => {
            let ubit = JSON.parse(data)
            if (ubit.button == 'a') {
                console.log('Button A Pressed')
            }
            if (ubit.button == 'b') {
                console.log('Button B Pressed')
            }
            if (ubit.ir) {
                console.log('Visitor detected')
            }
        })
    })
    */

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

В частности - перестройка библиотеки не является чем-то, что я ожидал бы сделать при использовании Node JS. Одним из возможных эффектов является то, что вам потребуется перестроить двоичные файлы последовательного порта для другой платформы.