[alerts][events] How to define the event life cycle with alerts

[frgfm]

Let's discuss here how we should create events, and link alerts to it.

Context

• An alert is: a signal sent by a device that localizes a wildfire. Natively, it holds: a timestamp, the localization information, the device_id
• an event holds: a type, a localization, a starting timestamp and an end timestamp

Problem statement

• How do we determine the event an alert refers to?
• How do we update the starting & end timestamps of the event?

[frgfm]

Here is a suggestion

Linking an alert to an event

There are two subquestions:

Matching the alert to existing events:

1. we first fetch all events that have no end_ts to get our candidates
2. if an alert was raised by the same device in the last 5 minutes, we take the referred event
3. otherwise taking the GPS location + azimuth of the current alert, and considering a limit of 10km in that direction, we check whether existing active events were reported in that area.

whether we need to create a new event

if the above matching fails, then we create an event first, and the alert will refer to it.

Updating the event

• start_ts: the timestamp of the first alert referring to this event
• end_ts: after a fixed duration (set in the config file most likely) since the last alert referring to this event, we set end_ts to the timestamp of this last alert.
• location: if alerts have been raised about the same event by different devices, using GPS + azimuth we can pinpoint an approximate location.

[fe51]

Thanks for opening the issue ! This is a nice suggestion !

So the inputcreate_alert_from_devicemight change in a way the AlertBase would not include the event_id as long as considering the proposition, an alert is not yet related to an event when sent.

The five minutes and the fixed duration are the same elt isn't it ?

[frgfm]

We actually have the choice:

• either the event_id will be filled after the alert creation
• or we first resolve the event, then create the alert with the field value

Most likely yes !

[frgfm]

Alright, I'll go ahead with 3 PRs:

• [x] implement the event existence check with the 5 minutes duration + start_ts of the event (#149)
• [ ] implement the conversion device GPS + alert azimuth --> event location
• [ ] implement the end_ts resolution of an event (perhaps it should be a user action from the platform :man_shrugging: )

[frgfm]

Lowering importance since we could first move forward with the sole relaxation duration criteria (event location resolution isn't critical for MVP)

[frgfm]

Closed by #405 & #412 The GPS resolution is out of scope for now