Converted @mdallaire document to rst and split in sections as to keep…

[zepiaf]

… all doc in one place. https://github.com/zepiaf/hydroqc/pull/21

[zepiaf]

@mdallaire / @clauderobi

I merged @mdallaire doc in the actual doc

You can preview it here : https://hydroqc.readthedocs.io/en/master/wintercredit/wintercredit.html

Is that working for you, if yes we'll scrap the other PR (sorry about that :) )

[zepiaf]

Just updated

[zepiaf]

It was done on purpose, but maybe I'm wrong.

An event has no type : it's a critical_peak_event

A period can any of normal | peak | reference | anchor | critical | pre_heat

This is a composite indicators as mentioned by @clauderobi

[zepiaf]

An event of type none is not an event, it's nothing (i mean it won't be in the data). It would make sense to type the event if we had other categories existing.

The big question now is what should the data look like, I'm thinking about something like this:

period: {
  type: PERIOD_TYPE,
  date: DATE,
  start: DATE_TIME,
  end: DATE_TIME,
  start_ts: TIMESTAMP,
  end_ts: TIMESTAMP
}

critical_peak_event: {
  date: DATE,
  start: DATE_TIME,
  end: DATE_TIME,
  start_ts: TIMESTAMP,
  end_ts: TIMESTAMP
}

state: {
  current_period_type: PERIOD_TYPE,
  event_forecast: {
    today : {
      morning: BOOLEAN,
      evening: BOOLEAN
    },
    tomorrow : {
      morning: BOOLEAN,
      evening: BOOLEAN
    }
  }
}

periods: { 
  past: [ period, period, ...],
  future: [ period, period, ...]
}
events: { 
  past: [critical_peak_event, critical_peak_event, ...] 
  future: [critical_peak_event, critical_peak_event, ...] 
}