{"id":348937,"name":"PVForecast","description":"Forecasts to optimize electricity consumption for rooftop PV installations.","url":"https://github.com/stefae/pvforecast","last_synced_at":"2026-04-29T20:01:03.605Z","repository":{"id":52764533,"uuid":"325843997","full_name":"StefaE/PVForecast","owner":"StefaE","description":"Forecasts to optimize electricity consumption for rooftop PV (photo-voltaic) installations","archived":false,"fork":false,"pushed_at":"2025-04-21T14:50:42.000Z","size":1794,"stargazers_count":74,"open_issues_count":2,"forks_count":14,"subscribers_count":5,"default_branch":"main","last_synced_at":"2026-04-21T16:04:02.902Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/StefaE.png","metadata":{"files":{"readme":"docs/README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2020-12-31T17:18:04.000Z","updated_at":"2026-04-10T11:56:40.000Z","dependencies_parsed_at":"2023-02-18T05:01:07.493Z","dependency_job_id":"32a237e2-1e35-4c15-9817-ef60d85677f8","html_url":"https://github.com/StefaE/PVForecast","commit_stats":null,"previous_names":[],"tags_count":12,"template":false,"template_full_name":null,"purl":"pkg:github/StefaE/PVForecast","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StefaE%2FPVForecast","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StefaE%2FPVForecast/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StefaE%2FPVForecast/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StefaE%2FPVForecast/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/StefaE","download_url":"https://codeload.github.com/StefaE/PVForecast/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StefaE%2FPVForecast/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":32441428,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-29T18:12:22.909Z","status":"ssl_error","status_checked_at":"2026-04-29T18:11:33.322Z","response_time":110,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"owner":null,"packages":[],"commits":{"id":11689592,"full_name":"stefae/pvforecast","default_branch":"master","total_commits":83,"total_committers":4,"total_bot_commits":0,"total_bot_committers":0,"mean_commits":20.75,"dds":0.08433734939759041,"past_year_total_commits":0,"past_year_total_committers":0,"past_year_total_bot_commits":0,"past_year_total_bot_committers":0,"past_year_mean_commits":0.0,"past_year_dds":0.0,"last_synced_at":"2026-04-27T19:01:08.072Z","last_synced_commit":"bf798af8aa87d40983d0681eeaec5427d9a1eaaf","created_at":"2026-03-20T00:01:30.259Z","updated_at":"2026-04-27T19:00:59.043Z","committers":[{"name":"Stefan_E","email":"se_misc@hotmail.com","login":"StefaE","count":76},{"name":"jesseklm","email":"jesseklm","login":"jesseklm","count":4},{"name":"Matze2","email":"12542802+Matze2","login":"Matze2","count":2},{"name":"Jakob Handke","email":"jakobhandke@icloud.com","login":"jhandke","count":1}],"past_year_committers":[],"commits_url":"https://commits.ecosyste.ms/api/v1/hosts/GitHub/repositories/stefae%2Fpvforecast/commits","host":{"name":"GitHub","url":"https://github.com","kind":"github","last_synced_at":"2026-04-29T00:00:10.453Z","repositories_count":6223003,"commits_count":899915120,"contributors_count":34898902,"owners_count":1147513,"icon_url":"https://github.com/github.png","host_url":"https://commits.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://commits.ecosyste.ms/api/v1/hosts/GitHub/repositories"}},"issues_stats":{"full_name":"StefaE/PVForecast","html_url":"https://github.com/StefaE/PVForecast","last_synced_at":"2026-04-25T18:01:42.694Z","status":"error","issues_count":4,"pull_requests_count":4,"avg_time_to_close_issue":314042.0,"avg_time_to_close_pull_request":3268508.75,"issues_closed_count":3,"pull_requests_closed_count":4,"pull_request_authors_count":4,"issue_authors_count":4,"avg_comments_per_issue":1.0,"avg_comments_per_pull_request":0.25,"merged_pull_requests_count":3,"bot_issues_count":0,"bot_pull_requests_count":0,"past_year_issues_count":0,"past_year_pull_requests_count":1,"past_year_avg_time_to_close_issue":null,"past_year_avg_time_to_close_pull_request":1296698.0,"past_year_issues_closed_count":0,"past_year_pull_requests_closed_count":1,"past_year_pull_request_authors_count":1,"past_year_issue_authors_count":0,"past_year_avg_comments_per_issue":null,"past_year_avg_comments_per_pull_request":0.0,"past_year_bot_issues_count":0,"past_year_bot_pull_requests_count":0,"past_year_merged_pull_requests_count":1,"created_at":"2025-08-30T23:42:24.207Z","updated_at":"2026-04-25T18:01:42.694Z","repository_url":"https://issues.ecosyste.ms/api/v1/hosts/GitHub/repositories/StefaE%2FPVForecast","issues_url":"https://issues.ecosyste.ms/api/v1/hosts/GitHub/repositories/StefaE%2FPVForecast/issues","issue_labels_count":{},"pull_request_labels_count":{},"issue_author_associations_count":{"NONE":3,"CONTRIBUTOR":1},"pull_request_author_associations_count":{"NONE":3,"CONTRIBUTOR":1},"issue_authors":{"Matze2":1,"fdzaebel":1,"christ0phd":1,"markusr":1},"pull_request_authors":{"jesseklm":1,"etofi":1,"Matze2":1,"jhandke":1},"host":{"name":"GitHub","url":"https://github.com","kind":"github","last_synced_at":"2026-04-27T00:00:06.950Z","repositories_count":14433773,"issues_count":34435239,"pull_requests_count":112697015,"authors_count":11247128,"icon_url":"https://github.com/github.png","host_url":"https://issues.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://issues.ecosyste.ms/api/v1/hosts/GitHub/repositories","owners_url":"https://issues.ecosyste.ms/api/v1/hosts/GitHub/owners","authors_url":"https://issues.ecosyste.ms/api/v1/hosts/GitHub/authors"},"past_year_issue_labels_count":{},"past_year_pull_request_labels_count":{},"past_year_issue_author_associations_count":{},"past_year_pull_request_author_associations_count":{},"past_year_issue_authors":{},"past_year_pull_request_authors":{},"maintainers":[],"active_maintainers":[]},"events":{"total":{"PullRequestEvent":5,"ForkEvent":1,"IssuesEvent":6,"WatchEvent":10,"IssueCommentEvent":9,"PushEvent":4},"last_year":{"IssuesEvent":1,"WatchEvent":4}},"keywords":[],"dependencies":[],"score":5.717027701406222,"created_at":"2026-03-20T00:01:03.730Z","updated_at":"2026-04-29T20:01:03.607Z","avatar_url":"https://github.com/StefaE.png","language":"Python","category":"Renewable Energy","sub_category":"Photovoltaics and Solar Energy","monthly_downloads":0,"total_dependent_repos":0,"total_dependent_packages":0,"readme":"---\ntitle: Users Guide\nlayout: template\norder: 4\nfilename: README\n---\n\n# PVForecast User's Guide\nA high level introduction to the project is given [here](https://stefae.github.io/PVForecast/). This _README_ file provides a full description of installation and configuration\n \n## Introduction\nAn extensive set of forecasts relevant to PV rooftop installations is supported:\n* production forecasts based on a number of providers (many users may focus on [Solcast](https://solcast.com/free-rooftop-solar-forecasting) for easy installation and excellent forecast quality)\n* \u003cspan style=\"color:#00B0F0\"\u003e\u003cb\u003eNew in v2.10:\u003c/b\u003e\u003c/span\u003e (for EU only)\n\t+ forecast of CO2 intensity of grid electricity consumed ([CO2signal](#co2signal-configuration) shows actual data for many areas of the world)\n\t+ auction prices of grid electricity\n* v2.11, v2.11.02, v2.11.03: bug fixes\n\n\u003cspan style=\"color:red\"\u003e\u003cb\u003eUpgrade Notice:\u003c/b\u003e\u003c/span\u003e incompatible changes - see [Version History](#version-history) for details\n* v2.11 sets default `apiCalls = 10` for [Solcast](#solcast-configuration) - legacy users with more credits need set `apiCalls` explicitly.\n* v2.10 requires pvlib v0.9.0 or higher (for **full version only**); small changes to `config.ini` keys and defaults, `SolcastLight` is deprecated (but still works)\n* v2.00 contains some incompatible changes (for the **full version** only) - . For users of the **light version**, there is no incentive to upgrade from v1.02/v1.03.\n\n-------------\n## Table of Content\n  - [Installation](#installation)\n    - [Setup](#setup)\n    - [Running the Script](#running-the-script)\n  - [Configuration](#configuration)\n    - [Sections](#sections)\n    - [Default Section](#default-section)\n  - [Configuring Data Sources](#configuring-data-sources)\n    - [Forecast Sources](#forecast-sources)\n    - [Solcast Configuration](#solcast-configuration)\n    - [VisualCrossing Configuration](#visualcrossing-configuration)\n    - [DWD configuration](#dwd-configuration)\n    - [OpenWeatherMap Configuration](#openweathermap-configuration)\n    - [Entso-E Configuration \u003cspan style=\"color:#00B0F0\"\u003e\u003cb\u003enew\u003c/b\u003e\u003c/span\u003e](#entso-e-configuration)\n    - [CO2signal Configuration \u003cspan style=\"color:#00B0F0\"\u003e\u003cb\u003enew\u003c/b\u003e\u003c/span\u003e](#co2signal-configuration)\n    - [FileInput Configuration](#fileinput-configuration)\n  - [Configuring PV Output Power Forecast Modelling](#configuring-pv-output-power-forecast-modelling)\n    - [Convert Weather Data to Irradiation Data](#convert-weather-data-to-irradiation-data)\n    - [Convert Irradiation Data to PV Output Power](#convert-irradiation-data-to-pv-output-power)\n      - [PVWatts Modelling](#pvwatts-modelling)\n      - [CEC Modelling](#cec-modelling)\n    - [Split Array System Configuration](#split-array-system-configuration)\n  - [Configuring Data Storage](#configuring-data-storage)\n    - [SQLite Storage](#sqlite-storage)\n    - [Influx Storage](#influx-storage)\n      - [Influx v2.x Storage](#influx-v2x-storage)\n      - [Influx v1.x Storage](#influx-v1x-storage)\n    - [.csv File Storage](#csv-file-storage)\n  - [Version History](#version-history)\n    - [Deprecations](#deprecations)\n  - [Acknowlegements](#acknowlegements)\n  - [License and Disclaimer](#license-and-disclaimer)\n\n-------------\n\n## Installation\n\n### Setup\n\nInstallation mainly ensures that all necessary python packages are available. We assume a Raspberry host here - although the instructions are probably quite generic. The scrip requires Python 3.8 or newer.\n\nRequired packages are described in [requirements.txt](https://github.com/StefaE/PVForecast/blob/main/requirements.txt). These packages can be installed manually (with `python -m pip install package)` or with `python -m pip install -r requirements.txt`. Referring to this file, which contains comments:\n* the first group of packages is required mandatorily\n* the `Influx` related packages are required if [Data Storage](#configuring-data-storage) to `Influx` (v1.8 or v2.x) is desired.\n* the last group of packages are the most difficult to install, but only required if corresponding functionality is needed:\n  + `pvlib` models [PV output power](#configuring-pv-output-power-forecast-modelling) and used for  [Forecast Sources](#forecast-sources) providing radiation data (`VisualCrossing`, `MOSMIX`, `OWM`) but **not** for `Solcast`\n  + `entso-py` is required only for [CO2 intensity forecast](#entso-e-configuration) (and easy to install)\n  \n[Influx](https://www.influxdata.com/products/influxdb/) must be installed separately. `SQLite` is supported natively by Python. However, an [SQLite browser](https://sqlitebrowser.org/) maybe useful.\n\nAdditional help for installation is in the [project wiki](https://github.com/StefaE/PVForecast/wiki).\n\n### Running the Script\n\nAfter downloading the script from Github, into a directory of your choosing (eg. `\\home\\pi\\PV`), you should have these files (and some more):\n```\n./PVForecasts.py\n./config.ini\n  |- ./PVForecast/*py\n  |- ./docs\n  |- ./emissionFactors\n  +- ./data\n./LICENSE\n```\n\n* update the config file (`config.ini`)\n* try it out ...: `python PVForecasts.py`\n* install it in `cron`, so that it runs in regular time intervals\n\nA typical `crontab` entry can look like so (assuming you have downloaded into `\\home\\pi\\PV`):\n```\n*/15 * * * * cd /home/pi/PV \u0026\u0026 /usr/bin/python3 PVForecasts.py \u003e\u003e /home/pi/PV/data/err.txt 2\u003e\u00261\n```\nwhich would run the script every 15min \n+ 15min interval is recommended due to the API call management provided for [Solcast](#solcast-configuration). For other data sources, the script handles larger calling intervals internally.\n+ when using `solcast_light_config.ini` it is recommended to rename this file to `config.ini`. Then we don't need the `-c` argument\n\nA great explanation of `cron` is from [crontab guru](https://crontab.guru/examples.html). Crontab entries are made with `crontab -e` and checked with `crontab -l`.\n\n**Note:** The script doesn't do much in terms of housekeeping (eg., limit size of SQLite database or `err.txt` file used above to redirect error messages).\n\n## Configuration\n`.\\config.ini` is a configuration file parsed with python's [configparser](https://docs.python.org/3/library/configparser.html). It consists of `Sections` and `key = value` pairs. Most importantly:\n* inline comments are configured to start with `#`\n* multi-line values are not allowed\n* out-commented `key = value` pairs in the provided `config.ini` template show the respective default options\n* the [template config.ini](https://github.com/StefaE/PVForecast/blob/main/config.ini) contains many useful comments, so should be read alongside this description\n* a few site specific values, which cannot be pre-configured. The are shown as `\u003cxx\u003e`.\n\n### Sections\n\nSection | Description |\n--------|-------------|\n`[Default]`\t| If a key-value pair is not found in a specific section, the corresponding value in the default section is used. |\n`[Forecasts]` | Forecasts to be run. If this section is missing, all forecasts for which a specific section exists is run |\nForecast configs | Each forecast source has its own section: _Solcast, VisualCrossing, DWD, OpenWeatherMap, Entso-E, CO2signal, FileInput_ |\n`[PVSystem]` | describes the PV system (for forecast sources which require modelling: _VisualCrossing, DVD, OpenWeatherMap_. For [split-array configurations](#split-array-system-configuration), additional sections can be created |\n`[DBRepo]` | configuration of [_SQLite_ storage](#sqlite-storage)\n`Influx]`  | configuration of [_Influx_ storage](#influx-storage)\n\n### Default Section\n\nThe following parameters are used by many forecast sources and hence typically placed into the `[Default]` section.\n\n```\n[DEFAULT]\n    # ----------------------------------------------------- Storage locations\n    storePath         = ./data/   # storage location for files (.csv, .kml, ..._ and SQLite database)\n    # following parameters could be overwritten for individual forecast providers\n    storeDB           = 0         # store to SQLite database (see [DBRepo] for name)\n    storeCSV          = 0         # store .csv files (mainly for debugging)\n    storeInflux       = 1         # store DC power output estimates in Influx (see [Influx] for name)\n    # dropWeather     = 1         # drop weather parameters irrelevant for PV forecasting for 'storeDB', 'storeCSV'\n    # force           = 0         # force downloading of new data\n\n    # ----------------------------------------------------- Location of PV system\n    Latitude          = \u003clatitude_of_your_system\u003e\n    Longitude         = \u003clongitude_of_your_system\u003e\n    # Altitude        = 0            # altitude of system (meters above sea level)\n```\n\nParameters `storeXX` all default to `0` (False), but at least one must be set to `1`.\nFor `dropWeather`, see [SQLite Storage](#sqlite-storage)\n`force` overwrites time-based blocking of downloading new data, if, for a data source, last data was downloaded not too long ago. Blocking time intervals are different per data source.\n\n## Configuring Data Sources\n\n### Forecast Sources\n\nSource | Description | Look-ahead |\n-------|-------------|------------|\n[Solcast](#solcast-configuration) | Solar forecast by [Solcast](https://solcast.com/) | Default 7 days |\n[VisualCrossing](#visualcrossing-configuration) | Weather and solar forecast from [VisualCrossing](https://www.visualcrossing.com/) | 15 days |\n[DWD](#dwd-configuration) | provided by [Deutscher Wetterdienst](https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/met_verfahren_mosmix.html) (primarily for Germany). Two flavours exist: | 10 days |\n_MOSMIX_L_ | single station forecast | \n_MOSMIX_S_ | all weather stations (will be downfiltered to single station after data download) | \n[OpenWeatherMap](#openweathermap-configuration) | Weather forecast from [OpenWeatherMap.org](https://openweathermap.org/) with approx. 10 parameters. Cloud coverage is used for PV output power forecast | 2 days |\n[Entso-E](#entso-e-configuration) | CO2 intensity for grid power, Electricity auction prices (EU only, based on data from [Entsoe Transparency Platform](https://transparency.entsoe.eu/)) | ~1 day |\n[CO2signal](#co2signal-configuration) | actual CO2 intensity for grid power, provided by [Electricity Maps](https://www.electricitymaps.com/) | na |\n\n_VisualCrossing, DWD_ and _OpenWeatherMap_ need modeling as described [below](#configuring-pv-output-power-forecast-modelling)\n\nDepending on the data source, various forecast algorithms are available. The configuration happens in the respective sections described below.\n\n### Solcast Configuration\n```\n[SolCast]\n    resource_id       = \u003cresource_id_from_solcast.com\u003e\n    # resource_id_2   = \u003csecond_resource_id_from_solcast.com\u003e\n    api_key           = \u003capi_id_from_solcast.com\u003e\n    # interval        =   0       # interval at which Solcast is read (during daylight only)\n    # hours           = 168       # forecast period defaults to 7 days, up to 14 days (336h)\n    # apiCalls        =  10       # number of API calls supported by Solcast (new default in v2.11.00)  \n```\n\n[Solcast](https://solcast.com/free-rooftop-solar-forecasting) allows for the free registration of a residential rooftop PV installation of up to 1MWp and allows for up to 10 API calls/day (legacy users may benefit from more credits and can set their entitlement with `apiCalls`). Note that _split array_ configurations require one credit per array - hence essentially reducing the calls to 5/day.\n\n_Solcast_ is considering to provide more calls as a paid service to hobbyists - [this questionaire](https://docs.google.com/forms/d/e/1FAIpQLSefZqRZ9z2f9pjl4Tc3zpscPVSBzhsPbErdyAwzui2xXqRz4A/viewform?usp=sf_link) helps them establish the market acceptance - hence, if you are interested, please fill in the form.\n\nThe registration process provides a 12-digit _resource_id_ (`xxxx-xxxx-xxxx-xxxx`) and a 32 character API key. _Solcast_ also supports [dual array systems](https://articles.solcast.com.au/en/articles/2887438-how-do-i-create-a-multiple-azimuth-rooftop-solar-site) (eg., east/west) through a second `resource_id_2`.\n\n_Solcast_ directly provides a PV forecasts (in kW) for 30min intervals, with 10% and 90% confidence level. Hence, no further modelling is needed. Forecasts are [updated every 15min](https://solcast.com/live-and-forecast) (for Eurasia), but it is recommended to call _Solcast_ no more than every 30min.\n\nTo stay within the limits of `apiCalls` per day, the script calls the API only between sunrise and sunset, except in the `24h` configuration below. It can further manage the calling interval to the API automatically or explicitly through the value assigned to `interval`:\n\nvalue | meaning\n------|---------\n0     | **Default**: call API every 15min (single array) or 30min (dual-array). To not exceed maximum API calls, extend interval to 30min (60min) after sunrise and before sunset on long days. Hence, this provides most accurate (short-term) forecasts during mid-day.\nearly | same as `0`, but all interval extensions are done before sunset only. Hence, this provides most accurate forecasts in the morning (this is not useful for `apiCalls \u003c 25`)\nlate  | same as `0`, but all interval extensions are done after sunrise only. Hence, this provides most accurate forecasts in the afternoon (this is not useful for `apiCalls \u003c 25`)\n24h   | downloads over the full day, but intervals are longer than in the previous configuration\nnumber | a positive number (eg. 15, 30, 60, ...) ensures that the API is not called more frequently than the stated number of minutes. It is the users responsability to stay within the limits of `apiCalls` supported by _Solcast_\n\nThere is obviously an interaction between the `interval` settings and the `crontab` entry used to run the script (see [above](#running-the-script)). It is suggested to configure `crontab` to run the script every 30min (for `apiCalls \u003e=25`, every 15min is possible). The interested user can use the script `./debug/solcast_timeInterval.py` to learn how download intervals are calculated - self-study is required).\n\nParameters `Latitude` and `Longitude` are only used to calculate daylight time. Defaults are for Frankfurt, Germany. (The _Solcast_ service has it's own location information, associated with the `api_key`.)\n\n`hours` defines the forecast period and defaults to 168h, but can be extended up to 14 days (336h)\n\n### VisualCrossing Configuration\n```\n[VisualCrossing]\n    api_key           = \u003capi_id_from_visualcrossing.com\u003e\n    # Irradiance      = disc        # default irradiation model\n```\n[VisualCrossing](https://www.visualcrossing.com/weather-data-editions) offers free access to their API to regularly download weather forecasts. The registration process provides a 25 character API key.\n\nThe [Weather Timeline API](https://www.visualcrossing.com/resources/documentation/weather-api/timeline-weather-api/) provides a 15-day forecast of approx. 18 parameters, including _solarradiation_ (or GHI). This can be converted to a PV output power forecast (see [Forecast Models](#configuring-pv-output-power-forecast-modelling)). The modelling strategy is controlled with the `Irradiance` parameter as described below.\n\n`dropWeather`, `Latitude` and `Longitude` are typically provided in `[Default]` section.\n\n### DWD configuration\n\n[Deutscher Wetterdienst (DWD)](https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/met_verfahren_mosmix.html) supports two (file based) interfaces (without the requirement of authentication):\n* `MOSMIX_L`: single weather station forecast, updated four times per day and approx. 115 weather parameters\n* `MOSMIX_S`: all MOSMIX weather stations, updated hourly, containing approx. 40 weather parameters\n\nAlthough both interfaces are supported, it is strongly suggested to use `MOSMIX_L`, since `MOSMIX_S` causes a download volume of ~1GByte/day without improving the forecast quality (despite the shorter update interval). `MOSMIX_S` can only be called from the [Forecast](#sections) section and downloaded data is immediatly downfiltered to the selected `DWDStation`.\n\n```\n[DWD]\n    DWDStation        = \u003cstation_number\u003e    # Station number\n    # DWD_URL_L       = https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/\n    # DWD_URL_S       = https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/\n    # Irradiance      = disc    # default irradiation model\n    # storeKMZ        = 0       # store downloaded .kmz files (.kml compressed as .zip)\n    # keepKMZ_S       = 0       # keep MOSMIX_S original file after downloading - note that these are many big files!\n```\n\nValid `DWDStation` values are defined on the [MOSMIX website](https://wettwarn.de/mosmix/mosmix.html)\n\n`storeKMZ`: The files downloaded are named `*.kmz` which is inadequate in two ways: First, the files are simple `.zip` files (so, why are they not called that way?) and second, a `.zip` file is meant to contain multiple files, which clearly the `.kmz` files never do. Hence, with `storeKMZ = 1`, downloaded data is stored in the more adequate `.gz` format. For _MOSMIX_L_, the downloaded files for the selected station are stored. For _MOSMIX_S_, an extract for the selected station is stored in a self-contained compressed `.xml` file. That format is very similar to _MOSMIX_L_ files.\n\n`keepKMZ_S`: in case of downloading the (huge) _MOSMIX_S_ file, they can be stored by enabling this option. \n\nThe modelling strategy used to convert weather data to irradiance is controlled with the `Irradiance` parameter as described in the next section. Not all MOSMIX stations support irradiance data (inconveniently labeled `Rad1h`). If the chosen station does not have it, irradiance based models won't work, but cloud-based models still do.\n\n`dropWeather` is typically provided in `[Default]` section.\n\n### OpenWeatherMap Configuration\n\n```\n[OpenWeatherMap]\n    api_key           = \u003capi_id_from_openweathermap.org\u003e\n    # Irradiance      = clearsky_scaling    # default irradiation model\n```\n\n[OpenWeatherMap](https://openweathermap.org/price) offers free access to their API to regularly download weather forecasts. The registration process provides a 32 character API key.\n\nThe weather forecast consists of approx. 10 parameters, including cloud coverage, which can be modelled to a PV forecast (see [Forecast Models](#configuring-pv-output-power-forecast-modelling)). The modelling strategy is controlled with the `Irradiance` parameter as described below.\n\n`dropWeather`, `Latitude` and `Longitude` are typically provided in `[Default]` section.\n\n### Entso-E Configuration\n\n\u003cspan style=\"color:#00B0F0\"\u003e\u003cb\u003enew\u003c/b\u003e\u003c/span\u003e - this works only for EU area. A detained introduction to the ideas behind this is given on a separate [CO2 Intensity](CO2Intensity) page\n\n[Entso-E](https://www.entsoe.eu/), the _European Network of Transmission System Operators for Electricity_, operates the [EU Transparency Platform](https://transparency.entsoe.eu/dashboard/show) with the goal to promote transparency goals to stakeholders.\n\n```\n[Entso-E]\n    api_key             = \u003capi_from_Entso-E\u003e\n    zones               = DE, DE_AMPRION                       # comma separated list of zones to be analyzed\n    # resolution        = 60T                                  # some countries offer bidding prices for different time intervals, typically 15T and 60T\n    # verbose           = 0                                    # verbosity level: 0=default, 1=basic, 2=max; forced =2 if start/end date are given\n    # keepRaw           = 0                                    # default 0, together with start/end can be used to dump Entso-E data to .csv\n    # start             = 2023-01-01T23:00Z                    # - see User's Guid\n    # end               = 2023-02-18T23:00Z                    # -\n    # loop              = 0                                    # -\n```\n\nAn `api_key` can be requested as described in the [User's Guide, chapter 2](https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html#_authentication_and_authorisation).\n\nData can then be downloaded for a comma separated list of `zones`. Depending on selected zone(s), different data is available and calculated. A list of zones - and available data per zone - is [here](https://github.com/StefaE/PVForecast/docs/EntsoE_Zones.pdf). For more details, refer to the [CO2 Intensity](CO2Intensity) page, where also the other parameters are explained.\n\nTo get accurate data, a rolling linear correlation fit between forecasts and actuals is used. Due to this, the system needs to run for a couple of days before accurate forecasts are achieved.\n\n### CO2signal Configuration\n\n\u003cspan style=\"color:#00B0F0\"\u003e\u003cb\u003enew\u003c/b\u003e\u003c/span\u003e - A detained introduction to the ideas behind this is given on a separate [CO2 Intensity](CO2Intensity) page\n\n```\n[CO2signal]\n    api_key             = \u003capi_from_www.co2signal.com\u003e\n    zones               = DE      # comma separated list of zones to be downloaded\n```\n\n[ElectricityMaps](https://www.electricitymaps.com/) generate CO2 intensity data for many regions of the world. A free API is available at [CO2signal](https://www.co2signal.com/), which provides hourly data of the CO2 footprint of grid electricity (there is no forecast available), where a free `api_key` can be registered.\n\n`zones` is a comma-separated list of zones to be downloaded, from a list of [supported zones](https://api.electricitymap.org/v3/zones).\n\n### FileInput Configuration\n\n```\n[FileInput]\n    ...\n```\nThis forecast source is for mainly for debugging purposes and allows to read `.kmz` or `.csv` files with weather data. Refer to comments in sample `config.ini` file and source code `ForecastManager.processFileInput` for further guidance.\n\n## Configuring PV Output Power Forecast Modelling\n\u003ca href=\"https://pvlib-python.readthedocs.io/en/stable/\"\u003e\n   \u003cimg style=\"margin-left:0\" src=\"pictures/pvlib_powered_logo_horiz.png\"\u003e\n\u003c/a\u003e\n\nData from all PV output power related data sources (except [Solcast](#solcast-configuration)) do not directly contain PV output power. This needs be modelled using functionality provided by [pvlib](https://pvlib-python.readthedocs.io/en/stable/). \n\nEssentially, the modelling consists of a two-step approach:\n1. convert weather data to irradiation data (_GHI, DNI, DHI_). Multiple conversion strategies are available and controlled with the `Irradiance` parameter in the config section for `[VisualCrossing]`, `[DWD]` and `[OpenWeatherMap]` respectively.\n\n2. convert such irradiation data into PV output power. This is controlled in the config section `[PVSystem]`\n\n### Convert Weather Data to Irradiation Data\n\nModel | Input parameter | Applicable to | Comment\n------|-----------------|---------------|--------\n[disc](https://pvlib-python.readthedocs.io/en/stable/reference/generated/pvlib.irradiance.disc.html)  | `GHI`     | MOSMIX (*), VisualCrossing | default if GHI available\n[dirint](https://pvlib-python.readthedocs.io/en/stable/reference/generated/pvlib.irradiance.dirint.html) | `GHI` | MOSMIX (*), VisualCrossing | \n[dirindex](https://pvlib-python.readthedocs.io/en/stable/reference/generated/pvlib.irradiance.dirindex.html) | `GHI` | MOSMIX (*), VisualCrossing | some numerical instabilities at very low values of GHI\n[erbs](https://pvlib-python.readthedocs.io/en/stable/reference/generated/pvlib.irradiance.erbs.html) | `GHI` | MOSMIX (*), VisualCrossing | \n[campbell_norman](https://pvlib-python.readthedocs.io/en/stable/reference/generated/pvlib.irradiance.campbell_norman.html) | `clouds` | OWM, MOSMIX | \n[clearsky_scaling](https://pvlib-python.readthedocs.io/en/stable/reference/generated/pvlib.forecast.ForecastModel.cloud_cover_to_irradiance_clearsky_scaling.html) | `clouds` | OWM, MOSMIX | default if GHI not available, \n[clearsky](https://pvlib-python.readthedocs.io/en/stable/reference/generated/pvlib.location.Location.get_clearsky.html) | NA | all (except Solcast), output agnostic to weather forecast | clear sky estimation of PV output power; uses `simplified_solis`\nall | NA | NA | calculate all applicable models for provided weather data\n\n(*) not all MOSMIX stations provide GHI data\n\nWhere needed, `DHI` is calculated from `GHI` and `DNI` using the fundamental equation `DNI = (GHI - DHI)/cos(Z)` where `Z` is the solar zenith angle (see eg. [Best Practices Handbook](https://www.nrel.gov/docs/fy15osti/63112.pdf)). Weather parameters considered in above models include:\n\nParameter | VisualCrossing | MOSMIX | OpenWeatherMap | unit\n---------|-----------------|--------|-----|------\nghi      | solarradiation | Rad1h | - | W/m\u003csup\u003e2\u003c/sup\u003e\ntemp_air | temp | TTT | temp | K\ntemp_dew | dew | Td | dew_point | K\nwind_speed | windspeed | FF | wind_speed | m/s\npressure  | pressure | PPPP | pressure | Pa\nclouds   | cloudcover | Neff | clouds | 0 .. 100\n\nWhere needed, unit conversion and parameter renaming is performed. `Parameter` correspond to same-named `pvlib` parameters and are stored in the [SQLite Storage](#sqlite-storage), if enabled.\n\nMOSMIX `Rad1h` is (according to DWD customer service) the integrated radiation over the last hour prior to the forecast time stamp. For VisualCrossing, the [documentation](https://www.visualcrossing.com/resources/documentation/weather-api/timeline-weather-api/) states that `solarradiation` is the power _at the instantaneous moment of the forecast_. Hence, it probably best reflects the average radiation for a period beginning 30min before and ending 30min after the forecast timestamp. To account for this, the forecast time stamp `period_end` is corrected by +30min (which is then slightly misleading for the secondary weather parameters reported) once it gets [written out](#configuring-data-storage)\n\n### Convert Irradiation Data to PV Output Power\nIn this section, we first describe how to model a single array PV System. The software also supports the configuration of split array systems. The necessary extensions are described in the next section.\n\n[pvlib](https://pvlib-python.readthedocs.io/en/stable/index.html) supports two modelling strategies for a PV system:\n* simplified `PVWatts` model\n* model system with actual component parameters based on a `CEC` database provided with pvlib\n\nBoth approaches are supported and selected based on `Model`, but `PVWatts` is simpler to configure:\n\n#### PVWatts Modelling\n```\n[PVSystem]\n    # Model            = PVWatts  # modeling strategy for PV: 'CEC' or 'PVWatts' \n    # TemperatureModel = open_rack_glass_glass\n    # clearsky_model   = simplified_solis\n    \n    # --------------------------- PVWatts definition\n    InverterPower     = 10000     # name-plate inverter max. power\n    NominalEfficiency = 0.965     # nominal European inverter efficiency\n    SystemPower       =  9750     # system power [Wp]\n    TemperatureCoeff  = -0.0036   # temperature coefficient (efficiency loss per 1C)\n```\n\nThe `PVWatts` model considers considerably less inefficiencies (~2.5%) than [PVWatts defaults](https://pvlib-python.readthedocs.io/en/stable/reference/pv_modeling/generated/pvlib.pvsystem.pvwatts_losses.html) (~14%):\n\n#### CEC Modelling\n\nTo use actual PV system component data, the `CEC` model must be used instead:\n\n```\n[PVSystem]\n    Model            = CEC        # modeling strategy for PV: 'CEC' or 'PVWatts' \n    # TemperatureModel = open_rack_glass_glass\n    # clearsky_model   = simplified_solis\n    \n    # --------------------------- physical definition of PV System, using CEC database\n    # based on .csv files at .../pvlib/data, special characters to be replaced by '_'\n    ModuleName        = LG_Electronics_Inc__LG325N1W_V5\n    InverterName      = SMA_America__SB10000TL_US__240V_\n    NumStrings        =   2       # number of strings \n    NumPanels         =  15       # number of panels per string\n```\n\nThe location of the `pvlib` library can be determined with `python -m pip show pvlib`. The two `.csv` files `sam-library-cec-inverters-2019-03-05.csv` and `sam-library-cec-modules-2019-03-05.csv` list inverters and modules respectively. The first column contain the names of supported inverters and modules. Special characters and blanks need replaced with `_` in the config file. Hence, eg. `SMA America: SB10000TL-US [240V]` becomes `SMA_America__SB10000TL_US__240V_`\n\nThe selected model should at a minimum match the nameplate power of the installed panels (eg. 325Wp). The selected inverter is uncritical as long as the nameplate power is same or higher as installed inverter (eg. 10kW) - the modeling of inverters is relatively poor in pvlib, considering only a _NominalEfficency_.\n\n`pvlib` models panel temperature (and related efficiency loss) based on `TemperatureModel` and weather parameter `temp_air`. `clearsky_model` is used for irradiation model `clearsky`. `ineichen` and `simplified_solis` are supported, `haurwitz` is not.\n\nBoth models also need basic parameters of the system location and orientation:\n```\n    # Latitude, Longitude, Altitude required, but typically taken from [Default] section\n    Tilt              =  30\n    Azimuth           = 127       # 270=West, 180=South, 90=East\n```\n\n### Split Array System Configuration\nThe above allows the definition of a _single array_ PV system. Split array systems (eg. with a west and east looking set of panels) can be configured as follows:\n```\n[PVSystem]\n    # define one array as explained in previous section\n    # additionally, following two parameters are supported:\n    suffix     = West             # value = name of this array; default '1'\n    storage    = both             # legal values: individual, both, sum (default)\n\n[PVSystem_East]\n    # define settings applicable to this array\n\n[PVSystem_South]\n    # define settings applicable to this array\n```\nThere is no limit to the number of splits that can be defined.\n\nNames of the sub-arrays are arbitrary - anything after the `_` serves as a suffix (here eg. `East`, `South`). Since the first section does not contain such a name (the section is strictly named `[PVSystem]`) a suffix can be provided separately (eg. `West`)\n\nThe secondary arrays (`[PVSystem_East]`, `[PVSystem_South]`, ...) inherit all settings from `[PVSystem]` except those which are explicitly overwritten. Typically, one wants to overwrite at least `Azimuth` and `Tilt`, likely also `NumStrings`, `NumPanels` and possibly panel types.\n\nPV output is calculated for each sub-array and creates parameters `dc_\u003cirradiation_model\u003e_\u003csuffix\u003e` and `ac_\u003cirradiation_model\u003e_\u003csuffix\u003e`. Parameters are added as columns to the same table a single-array PV system would have created. The parameter `storage` controls what is handed to the [data storage](#configuring-data-storage) module. Valid values are:\n\nValue | Function\n------|---------\nsum | **default**: only sum of all sub-arrays is stored (as `dc_/ac_\u003cirradiation_model\u003e`)\nindividual | only the individual sub-array results are stored, but sum is not calculated\nboth | individual results and sum are stored\n\n## Configuring Data Storage\nForecasting PV output power would be pointless, if the resulting data wouldn't be stored anywhere. The application supports three storage models:\n1. SQLite (file based relational database)\n2. Influx\n3. csv files\n\nThe following configuration parameters control what is stored where and can be configured separately for each forecast provider or, more commonly, in section `[Default]` (0 = disable, 1 = enable)\n\nParameter | Function \n----------|----------\nstoreDB   | enable SQLite storage \nstoreInflux | enable Influx storage \nstoreCSV  | enable CSV file storage\nstorePath | storage location of SQlite database and other files stored\n\nDatabases and tables are created dynamically. \n* Tables are named per forecast data source. \n* For [DWD](#dwd-configuration), table `dwd` contains data from `MOSMIX_L` and `dwd_s` from `MOSMIX_S`\n* [Entso-E](#entso-e-configuration) and [CO2signal](#co2signal-configuration) create a table for each zone, `entso_\u003czone\u003e` and `co2signal_\u003czone\u003e` respectively.\n\n_Influx_ stores a reduced set of data, aimed at displaying forecast data in a dashboard or similar. _SQLite_ is tailored to build a data repository useful for deeper analysis and learning.\n\nAll times stored or reported are in UTC. All period time stamps are aligned to show the _periodEnd_. Hence, at times, data appears to be mis-aligned with directly downloaded data from the data source. This is because some sources report period timestamps as _periodStart_.\n\n### SQLite Storage\n```\n[DBRepo]\n    dbName  = pvforecasts.db      # SQLite database name (at 'storePath')\n```\nAn SQLite database is dynamically created with above defined name at `storePath` with name `dbName`. It is sufficient to remove the database to cause a re-creation of a fresh database. If the configuration is changed on an existing data, new tables are added dynamically. Fields which no longer exist are left empty. But new fields are _not_ added dynamically.\n\nThe following features are only available in _SQLite_ storage:\n* All tables except `solcast` contain the minimum set of weather parameters as tabled [above](#convert-weather-data-to-irradiation-data). In addition, for each [irradiation model](#convert-irradiation-data-to-pv-output-power) enabled, GHI, DHI and DNI are stored alongside estimated PV ac and dc output power. These parameters may be multiplied depending on [split-array system configurations](#split-array-system-configuration) used.\n\n* If the configuration parameter `dropWeather` is disabled (set to `0`), all (other) weather parameters of the forecast source are also stored, with their original names and units. By default (`dropWeather = 1`) only the [used parameters](#convert-weather-data-to-irradiation-data) are stored\n\n* All tables contain `IssueTime` (when forecast was issued) and `PeriodEnd` (end time of forecast period). Date from previous `IssueTime` are not deleted to allow analysis of accuracy of forecasts over different forecast horizons. This makes the database grow quickly however!\n\n### Influx Storage\n\n_Influx_ contains a reduced set of data, compared to _SQLite_:\n\n* the last forecast overwrites any older forecast for a certain forecast time. That is, the _Influx_ database always contains the _current best knowledge_ about the forecasted parameter.\n* For modelled PV output power forecasts only contains DC power estimates, named `dc_\u003cmodel\u003e` for the [irradiance](#convert-weather-data-to-irradiation-data) model(s) calculated\n\n[Influx](https://www.influxdata.com/products/influxdb/) has undergone a major, largely not backward compatible upgrade between version 1.x and 2.x. However, both version are supported (though not in parallel). _Influx 1.x_ is out of maintenance since 2021. Hence, for new installations, it is suggested to move to _Influx 2.6_ or newer. Influx 3.x is not supported however.\n\n#### Influx v2.x Storage\nInstead of Influx v1.x storage, Influx v2.x can be used. For this to work, the config file section must adhere to the following:\n```\n[Influx]\n    influx_V2       = 1              # enable Influx 2.x support (default is to use 1.x)\n    token           = \u003cyour token\u003e\n    org             = \u003cyour org\u003e\n    bucket          = \u003cyour bucket\u003e  # fall-back: use key `database`\n```\n\n_Tables_ are called _buckets_ but largely serve the same purpose.\nNote that in Influx 2.x token based authentication is mandatory. Tokens can be [generated](https://docs.influxdata.com/influxdb/cloud/security/tokens/create-token/) in the Influx GUI.\n\n#### Influx v1.x Storage\n```\n[Influx]\n    host              = \u003cyour_hostname\u003e         # default: localhost\n    # port            = 8086\n    ssl               = 0\n    verify_ssl        = 0\n    database          = \u003cyour_influx_db_name\u003e\n    # username        = root\n    # password        = root\n    # retention       = None                    # retention policy   \n```\n\n_Tables_ are called _measurements_ but serve the same purpose.\n\nIf authentication is required, optional `username` and `password` can be provided in the `[Influx]` config section. Default is `root` / `root` (as is the default for Influx 1.x). Authentication is *not* SSL encrypted though.\n\nIf the database is configured to support multiple retention policies, one for the _PVForecast_ data can be selected with `retention`. \n\n### .csv File Storage\n`storeCSV = 1` store output in .csv files at `storePath`. This is mainly for debugging. \n\n_Solcast_ can only store to csv files if at least one other storage model (SQlite, Influx) is enabled.\n\n\n\n## Version History\n**v2.11.04**    2024-01-21\n+ Bug fix: Solcast _next download_ message corrected for `interval = 24h`\n+ changes spelling in documentation from _SolCast_ to _Solcast_ (**Note**: `config.ini` section remains `[SolCast]`)\n+ added [link](#solcast-configuration) to questionaire by _Solcast_ on paied service\n\n**v2.11.03**    2023-12-28\nBug fixes\n+ Deprecation warnings for pandas 2.x resolved ([issue #26](https://github.com/StefaE/PVForecast/issues/26))\n+ Improved behavior in case of runtime issues - search log file for 'Error' and 'Warning' to get them all\n+ Solcast now reports when next download is planned\n\n**v2.11.02**    2023-08-06\nBug fixes\n+ proper version checking of pvlib (`pip install packaging` might be needed) \n+ moved `pvlib` code for `cloud_to_irradiance` to pvmodel.py (pvlib deprecated [pvlib.forecast](https://pvlib-python.readthedocs.io/en/stable/whatsnew.html?highlight=history#v0-10-0-june-30-2023))\n+ suppressed warnings in `pvlib` related to np.exp overflow\n+ v2.11.01 recalled - fix was insufficient\n\n**v2.11.00**    2023-04-21\nBug fixes\n+ Solcast interval calculation fixed for low number of `apiCalls`\n+ avoid exit, if some forcast providers cause errors (eg. _too many API calls_) - allow continuation with next forecast provider\n+ other bug fixes\n\n_Compatibility notes on v2.11.00_\n\n_Solcast_ has changed number of allowed `apiCalls` per day to 10, but it appears that legacy users still can use their previous entitlements. The default value for `apiCalls` has changed, so that legacy users now need explicitly set their entitlement value.\n\n**v2.10.00**    2023-02-28\n\nIf you plan to continue using only _SolcastLight_, there is no reason to update - but you miss out on the new capabilities on CO2 intensity forecast\n+ [CO2 intensity forecast](CO2Intensity) added, see [Entso-E](#entso-e-configuration) and [CO2signal](#co2signal-configuration)\n+ _Solcast_ interval can now be configured to `24h` - see [Solcast Configuration](#solcast-configuration). This solves [issue #15](https://github.com/StefaE/PVForecast/issues/15)\n+ Installation simplified - if some libraries are not installed, _PVForecast_ behaves gracefully and only disables functionality which cannot be maintained. See [Installation](#installation)\n+ it is no longer required to create Influx databases manually upfront\n+ documentation (including [pages](https://stefae.github.io/PVForecast/)) reworked\n+ bug fixes\n\n_Compatibility notes on v2.10.00_\n\n+ `[Forecasts]` key `OWM` has been renamed to `OpenWeatherMap` for consistency reasons\n+ default model changed from `CEC` to `PVWatts`, see [Convert Irradiation Data to PV Output Power](#convert-irradiation-data-to-pv-output-power)\n\n**v2.01.00**    2022-12-03\n+ solves [issue #14](https://github.com/StefaE/PVForecast/issues/14): [Solcast](#solcast-configuration) defaults to 48h, but accepts an `hours` parameter.\n+ Upgrade notice: for this to work, `pysolcast` version needs be v1.0.2 or higher\n\n**v2.00.00**    2022-07-24\n+ added [VisualCrossing](#visualcrossing-configuration) as new forecast source\n+ added [File Input](#fileinput-configuration) as new forecast source, to simplify debugging\n+ [MOSMIX](#dwd-configuration) cloud based models use parameter `Neff` (effective cloud coverage) instead of `N` (cloud coverage) for slightly improved accuracy.\n+ default [Irradiation model](#convert-weather-data-to-irradiation-data) changed from `all` to `disc` (`clearsky_scaling` for cloud data)\n+ documentation improved\n+ code refactoring: weather parameters are now renamed and converted to standard units in the respective source objects rather than `PVModel`\n\n_Compatibility notes on v2.00.00_\n\nThere are no changes if you are using _SolcastLight_ and hence, there is no reason to update. However, if the full version is used, the following changes apply:\n+ changes to [Influx Storage](#influx-v1x-storage): Cloud based forecast fields have new (shorter) names. Influx will transparently add new fields, but long-term trends will get broken.\n+ changes to [SQLite Storage](#sqlite-storage):\n  + tables `dwd` and `pvsystem` are consolidated into `dwd`. Likewise, tables `dwd_s` and `pvsystem_s` are consolidated into `dwd_s`\n  + weather data in tables `dwd`, `owm` and `visualcrossing` have standard names and units as documented [above](#convert-irradiation-data-to-pv-output-power)\n  + other weather parameters are only stored if `dropWeather = 0` for the respective data source\n\nAs a consequence, if the [SQLite Storage](#sqlite-storage) model is used, the pre-existing database (referenced by `DBRepo.dbName`) has to be deleted, so that a new version, with new tables and fields, will automatically be re-created on first execution of the script.\n\n**v1.03.00**\n+ updated readme file, fixing some documentation bugs\n\n**v1.02.00**\n+ [Influx 1.x](#influx-v1x-storage) now supports authentication\n+ small bug fixes\n\n**v1.01.00**    2021-03-28\n+ Solcast:\n  - [Solcast](#solcast-configuration) default `interval` management to make optimal use of permitted 50 API calls/day\n  - [split array support](#split-array-system-configuration) for MOSMIX and OWM (Solcast supports two arrays only)\n- [Influx v2.x](#influx-v2x-storage) support\n- [storeCSV](#csv-file-storage) now enabled for all data sources\n- various bug fixes, documentation improvement\n\nv1.00.00    2021-02-06  initial public release\n\n### Deprecations\n* **Deprecated by Solcast**: Solcast previously allowed to post PV performance data to [tune forecast](https://articles.solcast.com.au/en/articles/2366323-pv-tuning-technology) to eg. local shadowing conditions, etc. \n\n* `SolcastLight` is deprecated (but still available). Use `python PVForecasts.py -c solcast_light_config.ini` instead\n\n## Acknowlegements\nThanks to all who raised issues or helped in testing!\n\n## License and Disclaimer\nDistributed under the terms of the [GNU General Public License v3](https://github.com/StefaE/PVForecast/blob/main/LICENSE)\n\nThe software pulls data from various weather sources. It is the users responsibility to adhere to the use conditions of these sources. \n\nThe author cannot provide any warranty concerning the availability, accessability or correctness of such weather data and/or the correct computation of derived data for any specific use case or purpose. Further warranty limitations are implied by the license\n","funding_links":[],"readme_doi_urls":[],"works":{},"citation_counts":{},"total_citations":0,"keywords_from_contributors":[],"project_url":"https://ost.ecosyste.ms/api/v1/projects/348937","html_url":"https://ost.ecosyste.ms/projects/348937"}