Replay received uplinks/scheduled downlinks from the events view in the Console

[bafonins]

Summary

@adriansmares proposed feature to send already received messages in the events view

Why do we need this?

I think this can be quite helpful when one:

1. Is working on configuring an end device to, say, receive a certain downlink message and respond with an uplink or vice versa (receive uplink via integration and schedule downlink to the end device). Currently, it is possible but the user has to keep 2 tabs open (one for sending downlinks and the events view to see device response).
2. Is working on a custom backend (connected via integrations) that should react when receiving a cetain event. In this case the user might be more interested in looking at the applications logs, but I believe that looking at the events in the Console can be helpful as well.
3. Already installed an end device (e.g. door sensor) and want to send uplinks without opening/closing the door and debug at the same time.

What is already there? What do you see now?

1. Events view where one can observe the events stream.
2. Messaging view where one can send uplinks and schedule downlinks.

What is missing? What do you want to see?

A button for uplink/downlink events that "replays" this particular event. This can rendered in the event details panel.

How do you propose to implement this?

1. Add button for events that need it.
2. Reuse API for scheduling downlinks and sending uplinks. (We might want to set the received_at filed to current time)

How do you propose to test this?

manual and e2e tests.

Can you do this yourself and submit a Pull Request?

yes

[bafonins]

@johanstokking What do you think?

@rvolosatovs Can this be helpful for you when debugging network server, events server, etc?

[johanstokking]

This is purely on the application-layer, right?

I think it would be useful to select a downlink message as a predefined test message for the application, that can be sent to devices within that application. Likewise for uplink messages.

So it would be a few test downlink and uplink messages within an application that the user can send individually as downlink message to an end device or as simulated uplink message to an integration.

[bafonins]

This is purely on the application-layer, right?

Why only application-layer?

@KrishnaIyer @elsalahy Can you benefit anyhow from this feature? Would be nice to hear some use cases from you guys.

[KrishnaIyer]

Hmm I have the same question as @johanstokking. There are 2 ways I imagine your description a. This just duplicates a past event to observe what happens? b. Replaying an event (Simulate Uplink / Send Downlink) meaning fetch the parameters of a console action that causes an event and do it again?

Which is closer to your proposal?

[bafonins]

Here is concrete use case of mine. I want The Things Uno to wait for downlinks on a certain port and with certain payload, depending on these I want to send a certain uplink. All I want to do is test that the sketch I upload to arduino indeed does what it is supposed to do. Currently, I have to switch between 3 windows:

1. Schedule downlink page in the Console - to send different downlinks
2. Events page - to see that the device correctly responds to downlinks and sends an uplink.
3. Arduino IDE - to recompile and fix the sketch if there are issues.

Im proposing to add functionality that allows capturing any event (uplink/downlink) in the events page and replay (simulate) those when needed from the events page.

So, this is more about adding additional functionality (only in the Console, we have required API for this already) to the events page. But Im also happy to hear other suggestions from people who regularly use the events page to test/debug devices/integrations.

[johanstokking]

Right, so that is all application layer: LoRaWAN FRMPayload on an FPort. We're not talking about replaying MAC commands or replaying infrastructural events generated by AS, for example. That would make things infinitely more complicated.

So if we scope this to replaying uplink messages (simulate uplink) and replaying downlink messages (send downlink), keeping a record of a few messages to replay on the application level, I think that is a great idea.

[elsalahy]

Yeah sounds like a great feature indeed, as we sometimes run in a situation in development or deployment where we need to replay a downlink or an uplink.

This will be most useful in sending device commands/triggers.

A relevant scenario:

• Obtaining device on board real time clock information
  • Send a command (downlink) to request the device current clock/time.
  • Re-send the same exact command after some time to observe the device clock drift.