Add a future activity annoucements broadcast channel

[leandro-lucarella-frequenz]

What's needed?

We want a mechanism to announce future activity so actors executing dispatches (or wanting to announce future activity for any other reasons) can broadcast this information, and actors wanting to use this information to make decisions can subscribe to the announcements.

For example, if some actor know that it will need to discharge a battery with X power at some point in time, it can send an announcement about this so other actors can plan and maybe avoid using that battery at that time (or whatever action makes more sense).

This is somewhat similar to dispatching but dispatches are requests, and just because they are broadcasted doesn't mean they will be executed. Actors should not make decisions based on which dispatches are being broadcasted, only

Proposed solution

Probably it should be enough for the SDK to just provide a BroadcastChannel of some FutureActivityAnnouncement objects. This channel should be created when the SDK is initialized.

Users should be able to create new senders (to announce future activity) and receivers (to subscribe to announcements) for this channel.

Actors executing dispatches should announce the future activity.

Use cases

No response

Alternatives and workarounds

• Use ad-hoc communication between actors.

Additional context

At some point we need to provide a way to notify that some future activity announcement was cancelled, as actors making those announcements might decide not to do what they announced after all if some condition changed.

One way to do this could be for every announcement to have a UUID and to have a special cancellation message referencing that UUID, another way might be to set the announcement value (power or whatever) to zero and identify the announcement using a combination of announcement properties (for example actor name and time of the future activity).

[leandro-lucarella-frequenz]

We still need to define at least the following:

• Where to put this? frequenz.sdk.actor.announcements_channel?
• How will the FutureActivityAnnouncement look like, which properties will it have? Maybe it can be based on dispatch messages as there is some overlap?

[thomas-nicolai-frequenz]

properties will it have?

1. Identifier: Can be the actor name or some other identifier. Keep in mind that future activity might not just be the result of some future actor activity but also being announced by a human through the UI. However, lets focus on the actor part for now as this is the closest use case we are facing. The identifier should stay consistent so the actor can override/update pre-announced activities in case they change later on.
2. Start time
3. End time
4. Power value (can be positive, negative or zero)

Maybe it can be based on dispatch messages as there is some overlap?

Unlikely that there is an overlap.

[thomas-nicolai-frequenz]

For example, if some actor know that it will need to discharge a battery with X power at some point in time, it can send an announcement about this so other actors can plan and maybe avoid using that battery at that time

The first use case will be that other actors can inform the peak shaving actor ahead of time of their own actions. It would allow the peak shaving actor to react ahead of time.

[thomas-nicolai-frequenz]

I've set the priority to low for now as I don't feel this needs to be part of SDK v1.0

[leandro-lucarella-frequenz]

4. Power value (can be positive, negative or zero)

OK, so announcements will only be about power setting? Also, aren't we missing a target? Like component IDs? Or this will always only affect batteries? But even then, all of them always?

Maybe it can be based on dispatch messages as there is some overlap?
Unlikely that there is an overlap.

I meant in the sense that both are somehow representing an scheduled action (but dispatches are requests and announcements are confirmed).

I've set the priority to low for now as I don't feel this needs to be part of SDK v1.0

This is actually very useful information, so I created a new milestone called post-v1.0, so we can put there issues that we know for sure we want to address post v1.0 release.

[thomas-nicolai-frequenz]

OK, so announcements will only be about power setting? Also, aren't we missing a target? Like component IDs? Or this will always only affect batteries? But even then, all of them always?

This is only about power and not components at this point in time. However, this can of course change:

1. An actor could announce I will be discharging the batteries with XYZ power values with or without giving IDs.
2. A user could announce additional power consumption from an unknown component in the consumption pool. In this case there would be no ID and not component category.