LoRaWAN payload decoder and webhook inspector
A meter is joined, the gateway sees it, and the dashboard still shows nothing. Nine times out of ten the uplink is arriving and one field is called the wrong thing. Paste the webhook and find out which.
Paste a webhook body
The JSON your network server POSTs to the platform. ChirpStack and TTN are detected automatically. Nothing is uploaded — the check runs in your browser.
Raw payload
Paste an uplink as hex or as base64 — TTN's frm_payload and ChirpStack's data field are both base64. The encoding is detected for you.
No manufacturer byte layouts are built in on purpose. A decoder written from a guess gives a confident wrong answer to someone debugging a real meter, which is worse than no decoder — so this reads the bytes and leaves the interpretation to your datasheet. The reliable route is to run the manufacturer's own decoder in your network server and check the result on the webhook tab.
Getting uplinks but no dashboard?
Once the field names line up, the rest is routing: point the webhook at a platform, and each meter shows up under the right customer with its own history and alerts.
Related
Common questions
- My meter joined and the gateway sees it, but consumption is always zero. Why?
- Almost always a field-name mismatch. A payload formatter written for one meter emits a field like "water" or "cumulativeFlow"; a ChirpStack integration only reads "cumulativeFlowM3" or "cumulativeFlowLiters" and ignores anything else, so it stores zero rather than erroring. Paste the webhook into the inspector above and it will name the field and the rename.
- What is the difference between ChirpStack and TTN field names?
- TTN payloads are read more loosely: consumption can arrive as cumulativeFlowM3, water, or cumulativeFlow (litres), and battery as battery, bateria or the string battery_status. ChirpStack payloads accept only cumulativeFlowM3 or cumulativeFlowLiters for volume, and batteryVoltage for battery. A formatter moved from TTN to ChirpStack without renaming its output is the classic failure.
- TTN shows my uplinks but decoded_payload is missing.
- The payload formatter is not configured, or it threw an error. TTN still forwards the uplink with the raw bytes in frm_payload but no decoded values, and there is nothing for a platform to store. Add the manufacturer's formatter to the device or application in the TTN console. Meanwhile you can paste frm_payload into the raw payload tab to confirm the bytes look sane.
- Why does this not decode my meter's bytes automatically?
- Because getting it wrong is worse than not doing it. Byte layouts differ between manufacturers, between models, and between firmware versions of the same model, so a built-in decoder based on anything less than the current datasheet would quietly hand you a plausible wrong volume. Run the manufacturer's decoder in your network server, where it belongs, and use the webhook tab to check the output.
- Is my payload sent anywhere?
- No. Both tabs run entirely in your browser — there is no request to any server, and nothing is stored. You can check that in your browser's network tab.