Decodificador de payload LoRaWAN e inspector de webhooks
El contador ha hecho join, el gateway lo ve, y el panel sigue sin mostrar nada. Nueve de cada diez veces el uplink está llegando y hay un campo que se llama de otra forma. Pega el webhook y averigua cuál.
Pega el cuerpo de un webhook
El JSON que tu network server envía por POST a la plataforma. ChirpStack y TTN se detectan automáticamente. No se sube nada — la comprobación se hace en tu navegador.
Payload en bruto
Pega un uplink en hexadecimal o en base64 — el frm_payload de TTN y el campo data de ChirpStack van en base64. La codificación se detecta sola.
No hay estructuras de bytes de fabricantes incorporadas, y es a propósito. Un decodificador escrito a ojo da una respuesta equivocada con toda seguridad a alguien que está depurando un contador real, lo cual es peor que no tener decodificador — así que esto lee los bytes y deja la interpretación a tu hoja de datos. Lo fiable es ejecutar el decodificador del propio fabricante en tu network server y comprobar el resultado en la pestaña de webhooks.
¿Recibes uplinks pero no tienes panel?
Cuando los nombres de campo cuadran, lo que queda es enrutado: apunta el webhook a una plataforma y cada contador aparece bajo el cliente que le corresponde, con su histórico y sus alertas.
Relacionado
Preguntas frecuentes
- Mi contador ha hecho join y el gateway lo ve, pero el consumo sale siempre a cero.
- Casi siempre es un nombre de campo que no cuadra. Un payload formatter escrito para otro contador emite un campo como «water» o «cumulativeFlow»; una integración de ChirpStack solo lee «cumulativeFlowM3» o «cumulativeFlowLiters» e ignora lo demás, así que guarda cero en lugar de dar error. Pega el webhook en el inspector de arriba y te dirá el campo y el nombre correcto.
- ¿En qué se diferencian los nombres de campo de ChirpStack y de TTN?
- Los payloads de TTN se leen con más manga ancha: el consumo puede llegar como cumulativeFlowM3, water o cumulativeFlow (litros), y la batería como battery, bateria o la cadena battery_status. Los de ChirpStack solo aceptan cumulativeFlowM3 o cumulativeFlowLiters para el volumen, y batteryVoltage para la batería. Mover un formatter de TTN a ChirpStack sin renombrar su salida es el fallo clásico.
- TTN muestra mis uplinks pero falta decoded_payload.
- El payload formatter no está configurado, o ha dado error. TTN sigue reenviando el uplink con los bytes en bruto en frm_payload pero sin valores decodificados, y no hay nada que una plataforma pueda guardar. Añade el formatter del fabricante al dispositivo o a la aplicación en la consola de TTN. Mientras tanto puedes pegar frm_payload en la pestaña de payload en bruto para confirmar que los bytes tienen buena pinta.
- ¿Por qué no decodifica automáticamente los bytes de mi contador?
- Porque equivocarse es peor que no hacerlo. Las estructuras de bytes cambian entre fabricantes, entre modelos y entre versiones de firmware del mismo modelo, así que un decodificador incorporado basado en algo que no sea la hoja de datos vigente te daría en silencio un volumen verosímil pero equivocado. Ejecuta el decodificador del fabricante en tu network server, que es su sitio, y usa la pestaña de webhooks para comprobar la salida.
- ¿Se envía mi payload a algún sitio?
- No. Las dos pestañas funcionan enteramente en tu navegador — no hay ninguna petición a ningún servidor y no se guarda nada. Puedes comprobarlo en la pestaña de red de tu navegador.