tiene serie seriales serial recibir puertos puerto mega entre datos cuantos configurar comunicacion arduinos web-applications com serial-port activex

web-applications - serie - cuantos puertos seriales tiene el arduino uno



¿Cómo se puede leer una página web desde el puerto serie del usuario en el año 2017? (6)

Tengo que volver a implementar un sistema existente desde cero.

En un momento dado, cuando el usuario navega a una determinada página web, el servidor debe leer los datos del puerto serie del usuario.

Actualmente, la página web tiene un control ActiveX; cuando se carga la página, el control ActiveX llama a una DLL COM en la PC del usuario que lee los datos del puerto serie.

El sistema tiene 10 años. ¿Hay alguna forma "mejor" de que pueda implementar esto?

Por ejemplo, la tecnología ha avanzado en los últimos diez años. Y esta solución parece funcionar solo en MS IE, que ahora tiene una cuota de mercado de alrededor del 26% (tenía, en 2013, la última vez que actualicé esta pregunta. A partir de febrero de 2107, MS IE tiene 3-4% y Edge tiene 1-2%. Como Edge también es un producto MS, podría ser compatible con Active X (no lo he probado. Otoh, ya que es nuevo desde cero, es muy probable que no lo haga).

¿HTML 5 ofrece nuevas posibilidades? ¿Qué pasa con los productos como Cordova ?

existen algunas otras posibilidades?

¿Puedo agregar una Raspberry Pi para realizar la lectura a través del puerto serie y hacer que la aplicación del navegador se comunique con eso a través de un servicio RESTful?

[Actualización] @ EuroMicelli dijo "Voy a asumir que tienes una muy buena razón para ejecutar tu aplicación desde un navegador web, en lugar de una aplicación nativa". No sé como no estaba cuando se planeó el proyecto original (y la compañía que lo diseñó ya no existe).

¿Quizás no querían que el usuario final interactuara directamente con la base de datos? Tal vez "basado en el navegador" era una nueva palabra de moda en ese entonces? Yo, personalmente, no tengo ningún problema con una aplicación de escritorio (ya que me parece que es más fácil de implementar), pero ¿tal vez deberíamos considerar seguir basados ​​en el navegador? (Además, yo mismo puedo manejar la aplicación de escritorio; es solo la lectura basada en el navegador del puerto COM lo que me lleva a ofrecer una bonificación ;-)

El uso del paquete serialport a través de Node JS como servidor es una opción. Esto funciona en Windows, y aparentemente en Linux y OSX también. Consulte https://github.com/node-serialport/node-serialport .

Esta es una solución que he usado para leer comunicaciones de micro bits a través de USB a un navegador. Tuve que reconstruir el controlador para Windows (10) con:

  • npm install --global --production windows-build-tools
  • npm install serialport --build-from-source

He pegado parte de mi código a continuación para referencia:

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'') } }) }) */

Este enfoque funciona, para mí, pero puede llevar mucho tiempo hacer que funcione. No es, en mi opinión, una solución obvia o simple. Requiere una gran cantidad de conocimientos técnicos y es, me parece, mucho más complejo y ''complicado'' de lo que debería ser.

En particular, la reconstrucción de la biblioteca no es algo que esperaría hacer al usar Node JS. Uno de los efectos posibles es que necesitaría reconstruir los binarios del puerto serie para una plataforma diferente.

Para minimizar la biblioteca externa o los requisitos de los complementos en las máquinas cliente, escribiría un applet de Java .

Resumen (incluidos los enlaces a la mayoría de la documentación que necesitará para que esto ocurra) :

  1. Asegúrese de que sus clientes tengan Java instalado (la mayoría ya lo tiene y, si no, el navegador puede instalarlo) (esta es la única instalación que puede necesitar de algunos de sus clientes para este enfoque)
  2. Elija una biblioteca de puerto serie Java que no requiera ninguna instalación externa, como PureJavaComm
  3. Escriba un applet de Java muy simple que proporcione métodos públicos para leer el puerto serie
  4. Firme su applet para que se le otorguen los privilegios de acceso al sistema requeridos
  5. Incluya el applet en su página web y simplemente llame a los métodos públicos directamente desde JavaScript

Más detalles:

Según StatOwl , alrededor de dos tercios de todas las máquinas ya tienen instalados los marcos de trabajo Java necesarios, por lo que es posible que ni siquiera tenga que pedir a sus clientes que proporcionen infraestructura adicional. Y si lo hace, al menos está solicitando un software bien mantenido ( en su mayor parte ) que la gente conoce y sobre el que no será demasiado escéptico. Y, la mayoría de los navegadores deberían tener la capacidad de pedir a los usuarios que instalen el marco Java automáticamente si falta.

Hay varias bibliotecas diferentes que puede usar en Java para acceder al puerto serie. PureJavaComm parece ser uno de los pocos, sin embargo, que no requiere código externo para ejecutarse. Específicamente, en Windows, su clase de WinAPI Java le brinda acceso directo a los puertos COM, incluida toda su configuración, solo mediante llamadas a las bibliotecas de Windows ya instaladas. Ya que PureJavaComm es una biblioteca solo para Java, puede empaquetarlo con su applet en un archivo .jar, que el navegador descarga automáticamente, por lo que no hay nada que instalar.

Luego puede escribir un Applet de Java mínimo (probablemente solo de aproximadamente 50 a 100 líneas en total) que defina métodos públicos para hacer el acceso al puerto serie que necesita, a los que luego puede llamar fácilmente desde JavaScript directamente: Invocar métodos de applet desde código JavaScript

