# Profile type
This section explains the profileType creation process in order to make different comparisons between the actual user's consumption and its profile type.
## Profile type data
The profileType data are stored in the profile doctype and includes the following information :
```ts
{
housingType: HousingType
constructionYear: ConstructionYear
area: string
occupantsNumber: number
outsideFacingWalls: OutsideFacingWalls
floor: Floor
heating: IndividualOrCollective
coldWater: IndividualOrCollective
hotWater: IndividualOrCollective
individualInsulationWork: IndividualInsulationWork[]
hasInstalledVentilation: ThreeChoicesAnswer
hasReplacedHeater: ThreeChoicesAnswer
hotWaterEquipment: HotWaterEquipment
warmingFluid: WarmingType | null
hotWaterFluid: FluidType | null
cookingFluid: FluidType
updateDate: DateTime
}
```
Each profileType value is an enum that you can find in the application. The values are set by default to a default profileType and needs to be completed by the user in order to become accurate.
## Profile type form
User should answer a form to be able to set its profile type.
Here is the flow of questions:
## Profile types handling over time
A user can have many profileTypes, Ecolyo takes into account that one can move from his home, have more occupants, start renovating works and so on.
That's why a profileType is only active for a given time period, this is how its time logic works.
### No filled profileType
A default profileType is loaded in redux to operate basic operations. When the user looks at its analysis or options, ecolyo suggest user to fill a more accurate profileType.
### First profileType
The profileType will follow the form logic above (see ProfileType form section). *updateDate* field will be the current month and year.
Since this profileType will be the only one in database, *getProfileType()* method will always return it, therefore it will be used for all past time period on analysis.
### Following profileTypes
Each new profileType form will show a calendar picking section at the end of the form.
By default, current month and year will be selected.
If current year is not yet completed (december not reached), month dropdown menu will only propose past and present months for this year.
When finishing, before the new profileType is saved. Checks if other profileTypes exist on the period between selected month/year and present day.
- If profileTypes are found, they are deleted (newest profileType always prevails on older ones, so that user had forgotten to fill some information before, this new profiletype will be more accurate). Then save profileType on given month/year.
- If no other profileTypes are found, save profileType on given month/year.
## Profile type entity service
Here you can see the different methods provided by the profileType service. These methods allows to calculate the average consumption depending on the information gathered in user's profileType.
| Method | Description |
| -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| getProfileType(date?: DateTime) : Promise-ProfileType, null | Returns a profiletype closest to the given param date. When no param date, returns most recent profiletype |
| getAllProfileTypes(timePeriod?: TimePeriod) : Promise-ProfileType[], null | Returns all profiletypes for given time period, if no param returns all profiletypes |
| updateProfileType(attributes: Partial-ProfileType): Promise-ProfileType, null | Saves profiletype in CouchDB |
| deleteProfileTypes(profileTypes: ProfileType[]): Promise-boolean | Delete array of profileTypes |
| parseProfileTypeEntityToProfileType(profileTypeEntity: ProfileType): ProfileType | Retrieves ProfileType from the ProfileTypeEntity |
## Profile type service
Here you can see the different methods provided by the profileType service. These methods allows to calculate the average consumption depending on the information gathered in user's profileType.
| Method | Description |
| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| getMonthlyForecast(month: number) : Promise-MonthlyForecast | Used to get the monthly forecast for a given month |
| getFluidForecast(fluidType: FluidType, month: number) : Promise-FluidForecast | Used to get the monthly forecast for a given FluidType |
| getDetailsMonthlyForecast(fluidType: FluidType, month: number): Promise-DetailsMonthlyForecast | Used to get the details of a fluidForecast. For each fluid return the related consumption |
| getMonthColdWaterConsumption(month: number): number | Returns the cold water consumption in L for a given month |
| getMonthElectricSpecificConsumption(month: number): number | Returns the electric specific consumption in kWh for a given month |
| getMonthCookingConsumption(month: number): number | Returns the cooking consumption in kWh for a given month |
| getMonthEcs(month: number) : number | Returns the hot water consumption in kWh for a given month |
| getMonthHeating(month: number): Promise-number | Returns the heating consumption in kWh for a given month |
| calculateTotalConsumption(spreadConsumption: number, profileType: ProfileType, month: number) : number | Returns the total ECS consumption with applyied corrections to the spreadConsumption depending on users facilities. |
| calculateSpreadNeeds(profileType: ProfileType, month: number): number | Calculate the water spread consumption |
| calculateMonthWaterRawNeeds(profileType: ProfileType, month: number) : number | Returns the raw water needs of a home |
| calculateWarmingEstimatedConsumption(): number | Calculates the estimated consumption of a home |
| calculateWarmingCorrectedConsumption(estimatedConsumption: number): number | Apply the different corrections to the estimated heating consumption |
| calculateWarmingMonthConsumption(correctedConsumption: number, month: number): Promise-number | Apply dju ratio to the corrected heating consumption |
| fetchDJU(month: number): Promise-number | Returns a Promise with the dju for the given month |
Here is an example of a MonthlyForecast, which is the only function directly called by the analysis component :
```ts
{
fluidForecast: [
{
detailsMonthlyForecast: {
coldWaterConsumption: null,
cookingConsumption: null,
ecsConsumption: null,
electricSpecificConsumption: 266,
heatingConsumption: 4074,
},
fluidType: 0,
load: 4340,
value: 670.96,
},
{
detailsMonthlyForecast: {
coldWaterConsumption: 14911,
cookingConsumption: null,
ecsConsumption: null,
electricSpecificConsumption: null,
heatingConsumption: null,
},
fluidType: 1,
load: 14911,
value: 46.224,
},
{
detailsMonthlyForecast: {
coldWaterConsumption: null,
cookingConsumption: 85,
ecsConsumption: 290,
electricSpecificConsumption: null,
heatingConsumption: null,
},
fluidType: 2,
load: 375,
value: 29.737,
},
],
month: 1,
totalValue: 746.921,
}
```
In these data, the load is in kWh for gas and electricity (fluidtype 0 and 2) and in L for water. Value and totalValue are given in euros. The different consumption are distributed to their corresponding fluidType according to the variables **_warmingFluid, hotWaterFluid, cookingFluid _**. For example, if the cookingFluid is gas, then its value will be stored in the fluidType 2 and nulled in the others.
Also, we consider that if the heating or the hotwater are collective, we don't calculate it because the user can never access his personal consumption, so it doesn't takes place in the calculation.
## DJU
The method **fetchDJU(month:number)** tries to fetch the daily dju from the datagrandlyon API trough a remote doctype named *org.ecolyo.dju*.
The data returned by this API are gathered by the lyon-bron-station The API returns dju by day for a given month, so we add them to return a monthly dju. If remote doctype fails or return a null value, we returns instead the default dju stored in *heating.json*
Useful tips while working with this API :
- Do not pass a Content-Type while requesting, it will returns error
- While requesting from a cozy instance, if you get errors, you will get errors from the cozy stack and not directly from the API, which leads to weird cases :
- If there is an authentication error, the api will returns an error in *html* format to cozy, so you'll get from cozy an error 502 as following, because cozy expects a json response :
```json
{
"status": "502",
"title": "Bad Gateway",
"detail": "the content-type for the response is not authorized",
"source": {}
}
```
- In case of bad request (wrong parameters for example), the API will return an error in *xml* format so you'll get exactly the same error as above in your cozy instance.