Hi all,
I’m new in this Lora/LoraWan things and need some guidance regarding how to get the uplink data decoding.
I’m building a prototype for a Smart Water Meter Billing app using Lorawan smart water meter.
For the gateway I’m using TTIG, and a smart water meter. And these two communicating well already. I can see the traffic coming in from the meter in my TTN App, Device and Gateway dashboard, along with the payload. But problem is, all I can see right now is only the timestamp, no flux and meterId. Like below screenshot:
I asked the vendor and he sent me this doc: LoRaWAN_188B(protocol) -[372].pdf (121.4 KB)
The vendor sent me a small parser utility though, but it’s no use cause it’s just a desktop app.
a sample parsing of payload 68 10 03 08 11 17 00 06 39 00 81 20 90 1E 00 00 00 00 2B 00 00 00 00 2B 00 00 00 00 00 00 00 36 0C 24 09 12 03 E4 07 00 80 00 24 00 A2 16
would yield something like below:
But I’ve any idea how to construct my decoder function to get above needed fields (meterId, recent meter reading and timestamp) in my uplink payload.
Can anybody please guide me how to construct my function and how to work with integration to be able to save it in my backend database. Really appreciate it. (a little disclaimer I’m originally a DBA and web app developer who took over this job cause our engineer has moved out to another company)
Just my personal opinion: I think it’s best to use TheThingsNetwork just to transport data and not put part of your application intelligence in some Javascript running on someone else’s server.
I think that for TheThingsNetwork, their “operational priority” is to get incoming LoRaWAN data delivered to their MQTT streams. I assume this will always get priority over problems like issues with decoding scripts.
Also easier to debug if you do the parsing yourself. You can keep your software stack consistent much more easily if it’s not spread out over various scripts running on various servers.
The TTN payload decoder can be convenient to get an immediate interpreted view of the raw data, but I (personally) would not rely on it.
Thanks for the reply and suggestion, Nick. Will have a look at that link.
And yeah, thinking about targeting the v3 too, But for this proto I think I’d stick with v2 at the moment.
@bertrik yes, that’s what my intention. Just to use TTN as data collector and send all collected data to my backend for further processing (ie: billing). I might have a look at MQTT streams.
But I’m trying to get some insights on how to create a function to decode the payload into readable json format. Thanks anyway.
100% agree, it’s useful when developing & looking at the console logs, but there have been several times in the recent past where the server load was so high that the JS decoder engine was timing out so you only got the raw payload - so relatively reliable, but not completely.
And version control on payload formats can lead to a royal mess of checks for which one you are decoding.