HTTP

Referencia del controlador HTTP: sondear puntos de conexión HTTP y HTTPS como tags, credenciales, correspondencia de rutas, análisis del cuerpo, escrituras PUT y tipos.

Ver como Markdown

El controlador HTTP sondea puntos de conexión HTTP genéricos como tags: un sensor de la red local con un servidor web diminuto, una pasarela que publica lecturas en URL fijas, un servicio propio. Es el controlador en modo cliente más sencillo del producto: Ganter Lab se conecta al equipo con peticiones GET sin cifrar y lee el cuerpo de cada respuesta como un valor.

Dos propiedades trazan la línea de para qué sirve:

El transporte es el que nombra la dirección. Un dispositivo cuyo host está escrito https://host alcanza su servicio sobre TLS; un host escrito a solas es HTTP sin cifrar. De una manera u otra, el controlador envía la credencial del dispositivo en cada petición, un nombre de usuario y una contraseña como HTTP Basic o un token de portador. Lo que los controladores AVEVA PI y Redfish siguen aportando para esos dos servicios es su vocabulario: rutas PI y WebId, árboles de recursos de Redfish, de los que este controlador no sabe nada.
El cuerpo entero de la respuesta es el valor. El controlador no es un extractor de campos JSON: un tag numérico espera que el cuerpo sea el número pelado.

Campos de conexión

Campo	Qué es	Formato	Por defecto
Host o IP	El nombre de host o la dirección IP del punto de conexión. Escrito `https://host` se alcanza sobre TLS, que es lo que mantiene una credencial fuera del cable; un host a solas es HTTP sin cifrar.	Nombre de host, IP, o cualquiera de los dos con `http://` o `https://` delante	vacío
Puerto	El puerto TCP. Cero significa el puerto en el que responde el transporte: el 80 sin cifrar, el 443 sobre HTTPS.	número de puerto	0
Ruta del recurso	Un prefijo de ruta opcional que se antepone a la ruta de todos los tags, por ejemplo `api/v2`. En blanco no antepone nada.	texto de ruta	en blanco
Nombre de usuario	La cuenta para la autenticación HTTP Basic, usada solo cuando no hay ningún token de portador puesto. Vacío (y sin token) deja las peticiones anónimas.	Texto libre	vacío
Contraseña	La contraseña que acompaña al nombre de usuario. Protegida en reposo por usuario de Windows; un secreto escrito con otra cuenta de Windows aparece como ilegible y hay que volver a escribirlo.	Texto libre	vacío
Token de portador	Un token enviado como `Authorization: Bearer …` en cada petición. Cuando está puesto, gana sobre la pareja de nombre de usuario y contraseña. Protegido en reposo de la misma manera.	Texto del token	vacío

Al conectar, el controlador verifica el punto de conexión con una petición HEAD a la dirección configurada, host más ruta del recurso, y recae en GET cuando HEAD no está implementado; una dirección que responde bien a cualquiera de las dos cuenta como alcanzable. Un servicio cuya raíz responde 404 mientras su API responde con normalidad está, por tanto, en línea, siempre que la ruta del recurso apunte a la API. Sobre HTTPS, el certificado TLS del servicio tiene que pasar la validación de certificados normal de Windows. Una credencial en una dirección que no nombra ningún TLS viaja sin cifrar, y la estación lo dice en el diario del conector cuando el dispositivo se conecta. A cada petición se le dan diez segundos: un punto de conexión que acepta la conexión y luego no dice nada cuesta una lectura, no el dispositivo entero, porque los demás tags del dispositivo se leen en la misma pasada. El intervalo de sondeo es configurable: el valor por defecto del dispositivo (1000 ms) se aplica a todo tag que no declare el suyo.

Direccionamiento del tag

El campo Ruta del tag es la ruta de la URL relativa a la ruta del recurso del dispositivo:

Campo	Qué hace	Valores	Por defecto
Ruta	La ruta que se pide para este tag. La URL completa es `<transport>://<host>:<port>/<resource path>/<path>`.	Texto libre (obligatorio)	vacío

Ejemplo: con el host 192.168.0.40, la ruta del recurso api y la ruta de tag sensors/temp se sondea http://192.168.0.40/api/sensors/temp.

Lecturas

Cada sondeo hace un GET a la URL del tag y analiza el cuerpo entero de la respuesta según el tipo de dato declarado del tag:

Tipo	Cuerpo aceptado
Float	Un número en formato invariable (`21.5`, con punto decimal y sin separadores de millares)
Int32	Un entero (`42`)
Boolean	`true` o `false`
String	Cualquier cosa; el cuerpo es el valor tal cual (un documento JSON llega como su texto en bruto)

Un cuerpo que el tipo declarado no puede analizar, o un código de estado que no es de éxito, se lee como una lectura fallida: el tag pasa a mala calidad y su política de fallo de lectura decide qué se presenta, tal como se describe en la página Connector.

Escrituras

Los tags con un modo de acceso que permite escribir escriben con PUT a la misma URL: el cuerpo es el valor en JSON, enviado con el tipo de contenido application/json. Un número va como literal pelado (42.5), un booleano como true o false, y el texto va entrecomillado ("automatic"). El punto de conexión decide qué hacer con él; un estado que no es de éxito se lee como una escritura fallida. Como en todas partes, la casilla de escritura toma el valor de ingeniería y las etapas de conversión del tag se deshacen antes de que el valor bruto salga al bus, tal como se describe en la página Connector.

Tipos de dato admitidos

Boolean, Int32, Float y String.

Comandos

Un tag lee un valor; un comando pide al servicio que haga algo. Cada uno se declara en el dispositivo, en la tarjeta Comandos de su página: un nombre, la ruta a la que se envía por POST (bajo la dirección propia del dispositivo, exactamente igual que la ruta de un tag) y, si procede, el nombre del único valor que toma. El verbo Ejecutar de la fila lo envía e informa de lo que contestó el servicio, y el comando pasa a ser además un método sobre el dispositivo en el espacio de direcciones OPC UA propio de esta estación, así que cualquiera que pueda llamar a un método lo puede emitir. El valor que se escribe se envía como cuerpo de la petición, tal como está escrito.

Lo que contesta el servicio es el resultado del comando. Un estado que el servicio devuelve fuera del rango de éxito es el servicio rechazando el comando, no la conexión fallando: la negativa nombra el estado y cita lo que dijo el servicio con él ("HTTP 500: el quemador está bloqueado"), y con eso no se perturba nada más del dispositivo.

Descubrimiento

El controlador no tiene ninguna exploración de descubrimiento. Añada cada punto de conexión por su host y cada valor por su ruta; el recorrido para añadir un dispositivo se describe en la página Connector.