Weather

Weather

The controller can record what the sky was actually doing at each end of every charging session. It is optional, it is off unless you configure it, and — like Solcast — it is one of the few parts of this otherwise entirely local system that talks to the internet.

Do you need it?

Only if you want to analyse your charging sessions. Nothing in charge control reads any of it, so turning it on cannot change what the controller does to your car or your battery.

Without it	With it
Every mode works exactly as it does now. Sessions are recorded with no weather columns, which is also what every session recorded before this existed looks like.	Each session carries the conditions when it opened and when it closed, plus that day's sunrise and sunset.

The point is the question a recorded session cannot otherwise answer. The forecast curve on a session says what the sun was expected to do; without the weather, a session that under-delivered against a confident forecast has no explanation attached to it at all — cloud that rolled in, a cold morning and snow on the panels are indistinguishable afterwards.

Getting a key

1. Register at openweathermap.org. The free plan is enough. This makes two API calls per charging session — one when it opens, one when it closes — which is a handful a day.

2. Copy the API key from your account's API keys page. A new key can take up to a couple of hours to activate; until it does, calls answer 401.

3. Find your site's coordinates in decimal degrees. Any map will give them, or ask OpenWeatherMap itself:

curl "http://api.openweathermap.org/geo/1.0/direct?q=Brno,CZ&limit=1&appid=<your-key>"

Note

The free current-weather endpoint is what this uses, not One Call 3.0. One Call needs its own paid "One Call by Call" subscription and answers 401 without one — and every figure recorded here comes back from the free endpoint anyway. You do not need to subscribe to anything.

Configuring it

Non-secret settings live in appsettings.json. The API key never does.

"Weather": {
  "BaseUrl": "https://api.openweathermap.org/",
  "Latitude": null,             // your site, in decimal degrees
  "Longitude": null,
  "Units": "metric",            // °C and metres -- what the stored numbers mean
  "RequestTimeout": "00:00:05"  // a slow provider is abandoned, never waited for
}

In Docker, supply all three through the environment:

WEATHER_API_KEY=<your-api-key>
WEATHER_LATITUDE=49.267803
WEATHER_LONGITUDE=16.529486

# or directly, using the config-section convention
Weather__ApiKey=<your-api-key>
Weather__Latitude=49.267803
Weather__Longitude=16.529486

For local development, the same two routes as the Solcast key: a gitignored .env in the repo root, which the worker loads on startup so it works from both dotnet run and the debugger, or user-secrets.

cp .env.example .env
# then edit .env:  Weather__ApiKey=<your-api-key>

# or, using user-secrets
cd src/Gleanvolt.Worker
dotnet user-secrets set "Weather:ApiKey" "<your-api-key>"

Warning

Keep one .env per machine, not one per project directory. The worker loads the nearest .env at or above its content root and stops there. A second one deeper in the tree shadows the one above it, and the keys in the outer file then silently stop reaching the app.

Leave the key or either coordinate unset and the feature is simply off: no HTTP call is ever made and sessions are recorded without weather.

Note

The coordinates have no default on purpose. 0, 0 is a real place in the Atlantic, so an unset site would otherwise record the weather in the Gulf of Guinea rather than recording none.

What gets recorded

Twice per session — when it opens and when it closes:

Field
Temperature	°C
Pressure	hPa
Humidity	%
Cloud cover	% — the figure that explains a session more often than any other
Visibility	metres, capped at 10 km; empty when the provider didn't report it
Condition	Clear, Rain, Snow… and its longer description, light rain
Observed at	the time the provider stamped the reading, which is typically a few minutes old

And once per session, for the day it started on: sunrise and sunset. They belong to the day rather than to either reading, and they are the denominator behind "did this session use the day it had?" — the same delivered energy against nine hours of possible daylight or against sixteen is not the same result.

Two readings rather than one because a six-hour session can finish in entirely different weather from the one it started in, and only the pair can say so.

The session detail page shows both, e.g. clear sky, 19.6 °C, 5% cloud → light rain, 14.1 °C, 88% cloud, with the daylight window beneath it.

What happens when the internet is down

The fetch fails, one warning is logged, and the session is recorded without weather. Nothing waits: the closing call sits between a session ending and its totals being written, so it is abandoned after five seconds rather than delaying the record. A refused key, an exhausted quota, a DNS failure and an outage all behave the same way — one empty column, never a lost session.

---

Previous: Solcast · Next: Troubleshooting