bertrik
commented
2 years ago This is a good idea I think, there's now a 1-on-1 relationship between the device-name in the TTN application and the payload name as published towards habhub.
I can think of a couple of possible solutions: 1) Just add a config item 'payload-name' (or similar) for it in the YAML config file 2) Use the concept of TTN device attributes, basically free-to-define key-value pairs
I've used solution 2 for another TTN application, where I have multiple devices under one app. I didn't want to keep a database of id-to-payload mappings in the bridge software. The device attribute makes it easy for the TTN-device administrator to control how the data is routed, without having to reconfigure the bridge-software.
I think solution 1 is the most appropriate here, since you probably have both sides under your control and probably only have one TTN device, for one TTN application at a time.
What kind of solution would you like to see?
I would like to be able to hardcode a callsign in the config file, that will override the callsign from ttn/helium. This is useful because the ttnhabbridge may receive packets from helium or ttn with different call signs from the same balloon. They need to be treated as a single balloon by habhub.
If the callsign is not supplied, then use the callsign from ttn/helium.