> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-es/kilo-iot-server/devices/registering-devices.md).
# Registro de dispositivos
Registra un dispositivo en Kilo IoT mediante LNS, MIOTY, Tracker, MQTT o el Emulador — construye su Gemelo Digital, perfil y asignaciones de métricas.
Cada dispositivo registrado en el servidor Kilo IoT se convierte en un Digital Twin: una representación digital completa que refleja el estado actual del dispositivo, su configuración, el historial de telemetría y los patrones de comportamiento. El Digital Twin persiste incluso cuando el dispositivo físico está desconectado, lo que te da una vista operativa continua de toda tu implementación. Como la vinculación del dispositivo físico es opcional, puedes crear y configurar por completo un perfil de dispositivo antes de que el hardware esté conectado; así, la configuración y la puesta en servicio del hardware no tienen por qué ocurrir al mismo tiempo. Con el [Emulador](/kilo-docs-es/kilo-iot-server/devices/emulated-devices.md), puedes ir más allá y hacer que el dispositivo produzca datos incluso antes de que exista el hardware.
El registro de dispositivos es el proceso de crear este Digital Twin y vincularlo a un dispositivo físico mediante un conector. El flujo de registro te guía para asignar un nombre al dispositivo, vincularlo a un conector, configurar su perfil de comunicación y mapear las mediciones que reporta.
## Requisitos previos
Antes de registrar un dispositivo, necesitas:
* **Un conector** — al menos un conector LNS, Mioty, Tracker, MQTT (Cloud o External) o Emulator debe estar configurado. Consulta [Conectores](/kilo-docs-es/kilo-iot-server/connectors.md) y la [Conector MQTT](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector.md) documentación.
* **Identificadores de dispositivo** — para dispositivos LoRaWAN: el Device EUI y AppKey (normalmente impresos en el dispositivo o en su embalaje). Para endpoints MIOTY: el End Point EUI y la Network Session Key. Para dispositivos tracker: el Unique ID proporcionado por el fabricante. Para dispositivos MQTT: el segmento de tópico a nivel de dispositivo bajo el que publica el dispositivo, usado como Device ID en el registro del dispositivo; debe coincidir con el segmento publicado carácter por carácter (se eliminan los espacios en blanco de la entrada). **Los dispositivos emulados no necesitan nada de esto** — tú eliges el Device ID.
* **Solo para dispositivos MQTT — el dispositivo debe estar publicando antes de poder completar el mapeo.** La lista desplegable de la clave del conector en la pestaña Mapeo se completa a partir de las claves de carga útil realmente recibidas del dispositivo. Consulta la [sección sobre comportamiento específico de MQTT](#mqtt-specific-behavior) más abajo para el flujo de trabajo de dos pasadas.
## Dónde empezar
Hay dos puntos de entrada para registrar dispositivos — ambos abren el mismo diálogo Gestionar dispositivo:
1. **Dispositivos** — Haz clic **Dispositivos** en la barra lateral. Esta página muestra todos los dispositivos de todos los conectores. Haz clic **Añadir dispositivo** en la esquina superior derecha.
2. **Acción de fila del conector** — Desde la página **Conectores** haz clic en el **+ Añadir dispositivo** botón en cualquier fila de conector. El diálogo se abre con ese conector preseleccionado.
El formulario del dispositivo está diseñado tanto para pantallas pequeñas como para escritorio, así que puedes registrar hardware desde un teléfono mientras estás en el punto de instalación.
## Fase 1 — Crear el perfil del dispositivo
El diálogo se abre en **Añadir dispositivo** modo, mostrando solo la **Información del dispositivo** sección. Aún no se muestran pestañas ni navegación — el primer paso es simplemente identificar el dispositivo.
* **Fotos del dispositivo** — Opcionalmente, carga fotos del dispositivo físico para su identificación visual.
* **Nombre del dispositivo** — Introduce un nombre descriptivo (obligatorio). Usa una convención de nombres que escale en toda tu implementación; por ejemplo, incluyendo la ubicación o el tipo de dispositivo en el nombre.
Haz clic en **Guardar**. El Digital Twin se crea solo con el nombre y la foto opcional. El diálogo cambia automáticamente al modo de edición.
## Fase 2 — Configurar conexión, métricas y registros
Después del primer guardado, el diálogo vuelve a abrirse con **Información del dispositivo**, **Conexión**, **Mapeo** y **Registros** pestañas, y un **Después** botón para navegar entre ellas. Aquí es donde vinculas el dispositivo a un conector y configuras sus datos. Aparecen dos pestañas más cuando corresponden: **Comandos y estados** en un dispositivo que puede recibir downlinks, y **Emulador** en un dispositivo vinculado al conector Emulator.
### Pestaña Conexión
Esta pestaña vincula el Digital Twin al dispositivo que le proporciona datos a través de un conector. La lista desplegable muestra los conectores que tu organización tiene realmente, por nombre y tipo, y los campos debajo cambian para coincidir con el que elijas.
#### Para dispositivos LoRaWAN (conector LNS)
1. **Tipo de conector** — Selecciona el conector LNS de la lista desplegable. Si solo existe un conector LNS, puede estar preseleccionado.
2. **EUI del dispositivo** — Introduce el identificador LoRaWAN único del dispositivo (cadena hexadecimal de 8 bytes, mostrada como `HH HH HH HH HH HH HH HH`). Suele estar impreso en la etiqueta o el embalaje del dispositivo. Una vez que se vincula un dispositivo físico, este campo no se puede cambiar sin desconectar primero el dispositivo.
**Escanear código QR** — En lugar de transcribir dieciséis caracteres hexadecimales de una etiqueta, haz clic **Escanear código QR** y apunta la cámara de tu portátil o teléfono al código QR del dispositivo o su embalaje. El EUI del dispositivo se rellena a partir del código y, si el código también incluye el AppKey, ese campo también se completa. Este es el camino más rápido y seguro al poner en servicio dispositivos en masa — un solo carácter mal escrito en un DevEUI produce un dispositivo que simplemente nunca se une.
Si el navegador no puede acceder a una cámara, el escáner informa **"No se ha encontrado el escáner de códigos QR. Vuelve a intentarlo."** Comprueba que haya una cámara y que el navegador haya recibido permiso de cámara para el sitio; luego inténtalo de nuevo, o introduce los identificadores manualmente.
3. **Usar plantillas de perfil de dispositivo** — Marca esta opción para seleccionar de una biblioteca de perfiles de dispositivo conocidos.
Las plantillas de perfil de dispositivo son preajustes de conveniencia para dispositivos LoRaWAN conocidos. Cada plantilla incluye la clase LoRaWAN del dispositivo, la banda de frecuencia y un **códec** — la lógica de decodificación de carga útil que traduce los datos de uplink binarios sin procesar del dispositivo en campos legibles. Seleccionar una plantilla es un proceso de dos pasos:
* **Marca** — Selecciona el fabricante del dispositivo en la lista de autocompletado.
* **Modelo** — Selecciona el modelo del dispositivo. La lista se filtra según la marca seleccionada.
* **Perfil** — Selecciona el perfil de plantilla para este dispositivo. Las opciones se derivan de las bandas regionales compatibles con el modelo.
Una vez que selecciones los tres, el servidor obtiene la plantilla correspondiente y aplica su configuración al formulario: la LoRaWAN **clase**, **banda**, y **códec** se completan automáticamente. Puedes revisar y ajustar estos valores antes de guardar.
Las plantillas se proporcionan como ayudas de conveniencia. No se garantiza la decodificación correcta de la carga útil para todas las versiones de firmware o revisiones de hardware. Si el códec de una plantilla produce campos faltantes o incorrectos, puedes editar directamente el **Funciones de código** campo directamente (ver más abajo).
Si no usas una plantilla, configura el perfil manualmente:
* **Clase** — Elige la clase del dispositivo LoRaWAN:
* **Clase A** — El dispositivo duerme entre transmisiones y solo abre breves ventanas de recepción después de cada uplink. Esto es extremadamente eficiente en consumo — la mayoría de los sensores alimentados por batería usan Clase A y pueden funcionar durante años con una sola batería.
* **Clase C** — El dispositivo mantiene su receptor abierto continuamente, lo que le permite recibir comandos de downlink del servidor en cualquier momento. Como la radio está siempre escuchando, los dispositivos Clase C consumen mucha más energía y normalmente funcionan con corriente eléctrica. Elige Clase C para dispositivos que necesiten responder a comandos de inmediato, como actuadores, interruptores o pantallas.
* **Marca** y **Modelo** — Introduce el fabricante y el modelo del dispositivo como texto libre.
* **Banda** — Selecciona la banda de frecuencia LoRaWAN para tu región. La banda debe coincidir con la configuración de tu gateway y con las regulaciones de radio de tu región. Opciones disponibles: EU868 (Europa), US915 (EE. UU.), AU915 (Australia), AS923 (Asia), KR920 (Corea del Sur), IN865 (India), RU864 (Rusia), CN470 (China), CN779 (China), EU433 (Europa 433 MHz), ISM2400 (2,4 GHz global). Para una lista completa de bandas de frecuencia por país, consulta [Frecuencias LoRaWAN](/kilo-docs-es/kilo-iot-server/connectors/lns-connector/lorawan-frequencies.md). Para una introducción a LoRaWAN, consulta [¿Qué es LoRaWAN?](/kilo-docs-es/kilo-iot-server/connectors/lns-connector/what-is-lorawan.md).
* **AppKey** — Introduce la clave de aplicación del dispositivo — la clave de cifrado LoRaWAN usada para la activación por aire (OTAA). Normalmente la proporciona el fabricante del dispositivo; consulta el embalaje o la documentación oficial del dispositivo.
#### Añadir al almacén de claves
Las credenciales del dispositivo suelen acabar en un lugar poco práctico: una etiqueta en una unidad que ahora está montada a seis metros de altura en el pasillo de un almacén. Haz clic **Añadir al almacén de claves** en el formulario del dispositivo para almacenar el EUI del dispositivo y el par de claves en Key Vault, donde se pueden recuperar independientemente del hardware y la etiqueta. Para un dispositivo LoRaWAN, esto almacena el AppKey asociado al DevEUI.
Hazlo en el registro, mientras tienes las credenciales delante. Tener que volver a aprovisionar un dispositivo cuyo AppKey ya no tienes archivado significa regresar a la unidad misma, y si la clave puede leerse en ese momento depende del fabricante, y puede requerir una conexión por cable a la placa. Consulta [Key Vault](/kilo-docs-es/kilo-iot-server/reports/key-vault.md).
#### Funciones de código (códec)
La **Funciones de código** campo contiene el códec de carga útil del dispositivo — lógica JavaScript que decodifica la carga útil de uplink LoRaWAN sin procesar del dispositivo en campos con nombre. Estos campos decodificados se convierten en los **claves del conector** visibles en la pestaña Mapeo.
Cuando seleccionas una plantilla de perfil de dispositivo, este campo se rellena automáticamente con el códec de la plantilla. Si configuras manualmente, este campo empieza vacío — es posible que tengas que pegar un códec de la documentación del fabricante del dispositivo o de un repositorio comunitario de códecs.
Si la salida decodificada no coincide con lo que esperas — por ejemplo, si faltan campos, los valores parecen incorrectos o los nombres de campo no coinciden con la documentación de tu sensor — puedes editar el código directamente. El editor es un área de texto multilínea con formato monoespaciado.
#### Intervalo de envío de datos
Un dispositivo transmite según un horario fijo — cada pocos minutos, una vez al día, una vez al mes — y ese horario se configura **en el propio dispositivo**. Varía de un fabricante a otro: algunos dispositivos salen con el intervalo ya configurado por el fabricante, otros requieren que lo configures cuando pones en servicio el dispositivo. En cualquier caso, el horario es una propiedad del dispositivo. El **Intervalo de envío de datos** campo es donde le indicas a la plataforma cuál es ese horario, para que sepa cuándo esperar datos.
Configúralo para que coincida con la forma en que el dispositivo está realmente configurado para transmitir. Si el dispositivo envía una vez al día, establece esto en **1 día**; una vez al mes, establécelo en **1 mes**. El campo empieza en **1 hora** por defecto solo porque la plataforma necesita un valor inicial — no tiene forma de leer el horario real del dispositivo, así que trata ese valor predeterminado como un marcador de posición que debes reemplazar.
Si no llega ningún mensaje dentro del intervalo configurado, el dispositivo se marca como fuera de línea en la lista de dispositivos y se señala en la tarjeta Dispositivos de la página General. Establecer el intervalo para que coincida con el dispositivo es lo que evita que un dispositivo sano y de baja frecuencia sea marcado como fuera de línea simplemente porque está en silencio entre informes programados.
Elige un número y una unidad: **minuto**, **hora**, **día**, **semana**, o **mes**.
> **Los dispositivos emulados son la excepción.** En un dispositivo vinculado al conector Emulator, este campo no es una descripción de un horario que el hardware ya mantiene — *es* el horario en el que la plataforma emite. Consulta [Dispositivos emulados](/kilo-docs-es/kilo-iot-server/devices/emulated-devices.md).
#### Para localizadores de vehículos (conector Tracker)
1. **Tipo de conector** — Selecciona el conector Tracker de la lista desplegable.
2. **ID único** — Introduce el identificador único del dispositivo del localizador.
3. **Modelo del dispositivo** — Busca y selecciona en la biblioteca de modelos de localizadores. Empieza a escribir para filtrar la lista.
4. **URL para rastreador GPS** — Después de seleccionar un modelo, aparece un panel que muestra la URL del endpoint. Haz clic en el botón de copiar para copiarla y luego configura tu localizador para enviar datos a esta URL.
#### Para endpoints MIOTY (conector Mioty)
Selecciona el conector Mioty de la lista desplegable y el formulario muestra el conjunto de parámetros MIOTY — End Point EUI, dirección corta, clave de sesión de red y contadores. Estos campos, sus rangos válidos y el plano que decodifica las cargas útiles del endpoint están documentados en detalle en [Dispositivos MIOTY](/kilo-docs-es/kilo-iot-server/devices/mioty-devices.md).
#### Para dispositivos emulados (conector Emulator)
Selecciona el conector Emulator y el dispositivo genera su propia telemetría en lugar de recibirla — sin identificadores, sin credenciales, sin hardware. Le das un Device ID, eliges qué mide (a mano o desde un preajuste de dispositivo) y estableces con qué frecuencia informa. Una pestaña adicional **Emulador** te permite controlar sus valores directamente.
Así es como construyes una implementación antes de que lleguen los sensores, y cambias al mismo dispositivo al hardware real cuando lleguen. Consulta [Dispositivos emulados](/kilo-docs-es/kilo-iot-server/devices/emulated-devices.md).
### Pestaña Mapeo
Esta pestaña asigna los datos brutos de sensores del dispositivo a definiciones de medición normalizadas. Si se han configurado plantillas de métricas para el tipo de dispositivo, los mapeos pueden completarse automáticamente. De lo contrario, puedes asignar plantillas de métricas manualmente.
#### Claves del conector — mira lo que envía el dispositivo
Una vez que el dispositivo está conectado y transmitiendo, la pestaña Mapeo muestra una **tabla de claves del conector** que muestra cada campo en la carga útil sin procesar del dispositivo. Cada fila muestra el nombre del campo (exactamente como lo envía el dispositivo — por ejemplo, `t`, `temp1`, `humidity_pct`), su valor actual y la marca de tiempo de la última actualización. Esta es la carga útil en vivo del dispositivo, actualizada en tiempo real.
Vuelve a esta tabla siempre que necesites saber qué informa un dispositivo y en qué forma — al escribir una condición de regla o al establecer el valor esperado en un comando. Consulta [Decodificación de carga útil y claves del conector](/kilo-docs-es/kilo-iot-server/devices/payload-decoding.md).
#### Mapear campos sin procesar a plantillas de métricas
Esta es la parte en la que conviertes la salida críptica del dispositivo en mediciones significativas y etiquetadas. Cuando asignas una clave bruta del conector (como `t`) a una plantilla de métricas (como "Temperatura", unidad: °C, tipo: Float), le estás dando a ese campo sin procesar una identidad legible por humanos. A partir de ese momento, los paneles, las reglas de automatización, las alertas y las consultas históricas muestran "Temperatura (°C)" — no el nombre de campo sin procesar que envía el firmware del dispositivo.
Para normalizar un campo sin procesar:
1. **Añadir una métrica** — Haz clic **Añadir clave** y selecciona una plantilla de métrica en la lista desplegable (por ejemplo, "Temperatura", unidad: °C, tipo: Float). Las columnas Unidad, Tipo y Tipo de datos se rellenan automáticamente a partir de la plantilla. Si la plantilla que necesitas no existe, créala primero en [Métricas](/kilo-docs-es/kilo-iot-server/devices/metric-templates.md) .
2. **Selecciona la clave del conector** — En la lista desplegable **Clave del conector** de esa métrica, elige el nombre del campo sin procesar que corresponde a esta medición (por ejemplo, selecciona `t` para un dispositivo que envía temperatura como `t`).
3. **Guardar** — El mapeo entra en vigor inmediatamente. Los datos normalizados fluyen a través de paneles, reglas de automatización, evaluaciones de alarmas y consultas históricas.
Si la clave del conector no está rellenada, los datos de esa métrica se ignorarán.
Repite esto para cada medición que informe el dispositivo. Se pueden mapear varias métricas en una sola sesión.
#### Cualquier dispositivo, cualquier formato de carga útil
Este flujo de trabajo acepta datos de cualquier dispositivo que el servidor pueda recibir, incluidos hardware prototipo con esquemas de carga útil en evolución, sensores de fabricantes de nicho con formatos de telemetría sin documentar y equipos de campo heredados que transmiten identificadores codificados en lugar de nombres de campo legibles por humanos. Si el dispositivo envía datos, la tabla de claves del conector los muestra y puedes mapearlos.
Para obtener detalles sobre la configuración de plantillas de métricas, consulta [Métricas](/kilo-docs-es/kilo-iot-server/devices/metric-templates.md).
#### Comportamiento específico de MQTT
Para dispositivos ingeridos a través del [conector MQTT](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector.md), se aplican dos detalles específicos del flujo de registro:
* **La lista desplegable de la clave del conector está vacía hasta que llega la primera publicación.** La lista desplegable se rellena a partir de las claves de carga útil realmente recibidas del dispositivo, no de una entrada de texto libre. Para un registro de dispositivo MQTT completamente nuevo, esto requiere un guardado en dos pasadas: añade una fila por métrica con la clave normalizada seleccionada y el tipo de datos establecido, deja vacía la clave del conector, guarda, confirma que el dispositivo está publicando, vuelve a abrir el registro del dispositivo — la lista desplegable de la clave del conector ya está rellenada, coincide cada fila, guarda de nuevo.
* **Columna Valor de la pestaña Mapeo frente al historial de la pestaña Registros.** La columna Valor es una instantánea en vivo de la carga útil más reciente (se actualiza con cada publicación aceptada, independientemente de si las claves del conector están rellenadas). La pestaña Registros es el historial por sensor (se rellena solo con las publicaciones que llegan *después* de guardar las claves del conector). Después de completar la segunda pasada, genera una nueva publicación para rellenar la pestaña Registros — las publicaciones anteriores no se normalizan retrospectivamente.
* **El mapeo es iterativo.** El registro inicial rara vez captura todas las claves útiles de la carga útil. Una vez que los datos en vivo hayan estado llegando durante un período representativo, vuelve a abrir el registro del dispositivo, revisa la lista desplegable de la clave del conector y la columna Valor para ver qué se está publicando realmente, añade filas de Mapeo para cualquier campo adicional que quieras seguir, guarda y genera una nueva publicación para que la pestaña Registros empiece a registrar el historial de los nuevos mapeos.
Consulta [Tópicos y enrutamiento de dispositivos](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/topics-and-device-routing.md) para el flujo de trabajo completo de registro específico de MQTT.
### Pestaña Registros
La pestaña Registros está vacía al principio. Después de que el dispositivo empiece a enviar datos, esta pestaña muestra el registro bruto de eventos con marcas de tiempo y detalles de la carga útil.
Haz clic en **Guardar** de nuevo para guardar la configuración de conexión y métricas.
## Después de guardar
El dispositivo aparece en las listas de dispositivos de todo el servidor — en la tabla de dispositivos del conector, en Dispositivos y en cualquier panel o regla de automatización que lo referencie.
Para dispositivos LoRaWAN, los datos comienzan a fluir una vez que el dispositivo físico envía una solicitud de unión y el servidor la acepta. Para dispositivos localizadores, los datos comienzan a fluir una vez que el localizador empieza a enviar datos al endpoint URL configurado.
Registrar un dispositivo aquí no hace que se una. Un dispositivo LoRaWAN se une a una red a la vez, así que una unidad que se comisionó previamente en otro sitio — devuelta desde otra ubicación, comprada de segunda mano o usada en una plataforma diferente — permanece unida a esa red hasta que se restablece y envía una nueva solicitud de unión. El hardware nuevo de fábrica se une por sí solo; cualquier cosa con historial suele necesitar primero un reinicio. Consulta [Antes de que llegue nada: unirse a la red](/kilo-docs-es/kilo-iot-server/devices/device-diagnostics.md#before-anything-arrives-joining-the-network).
Si el dispositivo está registrado pero no llegan datos, abre su **Conexión** pestaña [y lee el estado de recepción — informa de si el dispositivo ha llegado a la red, de si se están recibiendo mensajes y de si se están almacenando los valores que contienen, con el siguiente paso específico para cada caso. Consulta](/kilo-docs-es/kilo-iot-server/devices/device-diagnostics.md).
## Qué sigue
* **Configurar plantillas de métricas** antes o después del registro para controlar cómo se normalizan los datos sin procesar. Consulta [Métricas](/kilo-docs-es/kilo-iot-server/devices/metric-templates.md).
* **Editar propiedades del dispositivo** en cualquier momento a través del mismo diálogo. Consulta [Gestión de dispositivos](/kilo-docs-es/kilo-iot-server/devices/device-management.md).
* **Diagnosticar un dispositivo silencioso** desde su pestaña Conexión. Consulta [y lee el estado de recepción — informa de si el dispositivo ha llegado a la red, de si se están recibiendo mensajes y de si se están almacenando los valores que contienen, con el siguiente paso específico para cada caso. Consulta](/kilo-docs-es/kilo-iot-server/devices/device-diagnostics.md).
* **Registrar un endpoint MIOTY** y sus campos específicos del protocolo. Consulta [Dispositivos MIOTY](/kilo-docs-es/kilo-iot-server/devices/mioty-devices.md).
* **Empezar sin hardware** y cambiar al dispositivo real cuando llegue. Consulta [Dispositivos emulados](/kilo-docs-es/kilo-iot-server/devices/emulated-devices.md).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.kiloiot.io/kilo-docs-es/kilo-iot-server/devices/registering-devices.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
