Simulate uplink and schedule downlink based on device repository examples

[johanstokking]

Summary

Simulate uplink and schedule downlink based on examples declared in the device repository.

Why do we need this?

To make it really easy to test integrations.

What is already there? What do you see now?

Onboarding devices via the device repository.

What is missing? What do you want to see?

In the Messages tab, when the end device has a version set, retrieve uplink examples from the device repository and put the example names in a dropdown and schedule the binary payload. It can also be a pre-fill for the input field, so that the user can see what the binary payload is.

Same for scheduling downlink.

How do you propose to implement this?

I suppose this needs an API extension to list the codec information with the payload examples. When those can be retrieved by the end device's version identifiers, the dropdowns can be populated.

How do you propose to test this?

Test with devices with and without examples.

Can you do this yourself and submit a Pull Request?

Can test

[neoaggelos]

Had already done some work on this during initial implementation, parts of which were also used for the Wall Of Fame during the conference.

My proposal would be to extend MessagePayloadFormatter with two new fields:

• CodecID: this comes from the Device Repository, and can be used by users to refer to the Device Repository
• Examples: this parses the codec examples from the Device Repository. For the Output of each example, a protobuf.Struct is used.

This also means that we add field mask paths to the GetPayloadFormatterRequest. By default, only the formatter and formatter_parameter fields are returned, maintaining backwards API compatibility.

[johanstokking]

My proposal would be to extend MessagePayloadFormatter with two new fields

Why?

[neoaggelos]

My proposal would be to extend MessagePayloadFormatter with two new fields

Why?

I am open to alternatives, but I think it's a simple solution: The ttnpb.MessagePayloadFormatter message is used by the Get*Codec() RPCs only. The AS can keep using it to retrieve the codecs and encode/decode payloads, and the Console can then use it to retrieve both the codec (if needed) and the codec examples.

[johanstokking]

Right, I was confused with MessagePayloadFormatters (plural). Sounds good to me.