---
title: 'Gas Demand Forecast'
description: Daily gas consumption forecast for a metering node over the next 7, 30 and 90 days, with a 95% confidence interval and a 14-day accuracy check.
section: AI Analytics
weight: 5
related:
  - ai-analytics/node-reports/consumption-analytics
---

import Alert from '@/components/docs/Alert.astro';

This report works on **a single metering node**: it predicts how much gas the node will consume over the next 7, 30 and 90 days. It is used for procurement and balance planning — how much gas the consumer will need in the near term.

The forecast is built from the consumption history of past periods and accounts for the weather: in cold weather more gas goes to heating. Along with the forecast, the report provides a confidence interval (a "from–to" range that consumption will fall within with high probability) and an accuracy check on recent days.

## What it shows

| Block | What it means |
|---|---|
| Forecast chart | expected daily consumption going forward, overlaid on the actual history |
| Confidence interval | a corridor around the forecast within which consumption will land with 95 % probability |
| Totals for 7 / 30 / 90 days | how much gas is expected in total over these horizons |
| Accuracy check | how far the model was off over the last 14 days (see below) |

The forecast is decomposed into clear components: a baseline level, an overall trend (consumption rising or falling over time), seasonality (year and day of week), and the weather contribution.

## How it works

Data sources:

- **Gas consumption** — from the device's hourly archive, rolled up into daily totals.
- **Weather** — daily temperature from the open service open-meteo. The temperature history is taken by the node's coordinates; for the forecast dates — the actual weather forecast from the same service.

The model is a linear dependence of consumption on four factors:

1. **Trend** — slow rise or fall of consumption over time.
2. **Annual seasonality** — winter/summer.
3. **Weekly seasonality** — weekdays and weekends consume differently.
4. **Temperature** — via **heating degree-days**: how much colder the day is than 18 °C. The colder it is, the more gas goes to heating.

If weather is unavailable, the model works without the temperature factor. Abnormally large hourly values (telemetry artifacts) are clipped at the device's passport maximum, so as not to distort the forecast.

Accuracy is checked as follows: the model "does not see" the last 14 days, forecasts them, and compares with the actuals. From this come the average forecast error and the share of days on which the actual fell within the confidence interval.

## Run parameters

| Parameter | Default | What it means |
|---|---|---|
| Node # | required | the metering node number |
| History from | 2 years ago | start of the history (≥ 1 year required for annual seasonality) |
| History to | yesterday | end of the history |
| Horizon | 30 | how many days ahead to forecast |
| Backtest days | 14 | how many recent days to check accuracy on |
| Minimum hours per day | 18 | how many hours per day must have data for the day to be counted |
| Coordinates | node coordinates | location for the weather request |
| Heating base | 18 °C | temperature below which heating begins |
| Without weather | off | compute without accounting for weather |

## How to read the result

- Look first at the **accuracy check**. An average relative error up to 10 % — an excellent forecast; 10–20 % — acceptable; more than 20 % — trust with caution. The share of hits within the confidence interval is normally around 90–95 %.
- The **7-day horizon** is the most reliable; 90 days is indicative and requires at least a year of history. Beyond 90 days the forecast is not recommended.
- **The confidence interval matters more than a single figure:** plan against its upper bound if you need a margin.

<Alert type="warning" title="Limitations">
With less than half a year of history the model is simplified (without annual seasonality). The model does not detect outages and data gaps on its own — such days are better excluded manually, otherwise the forecast will be understated.
</Alert>