Lo único que debe asegurarse es que firma su applet y que ajusta su código de puerto serie en llamadas doPrivileged (...) para que se le otorgue el acceso al sistema requerido desde el JVM Sandbox. Para esto, puede obtener un certificado SSL comprado (que es posible que ya tenga si su servicio usa https) o generar el suyo propio. Si genera el suyo propio, se le preguntará a los usuarios si desean confiar en su applet, pero pueden elegir "confiar siempre", por lo que es solo una casilla de verificación de una sola vez y hacer clic en Aceptar. Pero más allá de eso, debe ser una solución completamente transparente que minimice el impacto en su experiencia de usuario.

Alternativa 1:

Otra opción sería, simplemente deshacerse de la interfaz web por completo y en su lugar, proporcionar un programa Java que los usuarios puedan ejecutar fácilmente (con o sin instalarlo) directamente desde su sitio web utilizando JNLP (Java Web Start) .

Alternativa 2 (solo Windows probable):

Supongo que también podría usar Microsoft Silverlight , que también parece bastante implementado :

Comunicación serial con Silverlight 5 (puerto COM)

Algunos podrían considerarlo más "moderno" que los applets de Java, pero probablemente sea menos multiplataforma.

También parece un poco más complicado llamar a tu código Silverlight desde JavaScript, pero es posible:

Hacer Silverlight con scripts de JavaScript

Probablemente no.

Voy a asumir que tiene una muy buena razón para ejecutar su aplicación desde un navegador web, en lugar de una aplicación nativa. Puedo pensar en un par de escenarios en los que puedo ver que es una decisión comercial justificable.

Incluso hoy en día, con todos los avances modernos, los navegadores web siguen siendo visores de documentos interactivos sofisticados, no entornos de tiempo de ejecución universales. Incluso las características más avanzadas como websockets se introdujeron para permitir comunicaciones sofisticadas entre el cliente y el servidor, y no debido a un interés universal para que algún día podamos hacer todo desde el navegador.

Puede haber algún entorno especializado donde sea posible de forma nativa (¿Chrome OS?), Pero no será una solución general. No hay un estándar existente o propuesto que conozca para abrir puertos serie a través de una etiqueta de navegador o secuencias de comandos. Eso significa que necesitará algún tipo de tecnología de plug-in de nivel bastante bajo como ActiveX. ActiveX es una solución realmente buena si está de acuerdo con el soporte de IE, especialmente si ya está escrito y funciona.

La mayoría de las personas que buscan acceso a un puerto serie desde un navegador probablemente están haciendo la adquisición de datos de algún hardware propietario que especifican (¿construyen / venden?) Y controlan, como equipos de laboratorio, escáneres de códigos de barras, instrumentos científicos, etc. Creo que en ese momento También es perfectamente aceptable especificar el navegador requerido también. Las aplicaciones especializadas comúnmente hacen eso.

Si aún desea ver un soporte de navegador más amplio, intente buscar la solución propuesta para esta pregunta: Comunicarse con Serial Port utilizando Adobe Flash . No tengo experiencia con este producto, pero si funciona, debería permitir que la mayoría de los navegadores hagan lo que usted quiere con un solo código, y eso es lo mejor que puede esperar.

Lo que sea que termine haciendo, sin duda implicará algún tipo de complemento de terceros.

Solo para nombrar otra opción (más como "web-of-things"): hardware externo.

Dependiendo del caso de uso, PODRÍA utilizar un dispositivo externo de bajo costo, como un microcontrolador arduino o una PC integrada con frambuesa-pi.

No es muy difícil construir un puente simple de servicio serie a web sobre este tipo de dispositivos. Puede usar algunos proyectos como este, por ejemplo: https://code.google.com/p/serwebproxy/

En tal caso, todo el contenido de bajo nivel lo maneja el hardware externo y se lo ofrece un servicio web como la interfaz (a través de get / post).

Otra ventaja es que la PC, en la que se ejecuta la aplicación, no necesita un puerto serie (que es bastante raro en algunos sistemas).

Desde la aplicación de su navegador, puede consultar el servicio web en el dispositivo integrado con una simple llamada ajax. El navegador no necesitaría ningún complemento, la solución funciona de forma cruzada y es genérica e independiente del desarrollo de tecnologías de navegador en un futuro cercano.

Una cosa es segura, nunca podrá comunicarse con el hardware de la máquina local sin instalar algunos binarios especiales (y ejecutarlo con los privilegios adecuados) en la máquina local. Sin embargo, eso no significa que tenga que usar un componente ActiveX y quedarse atascado con Internet Explorer. Por supuesto, también puede desarrollar un componente para cada navegador en el mercado.

Sugiero otro enfoque:

  • Escriba un servicio de Windows (supongo que su máquina ejecuta Windows), configúrelo con los privilegios necesarios. Tendrás que instalar algo en la máquina de todos modos. El servicio puede ser implementado en cualquier idioma.
  • Agregue capacidades de servidor HTTP (S) a él. Puede usar muchas tecnologías aquí desde WCF a WebAPI.
  • Inventa tu propio protocolo de comunicación a través de HTTP. Podría usar JSON, Ajax, WebSockets, SignalR, etc.
  • Escriba un archivo Javascript que sea compatible con la mayoría de los navegadores del mercado, de modo que solo tiene que escribirlo una vez, que se convertirá en su API COM serie. Puede admitir todos los navegadores con capacidades de Javascript y Ajax ( XmlHttpRequest ), con solo un código base.

Así es como se vería: