> 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/device-diagnostics.md).
# Diagnóstico del dispositivo
Lee el estado de recepción, la canalización y el feed de eventos de un dispositivo para averiguar por qué no llega la telemetría.
Poner en marcha un sensor es el momento en que es más probable que una implementación quede en silencio. El dispositivo está registrado, el perfil parece correcto, la tabla de mapeo está completada — y no aparece nada en el panel. La pregunta que sigue siempre es la misma: ¿el hardware está inactivo, la radio está fuera de alcance, la carga útil está llegando pero no aterriza en ningún sitio, o todo funciona y el dispositivo simplemente aún no ha llegado a su próximo informe programado?
Los diagnósticos del dispositivo responden a esa pregunta directamente. En lugar de dejarte inferir el estado de la integración a partir de un gráfico vacío, la plataforma informa lo que realmente ha visto del dispositivo — si un mensaje llegó al servidor, si las claves dentro de él coincidieron con tus sensores y si los valores resultantes se escribieron en el historial. Cada estado incorrecto viene con lo específico que hay que comprobar y un atajo a la pantalla donde lo corriges.
## Por qué importa
Sin diagnósticos, un dispositivo silencioso es indistinguible de uno mal configurado. Un ingeniero que pone en marcha cincuenta sondas de cadena de frío en un centro de distribución no tiene forma de distinguir entre una sonda que está fuera del alcance de la pasarela y una sonda que está transmitiendo perfectamente hacia un mapeo que nunca se completó. Ambas parecen un panel vacío, y ambas cuestan una visita al sitio.
Los diagnósticos separan esos casos en el origen. Una sonda que se ha unido a la red pero no ha enviado uplinks es una cuestión de radio o de programación. Una sonda cuyo payload se está decodificando en claves que nunca se mapearon es una solución de dos minutos desde tu escritorio. Saber cuál de las dos estás viendo es precisamente el objetivo.
## Dónde encontrarlo
Abre el dispositivo y cambia a la **Conexión** pestaña. Los diagnósticos aparecen junto a la configuración de conexión, en tres bloques:
| Bloque | Qué responde |
| ----------------------- | -------------------------------------------------------------------------------------------------- |
| **Estado de recepción** | ¿Están llegando datos ahora mismo y se están conservando? |
| **Canalización** | Durante la ventana reciente, ¿hasta dónde llegaron los mensajes: enrutados, mapeados, almacenados? |
| **Feed de eventos** | Mensaje por mensaje, ¿qué ocurrió y cuándo? |
Léelos en ese orden. El estado de recepción te da el veredicto, la canalización te da el patrón y el feed de eventos te da la evidencia individual.
## Estado de recepción
El bloque de estado de recepción reduce todo el recorrido de ingestión del dispositivo a un solo estado, con una breve línea de detalle de apoyo debajo. Un **RECEPCIÓN** encabezado marca el bloque, y un indicador **EN VIVO** o **SIN DATOS** (mostrado como **En vivo** o **Inactivo** en forma compacta) refleja si el tráfico está fluyendo en este momento.
Mientras el bloque se carga ves **Cargando estado de recepción…**. Si no se pueden recuperar los datos de diagnóstico, el bloque muestra **Diagnósticos no disponibles** — el dispositivo en sí no se ve afectado; vuelve a intentar la pestaña.
### Los estados y qué hacer con cada uno
| Estado | Qué significa | Tu siguiente paso |
| ------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Recibiendo y almacenando** | El estado saludable. La línea de apoyo dice `{{count}} sensores mapeados · último valor {{last}}`. Los mensajes llegan, las claves coinciden con tus sensores y los valores se están escribiendo en el historial. | Nada. Si la línea también dice `{{count}} claves más disponibles, sin mapear`, el dispositivo está enviando campos que todavía no has mapeado — conviene revisarlo si quieres que aparezcan en los paneles. |
| **Enviando datos — configura el mapeo para conservarlos** | El dispositivo está transmitiendo y su payload se decodifica limpiamente — `{{count}} claves decodificadas · ninguna mapeada aún` — pero ninguna clave está conectada a un sensor, así que no se conserva nada. | Usa **Configurar mapeo** o **Mapear una clave** para abrir el mapeo y conectar al menos una clave entrante a un sensor. Los valores empiezan a acumularse a partir del siguiente mensaje. |
| **Los datos llegan pero no se almacena nada** | *"Los datos están llegando pero aún no se almacena nada."* Los mensajes llegan a la plataforma, pero ningún valor sobrevive en el historial — normalmente una brecha de mapeo o un decodificador que produce claves distintas de las que esperan tus sensores. | Haz clic en **Corregir mapeo**. Compara las claves del feed de eventos con tus sensores mapeados. Si las claves parecen incorrectas en lugar de simplemente no mapeadas, revisa el decodificador del payload en esta pestaña. |
| **No ha informado — el dispositivo parece fuera de línea** | *"El dispositivo estaba informando pero se ha quedado en silencio."* El dispositivo funcionaba antes y se detuvo. La línea de apoyo — `Se esperaba cada {{interval}} {{unit}} · visto por última vez {{last}}` — te indica el calendario con el que la plataforma está comparando. | Esto es trabajo de campo: comprueba la alimentación o la batería del dispositivo, confirma que sigue dentro del alcance de una pasarela y asegúrate de que el programa de envío no haya cambiado. Si el programa real del dispositivo cambió, corrígelo **Intervalo de envío de datos** en esta pestaña para que no se marque innecesariamente. |
| **Esperando los primeros datos** / **Esperando el primer uplink** / **Aún no se han recibido uplinks** | El registro del dispositivo existe, pero la plataforma nunca ha recibido nada de él. | Dale un intervalo de informe para transmitir. Si pasa la ventana, revisa **QUÉ COMPROBAR** a continuación — y si la unidad se usó alguna vez en otra red, consulta [Antes de que llegue nada: unión a la red](#before-anything-arrives-joining-the-network). |
| **Red alcanzada — esperando datos** | `Unido a la red · aún no hay uplinks`. Para un dispositivo LoRaWAN esto es una buena noticia: las credenciales son correctas y el enlace de radio funciona. El dispositivo simplemente aún no ha enviado un payload. | Espera un intervalo de informe. Si se queda aquí, el dispositivo se está uniendo pero no transmite — comprueba su programación de envío y su estado de alimentación. |
Aparece otra línea de apoyo cuando un dispositivo está configurado pero inactivo: `{{count}} sensores configurados · 0 recibiendo valores`. Tus sensores existen, pero ninguno está recibiendo datos. Trátalo igual que *Los datos llegan pero no se almacena nada* — el mapeo es donde hay que mirar.
### Antes de que llegue nada: unión a la red
Los estados de recepción anteriores describen un ciclo de vida, y conviene leerlos en orden:
**Esperando los primeros datos** → **Red alcanzada — esperando datos** → **Recibiendo y almacenando**
El paso entre los dos primeros es el que suele confundir a la gente, porque ocurre por completo del lado del dispositivo y la plataforma solo puede esperar.
Un dispositivo LPWAN no se "configura" simplemente en una red — tiene que **unirse** a una. Un dispositivo LoRaWAN envía una **solicitud de unión**, el servidor de red la valida frente al DevEUI y AppKey que registraste, y responde con una aceptación de unión. Solo entonces el dispositivo tiene una sesión y empieza a enviar uplinks. Un endpoint MIOTY hace lo equivalente: se **adhiere** a través de una estación base, que es lo que mueve la plataforma a *Red alcanzada — esperando datos*. Hasta que ocurre ese apretón de manos, un registro de dispositivo en la plataforma es solo eso: un registro — con las credenciales correctas y todo.
**Un dispositivo pertenece a una sola red a la vez.** Esta es la parte que sorprende a la gente. Un dispositivo que se puso en marcha previamente en otro sitio — una unidad devuelta de otra instalación, hardware comprado de segunda mano, un sensor que estaba en otra plataforma o en la red de un operador anterior, o una unidad de demostración que volvió de un stand de feria — sigue unido a esa red. No se unirá a la tuya solo porque lo registraste aquí. No está buscando una red nueva; en lo que respecta a su firmware, ya tiene una.
El síntoma es distintivo: el dispositivo se queda en **Esperando los primeros datos** indefinidamente mientras todas las configuraciones que puedes comprobar son correctas. El DevEUI coincide. El AppKey coincide. Está encendido, está dentro del alcance y el intervalo de informe ha pasado varias veces. Nada en **QUÉ COMPROBAR** lo resuelve, porque nada de eso está mal.
La solución es **reiniciar el dispositivo** para que envíe una nueva solicitud de unión. El procedimiento depende del fabricante — pasar un imán, mantener pulsado un botón, un interruptor reed, un ciclo de energía de una duración concreta o un comando downlink — así que consulta las instrucciones del proveedor para tu modelo en lugar de adivinar. Algunos dispositivos distinguen entre un reinicio normal y una nueva unión completa, y solo esta última borra la sesión anterior.
Una vez que se vuelve a unir, el estado pasa a *Red alcanzada — esperando datos* y luego a *Recibiendo y almacenando* en la siguiente transmisión programada del dispositivo.
Dos casos relacionados que conviene reconocer:
* **Un dispositivo que se unió una vez y luego se detuvo** es un problema distinto. Eso es *No ha informado — el dispositivo parece fuera de línea*, y apunta a la alimentación, el alcance o la programación — no a la unión. Un dispositivo no se desune en silencio.
* **Un dispositivo que sigue volviendo a *****Esperando los primeros datos*** después de una unión exitosa suele significar que las credenciales de la plataforma y las credenciales grabadas en el dispositivo no coinciden de una forma que permite que la unión falle en silencio. Vuelve a introducir el DevEUI y el AppKey — [Escanear código QR](/kilo-docs-es/kilo-iot-server/devices/registering-devices.md) elimina el riesgo de transcripción — y reinicia el dispositivo de nuevo.
### QUÉ COMPROBAR y MIENTRAS ESPERAS
Junto a un estado incorrecto o pendiente, la plataforma enumera las comprobaciones relevantes bajo un encabezado **QUÉ COMPROBAR** y — cuando el estado es simplemente temprano — la lista más corta de **MIENTRAS ESPERAS** . Los elementos que verás incluyen:
* Confirma que el dispositivo está encendido y transmitiendo
* Comprueba la alimentación o la batería del dispositivo
* Asegúrate de que esté dentro del alcance de una pasarela / Confirma que sigue dentro del alcance de una pasarela
* Comprueba que AppKey y DevEUI coinciden con el dispositivo
* Comprueba que el decodificador del payload coincide con este dispositivo
* Comprueba que la configuración de conexión es correcta
* Confirma que el dispositivo está enviando según su programación
* Asegúrate de que el programa de envío no haya cambiado
* Dale un intervalo de informe para transmitir
* Mapea al menos una clave entrante a un sensor
La lista es sensible al estado, así que merece la pena leerla y no solo echarle un vistazo: a un dispositivo que ya se ha unido a la red no se le preguntará por AppKey y DevEUI, porque esa pregunta ya está respondida.
Una cosa que la lista no puede decirte es si el dispositivo sigue unido a una red en la que se usó antes que la tuya — eso es invisible desde el lado de la plataforma. Si aquí todo está correcto y el dispositivo sigue sin informar nunca, ese es el caso que hay que sospechar: consulta [Antes de que llegue nada: unión a la red](#before-anything-arrives-joining-the-network).
Cada elemento apunta a una configuración que controlas. AppKey, DevEUI, el decodificador del payload y la configuración de conexión viven todos en esta misma **Conexión** pestaña. El programa de envío se establece en el propio dispositivo y se refleja en **Intervalo de envío de datos** — consulta [Administración de dispositivos](/kilo-docs-es/kilo-iot-server/devices/device-management.md). El mapeo vive en la **Métricas** pestaña, y las acciones de **Corregir**, **Corregir mapeo**, **Configurar mapeo**, y **Mapear una clave** te llevan allí directamente.
### Dispositivos MQTT
Las integraciones MQTT tienen sus propios estados de recepción, porque hay dos enlaces que verificar: la conexión de la plataforma con tu broker y el comportamiento de publicación del dispositivo en él. Dos campos enmarcan el diagnóstico: **Tema esperado** muestra el tema para el que está configurado el registro del dispositivo, y **Publicado en** muestra el tema en el que realmente llegó un mensaje.
| Lo que ves | Qué significa | Tu siguiente paso |
| -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Broker conectado** — *"Tu broker es accesible y Kilo está suscrito"* | El lado del conector está sano. | Pasa al lado del dispositivo. |
| **Conectando con tu broker…** | Se está estableciendo la suscripción. | Dale un momento. Si persiste, verifica la configuración del conector. |
| **Kilo no puede llegar a tu broker** — *"Comprueba la URL del broker y las credenciales en la configuración del conector."* | La plataforma no puede establecer la suscripción, así que ningún dispositivo en este conector puede entregar datos. | Abre el conector y corrige la URL del broker y las credenciales. Consulta [Solución de problemas de MQTT](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md). |
| **Esperando a que el dispositivo publique en el broker de Kilo…** | La suscripción está activa; este dispositivo aún no ha publicado. | Espera un intervalo de informe y luego confirma que el dispositivo está funcionando y apuntando al broker correcto. |
| **Llegó un mensaje a un tema para el que este dispositivo no está configurado** — *"Actualiza el tema de arriba o cambia dónde publica el dispositivo."* | Una publicación llegó a la plataforma pero su tema no coincide con este registro de dispositivo. Compara **Publicado en** con **Tema esperado**. | Corrige el tema en esta pestaña para que coincida con lo que el dispositivo publica realmente, o reconfigura el dispositivo para publicar en el tema esperado. |
| **Aún no hay ningún tema de publicación configurado — establece uno arriba.** | El registro del dispositivo no tiene ningún tema con el que comparar. | Establece el tema de publicación en esta pestaña. |
Cuando el dispositivo publica correctamente, el bloque confirma las condiciones que debían cumplirse para que el mensaje llegara: *"El dispositivo publica en el tema esperado"*, *"El payload es JSON válido"*, *"El ID del dispositivo se resuelve según lo configurado"*, y — para los dispositivos que usan credenciales emitidas por la plataforma — *"Está conectado con sus credenciales MQTT generadas"*.
## Canalización
El bloque de canalización cuenta hasta dónde llegaron los mensajes durante el período reciente, desglosado en **Enrutados**, **Mapeados**, y **Almacenados**.
Estos conteos son una ventana reciente en movimiento, no un total acumulado. La ventana se indica en la etiqueta del bloque: **Estadísticas de los últimos {{days}} días** — así que lee esa etiqueta antes de sacar conclusiones. Un dispositivo mal configurado el trimestre pasado y corregido la semana pasada mostrará aquí conteos limpios; la ventana ya ha pasado por el incidente.
Léelos como un embudo:
* **Enrutados altos, Mapeados en cero** — los mensajes están llegando y se están asignando a este dispositivo, pero ninguna clave está conectada a un sensor. El mapeo es la solución.
* **Mapeados altos, Almacenados en cero** — claves coincidentes pero valores que no persistieron. Revisa las filas de mapeo y los tipos de sensor a los que apuntan.
* **Los tres en cero** — no ha llegado nada a este registro de dispositivo. Esto es un problema de recepción, no de mapeo; vuelve al bloque de estado de recepción.
* **Los tres avanzando juntos** — la integración está sana.
Si el bloque dice **Sin datos de canalización**, la plataforma no tiene nada que contar para este dispositivo en la ventana actual — la misma conclusión que si los tres estuvieran en cero.
## Feed de eventos
El feed de eventos es el registro mensaje por mensaje que hay detrás del resumen. Donde los conteos de la canalización te dicen *con qué frecuencia*, el feed te dice *qué mensaje, cuándo y por qué*.
| Columna | Qué muestra |
| ------------- | ----------------------------------------------------------------------------- |
| **Hora** | Cuándo procesó la plataforma el evento |
| **Etapa** | Qué paso de la canalización describe la fila — Enrutado, Mapeado o Almacenado |
| **Resultado** | Si ese paso tuvo éxito — OK, Omitido o Error |
| **Detalle** | Los detalles de ese paso |
Antes de que exista ningún dato ves **Aún no hay eventos** y *"Los eventos aparecerán aquí una vez que el dispositivo envíe datos."* — lo esperado para un dispositivo que no ha transmitido.
El feed se carga por páginas. Haz clic en **Cargar más** para obtener la siguiente página; muestra **Cargando…** mientras obtiene datos y **Todos los registros cargados** una vez que hayas llegado al final del historial disponible. Las filas individuales ofrecen **Detalles** para expandir el contexto completo de un evento y **Ocultar** para volver a contraerlo. **Ver estado de recepción** te lleva de vuelta al bloque de resumen de la parte superior.
### Qué significan estos estados
El feed incluye su propia leyenda bajo el encabezado **Qué significan estos estados**:
| Término | Significado |
| --------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **Enrutados** | El mensaje llegó a la plataforma y se asignó a este dispositivo. |
| **Mapeados** | Las claves entrantes se asignaron a tus sensores configurados. |
| **Almacenados** | Los valores de los sensores se guardaron en el historial. |
| **OK** | Este paso se completó correctamente. |
| **Omitido** | No procesado intencionalmente (por ejemplo, sin mapeo coincidente o un tema inesperado). No necesariamente es un error. |
| **Error** | Este paso falló y necesita atención. |
**Omitido es la fila que despista a la gente.** No es un fallo — la plataforma te está diciendo que tomó una decisión deliberada. Una `Mapeado / Omitido` fila significa que llegó una clave que ningún sensor reclama; si esa clave te importa, mapéala. Si no, la fila es el comportamiento correcto y puedes ignorarla. Una `Error` fila es lo contrario: algo falló y el mensaje no completó su paso. Ábrela con **Detalles** y actúa según lo que informe.
## Leyendo el feed para arreglar un dispositivo
Una secuencia práctica cuando un dispositivo no está entregando datos:
1. Abre el dispositivo y ve a la **Conexión** pestaña.
2. Lee el estado de recepción. Si nombra un problema específico — claves sin mapear, un tema inesperado, un broker inaccesible — usa el botón de acción junto a él (**Corregir**, **Corregir mapeo**, **Configurar mapeo**, **Mapear una clave**) y resuélvelo allí.
3. Si el estado dice que el dispositivo está esperando o en silencio, comprueba la línea de apoyo para ver el intervalo y la hora del último visto, y luego revisa **QUÉ COMPROBAR**.
4. Mira los conteos de la canalización para ver dónde se detienen los mensajes en el embudo, teniendo presente la ventana en la **Estadísticas de los últimos {{days}} días** etiqueta.
5. Abre el feed de eventos y encuentra las filas más recientes en esa etapa. Expande una fila con **Detalles** para ver exactamente qué clave o tema estuvo involucrado.
6. Aplica la corrección, luego espera un intervalo de informe y vuelve a leer el bloque. Los valores se almacenan a partir del siguiente mensaje que cumpla los requisitos — los mensajes anteriores no se reprocesan, así que una transmisión nueva es lo que confirma la reparación.
Las claves del conector aparecen en el mapeo automáticamente una vez que el dispositivo transmite — no necesitas escribirlas. Por eso importa el orden: haz que el dispositivo transmita primero y luego mapea lo que realmente llegó.
## Diagnósticos del conector
Los diagnósticos también existen un nivel más arriba. Abre un conector y encontrarás una **Diagnósticos del conector** área que cubre todos los dispositivos que hay en él, con un resumen de **Estado de la fuente** y dos pestañas:
* **Entrantes** — lo que está llegando al conector, con una `{{count}} vistos` cifra.
* **Actividad** — el historial reciente de eventos del conector. Antes de que haya tráfico, muestra **Aún no hay actividad**. Si no se pueden cargar los datos de diagnóstico, muestra **Diagnósticos no disponibles**.
Un **Conectar dispositivo** la acción te permite registrar aquí un dispositivo contra el conector.
Usa los diagnósticos del conector cuando *varios* dispositivos se callan a la vez — ese patrón suele apuntar al conector o al broker, no al hardware. Usa los diagnósticos del dispositivo cuando un dispositivo está en silencio mientras los que lo rodean están bien. Los diagnósticos del conector se limitan a conectores MQTT; otros tipos de conector solo muestran su configuración.
Para problemas del lado del broker, TLS, autenticación y enrutamiento de temas, consulta [Solución de problemas de MQTT](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md).
## Consejos
* **Configura con honestidad el intervalo de envío de datos.** Los diagnósticos miden "quedarse en silencio" frente al intervalo que introdujiste. Una sonda que informa una vez al día pero está configurada como horaria será marcada fuera de línea veintitrés veces al día, y un sensor realmente muerto configurado como mensual permanecerá en verde durante semanas.
* **Comprueba el estado de recepción antes de abrir un ticket.** *Enviando datos — configura el mapeo para conservarlos* es una solución de escritorio. *No ha informado — el dispositivo parece fuera de línea* requiere una visita al sitio. La diferencia merece treinta segundos.
* **Vigila la ventana de la canalización durante la puesta en marcha.** Los conteos cubren los días nombrados en la **Estadísticas de los últimos {{days}} días** etiqueta, así que un dispositivo arreglado hace una hora sigue arrastrando sus mensajes fallidos en el conteo. Juzga una corrección reciente por las filas más nuevas del feed de eventos, no por los totales.
* **Las claves no mapeadas son una oportunidad, no un error.** Cuando un dispositivo saludable informa `{{count}} claves más disponibles, sin mapear`, el hardware está enviando mediciones que aún no estás usando — un sensor de vibración puede estar informando temperatura a la vez, sin coste adicional de batería ni de tiempo de transmisión.
* **Los diagnósticos complementan la pestaña Registros, no la reemplazan.** Los diagnósticos explican *por qué* por qué el procesamiento siguió el camino que siguió. La pestaña Registros muestra las lecturas sin procesar. Consulte [Administración de dispositivos](/kilo-docs-es/kilo-iot-server/devices/device-management.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/device-diagnostics.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.
