When the server returns data from today; it should return the data from today:00h00 to today:now and not today:23:45

This way, it avoids zeros data on the client-side.

Write the nodejs tool which will be launched as a background task to periodically call opendatareseaux's API and store in our specific format.
This format will be discussed here.

See branch feature/30

Mixed Content: The page at 'https://www.facteurs-charge.fr/' was loaded over HTTPS, but requested an insecure resource 'http://facteurs-charge.fr/now'. This request has been blocked; the content must be served over HTTPS.

Configuration:

Google Chrome | 81.0.4044.129 (Build officiel) (64 bits)
Révision | 3d71af9f5704a40b85806f4d08925db24605ba25-refs/branch-heads/4044@{#979}
Système d'exploitation | macOS Version 10.15.4 (assemblage 19E287)
JavaScript | V8 8.1.307.31

I don't know if this issue is

• server side ; but maybe this can help.
• or client side where the requested url starts with http.

When hitting http://localhost:8080/api/v1/zones/FR/installations/breakdown the breakdown is plainly wrong:

"breakdown": {
      "solar": {
        "production": {
          "unit": "MW",
          "value": 0
        },
        "capacity": {
          "unit": "MW",
          "value": null
        }
      },

But getting this on a zone returns the proper schema.

This issue is meant to talk globally about what is next in terms of slides.
So far, we have a map, a slide that shows the breakdown of the installations' production, and a slide that shows the breakdown of the installations' load.

This issue is meant to discuss the new API. So I'll start!

• Why the field evolution is needed and what does it represent?

This slide emerges from discussion on issue #38

It is part of v.2 ?

As mentioned by @PETILLON-Sebastien here this slide is meant to show the local energetic balance: the energy (electricity) does not disappear if produced and not consumed locally, it is either stored (another topic) OR exported.

This slide deliberately does not mention the storage as a thing.
It makes the slide too complex to quickly understand it.
The storage, for my pov, is a local consumption, to create a virtual power bank that will be used later. We need to discuss further this topic to see if this storage thing is a slide on its own or if we don't have enough data to say anything about it.

Here is my first proposition.

Feedbacks are welcome! :)

Script to transform old data stored on the server to the brand new format chosen in the Daemon for data retrieval issue.

The Map component should display the most loaded sources for each zone.
Thus, the client needs to have this route implemented :)

Ultimately, the map will only need the most loaded power source on the LAST snapshot for each zone

Maybe get_installations_load_breakdown is better than get_installations_load ?

The shouldComponentUpdate is wrong, leading to a render of non-set variable leading to NullE

• Fetching data should be encapsulated
• Components must be split up (e.g. navbar != board)
• Adding loading screen

I failed to run this project locally...

As stated in the README.md file, I ran npm i @babel/preset-env @babel/preset-react --save-dev.
This prompts: Select your Highcharts version (e.g. 4.2.2):: (latest) .
Does this choice matter?

Then, the doc states
Pour exécuter le front-end, lancez la commande npm run watch puis ouvrez le fichier index.html.
npm run watch does not yield an index.html file but a static/facteurscharge.html is yielded.

When I open this file, css and js files can not be loaded.
I had to modify this path and this path to relative paths that start with ./.

I am definitely doing something wrong....Am I?

Each API route will need to find data from files.
We need a common tool, able to retrieve data from different files if needed.
This issue depends on the file format decided in the Daemon for data retrieval issue.

The back needs to have a route to retrieve the most loaded installations for a zone, or for all zones.

Something like /zones/installations/load?filter=highest may make sense.

On http://localhost:8080/api/v1/zones/FR-11/installations/breakdown , the indicated load is systematically below 0.01 which seems like two division per 100 instead of one.

Eg : "value": 0.004950004950004951.
I would have expected, on Ile-de-france, a ~50% fossil load and not a 0.5% one.

The server shouldnt answer with subfield power

      "wind": {
        "power": {
          "unit": "MW",
          "value": 28
        }
      },

Avoid black over grey, grey over light grey, etc
Warning : consistent with electricitymap ?

When hitting http://localhost:8080/api/v1/zones/FR-11/installations/breakdown

{
"solar":{"production":{"unit":"MW","value":0},"capacity":{"unit":"MW","value":133.33},"load":{"value":0}},"wind":{"production":{"unit":"MW","value":48},"capacity":{"unit":"MW","value":89.02},"load":{"value":53.92046731071669}},
"hydraulic":{"production":{"unit":"MW","value":5},"capacity":{"unit":"MW","value":20},"load":{"value":25}},
"nuclear":{"power":{"unit":"MW","value":0}},
"bioenergy":{"production":{"unit":"MW","value":137},"capacity":{"unit":"MW","value":319.03},"load":{"value":0.4294266996834154}},
"fossil":{"production":{"unit":"MW","value":10},"capacity":{"unit":"MW","value":2222.22},"load":{"value":0.004500004500004501}}
}

Find the better way to estimate capacities with the smallest range of time (days ?) from 01/01/2013 to 01/31/2020 and use the historic data from the opendatareseaux APIs to create file descriptions for this period, to allow the display of screens on this period.
This issue needs a decision on the file format in the Daemon for data retrieval issue.

To avoid simple attacks or gigantesc calls to the API, we should limit the date range in the calls.
We can discuss about this range here.

We need to update the readme (full english) :

• Explain the purpose of the application
• "How to start ?" update (the description is not accurate anymore)
• Explanations about the work environnement and CI ?
• Link to the API description ? (Is it possible to show the swagger API in github directly from the .yaml description ? I did not found it with a quick search)

Based on the described API and thanks to the official swagger generator, implement the specified routes.
This issue needs both Daemon for data retrieval and Tool to retrieve data from files features completed.

The backend data are mostly sorted.

Somehow, all the data but a teeny tiny portion of it is not.
It goes to 23h45 to 00h00... of the same day :)

Server version : 9bfbd11
Route : http://localhost:8080/api/v1/zones/FR/installations/production/breakdown

190th element of the array:
https://gist.github.com/ttben/23779ad5006da69e5f9146163aaf50bd#file-data-json-L28078

191th element of the array:
https://gist.github.com/ttben/23779ad5006da69e5f9146163aaf50bd#file-data-json-L28225

192th element of the array
https://gist.github.com/ttben/23779ad5006da69e5f9146163aaf50bd#file-data-json-L28372

https://discourse.gohugo.io/t/postcss-error-building-site-since-yesterday/25513
gohugoio/hugo#7278
gohugoio/hugo#7253

This may be solved by specifying node version < 10.3

Easy part : % of low-carbon energy of production in a new slide (wind, solar, hydro, nuclear)
Difficult part : low and high estimations of emissions (gCO2eq/kWe) in a new slide :

• For low estimations, consider fossil as gas, then fuel, then coal
• For high estimations, consider fossil as coal, then fuel, then gas

This can be a starting point: https://oncletom.io/2016/travis-ssh-deploy/

The zone is changed but data in slide power-source is not.