Energy Communities

What are Energy Communities?

Energy communities are collaborative organizations where citizens, local businesses, and other stakeholders jointly invest in, produce, manage, and consume renewable energy. These communities represent a fundamental shift from centralized energy systems to decentralized, democratic energy management.

Key Characteristics

Local Energy Production and Consumption Members produce renewable energy (typically solar, wind, or hydroelectric) and share it within the community. Energy is consumed where it's produced, reducing transmission losses and grid dependency.

Collective Ownership Community members collectively own or lease energy generation assets. Democratic decision-making ensures all members have a voice in community operations.

Energy Sharing Surplus energy from one member can be shared with others in the community. This creates a local energy market with optimized distribution based on real-time supply and demand.

Grid Independence While still connected to the main grid for backup, communities aim to maximize self-sufficiency. Excess energy can be sold back to the grid, creating additional revenue streams.

Benefits

• Economic: Lower energy costs through collective bargaining and shared infrastructure
• Environmental: Increased renewable energy adoption and reduced carbon footprint
• Social: Strengthened community bonds and local economic development
• Resilience: Enhanced energy security and reduced dependency on external suppliers

Regulatory Framework

Energy communities operate within specific regulatory frameworks that vary by region. In the EU, they are recognized under the Clean Energy Package, which defines:

• Renewable Energy Communities (RECs)
• Citizen Energy Communities (CECs)

These frameworks establish rights for energy sharing, grid access, and fair treatment in the energy market.

Technical Requirements

Operating an energy community requires sophisticated data management for:

• Real-time energy production and consumption monitoring
• Member billing and settlement
• Grid interaction management
• Regulatory compliance reporting
• Asset performance tracking

This is where OctoMesh's Data Mesh technology provides the structured data foundation needed to manage these complex, interconnected systems effectively.

Solution Architecture with OctoMesh

System Overview

The OctoMesh platform serves as the central data hub for managing energy communities, integrating with external systems and providing user interfaces for different stakeholder groups.

Key Components

1. External Integrations

EDA Integration via Ponton X/P KEP

• Bidirectional communication with the energy data exchange platform
• EDIFACT/XML message processing
• Automated status and error message handling

Supported EDA processes

The EDA adapter implements the following market processes (process catalogue Marktprozesse 04p10, EDA config patch 3.7.29, valid from 5 October 2026). Each process is started through the adapter and its reply messages are handled by pipelines in the respective application.

Process	Version	Purpose
EC_REQ_ONL	03.00	Register a metering point with an energy community (online request)
EC_PODLIST	02.10	Request the list of metering points of an energy community
EC_PRTFACT_CHANGE	01.10	Change the participation factor of a metering point
CR_REQ_PT	04.30	Request consumption/production data for a metering point
CR_MSG	03.30	Receive consumption records (DATEN_CRMSG)
CM_REQ_ONL	01.50	Request a data sharing consent (online request)
CM_REV_CUS / CM_REV_IMP / CM_REV_SP	01.30 / 01.40 / 01.40	Revoke a data sharing consent
CM_PODLIST	01.00	Reconcile active and inactive data consents of a service provider with the grid operator

Market role restriction. According to the market role permission matrix, CM_PODLIST may only be used by the roles VNB and EDL (service provider for end consumers). It is therefore part of the service provider application and not of the energy community management application.

Changes with EDA config patch 3.7.29

• Only one schema changes: ECMPList 01.10 → 01.20. It is shared by EC_PODLIST, EC_PRT_CHANGE, EC_PRTFACT_CHANGE, EC_REQ_ONL and CM_PODLIST. All other schemas used by OctoMesh are unchanged.
• dataType is mandatory when starting EC_PRTFACT_CHANGE. Optional additional fields are endDate, transmissionCycle, purpose, techCode and fuelCode. This is a breaking change for clients that start this process directly.
• PlantCategory has been removed. The production type of a metering point is now derived from the techCode (AIB fact sheet 5): T01 solar, T02 wind, T03 hydro, T04–T07 other. If the grid operator does not report a techCode, the production type stays empty. fuelCode is passed through unchanged.
• Metering point lists may be empty. Replies of EC_PODLIST and CM_PODLIST can contain no metering points; pipelines must not assume at least one entry.
• Hard cut-over. From 5 October 2026 only the new EC_* schema sets are authorised in production; parallel operation of old and new versions is not possible. New market roles (Peer-to-Peer, Eigenversorger) are added by the market process update but require no schema change.

Excel Import

• Initial master data import functionality
• Batch processing for participant and metering point data
• Validation and error handling

2. OctoMesh Core Platform

Construction Kit

• Object-oriented data modeling (classes, inheritance, attributes, associations)
• Support for simple data types (strings, numbers, booleans) and complex records
• Version-controlled schema management

Business Logic Layer

• Energy allocation algorithms
• Billing calculations
• Regulatory compliance rules

API Layer

• RESTful APIs for application integration
• Event-driven architecture for real-time updates
• Security and authentication handling

3. User Applications

Management Application for Energy Communities

• Complete master data management
• Energy quantity tracking and allocation
• Billing and settlement processing
• EDA message monitoring and handling
• Reporting and analytics

Participant Portal

• Self-service access for community members
• Personal energy consumption/production views
• Billing history and statements
• Document access

Data Architecture

The solution manages four primary data domains:

1. Master Data: Core participant and infrastructure information
2. Energy Data: Production, consumption, and grid feed-in measurements
3. Billing Data: Financial transactions and settlements
4. Communication Data: EDA messages and system notifications

Data model and metering data

This section describes how the EnergyCommunity solution stores master data and metering values in OctoMesh. The hands-on counterpart is the tutorial Understanding energy data.

Construction Kits

The solution builds on three Construction Kit libraries:

Library	Content
Basic	Generic building blocks: named entities, tree nodes, addresses, contacts, time ranges, amounts
Basic.Energy	Energy domain: OperatingFacility, the abstract MeteringPoint with Consumer and Producer, EnergyMeasurement, the enums DataQuality, ProductionType, CarrierType
EnergyCommunity	Community-specific types: Customer, Consumer and Producer with participation attributes, ParticipationPeriod, EnergyPrice, billing documents, CommunitySettings

• A customer (member of the community) owns one or more operating facilities (a household, a company site, a PV plant).
• A facility has one or more metering points. A consumer metering point measures energy drawn from the grid, a producer metering point measures energy fed into the grid. The metering point number is the 33-character identifier of the grid operator (in Austria AT…).
• PartitionFactor (1–100 %) is the share of the metering point that takes part in this community; a metering point can take part in several communities.
• Participation periods state from when to when a metering point belongs to the community.
• An energy measurement entity is the anchor of one time series: one anchor per metering point and register (OBIS code). Its well-known name is <meteringPointRtId>_<obisCode>. The values themselves are stored as stream data, not on the entity.

The full type reference is in EnergyCommunity-4 and Basic.Energy.

Metering registers (OBIS codes)

Each value carries an OBIS code that says what was measured. The direction is encoded in the code (1.9.0 = drawn from the grid, 2.9.0 = fed in or allocated within the community), never in the sign: all values are positive kWh per 15-minute interval.

Register	Metering point	Meaning
1-1:1.9.0 G.01	Consumer	Total consumption measured at the meter
1-1:2.9.0 G.01	Producer	Total generation fed into the grid
1-1:2.9.0 G.02	Consumer	Share assigned by a static allocation key (can exceed the consumption)
1-1:2.9.0 G.03	Consumer	Self-coverage: energy covered from within the community; this is the quantity billed by the community
1-1:2.9.0 G.01T	Producer	Generation offered to the community (generation × partition factor)
1-1:2.9.0 P.01T	Producer	Part of the offered generation that was not distributed (surplus)

Derived quantities are not stored because they follow from the registers:

• Remaining consumption from the supplier: 1.9.0 G.01 − 2.9.0 G.03 per consumer.
• Energy distributed by a producer: G.01T − P.01T.
• Balance per 15-minute slot: Σ G.03 (consumers) = Σ (G.01T − P.01T) (producers).

In a community fed by the grid operator the registers arrive through EDA consumption records. In a community without EDA (self-reported or simulated metering points) the daily allocation computes G.03, G.01T and P.01T from the raw registers 1.9.0 G.01 and 2.9.0 G.01.

Data quality

Every value has a data quality (enum Basic.Energy/DataQuality):

Value	Meaning
L1	Measured 15-minute value
L2	Linear interpolation between two known meter readings
L3	Estimate (also used for missing values in the allocation)
Manual	Entered or corrected by a user
Unknown	No quality information

The raw archive resolves conflicting writes for the same interval by quality first (a lower L value wins) and then by the date of the source document, so an estimate never overwrites a measurement, and a final value replaces a provisional one. Billing only counts L1 and L2; L3 intervals are reported separately.

Storage: 15-minute windows and rollups

Metering values are stored in a time-range archive with 15-minute windows (window_start, window_end, amount.value, amount.unit, obisCode, dataQuality), one row per anchor and window. A cascade of rollup archives aggregates them into hourly, daily, weekly, monthly and yearly sums (SUM of the amount, MAX of the data quality). Calendar rollups are aligned to the time zone Europe/Vienna. See Stream Data Archives.

Daily allocation (D+1)

In a renewable energy community, energy produced by members is shared with members in the same 15-minute slot. The grid operator, or OctoMesh for communities without EDA, computes the allocation once a day for the previous day (D+1), after all values for day D have been reported:

1. For each slot the offered generation of each producer is its generation times its partition factor (G.01T).
2. The eligible demand of each consumer is its consumption times its partition factor.
3. With a dynamic key the offered energy is distributed in proportion to the eligible demand, never more than a consumer's own demand (G.03). With a static key each consumer receives a fixed share (G.02) and is covered up to its consumption.
4. What is left is the surplus (P.01T), split among the producers in proportion to their offer. It is sold outside the community.

The allocation pipeline of the solution runs after a configurable reporting cut-off (default 06:00 Europe/Vienna, setting CommunitySettings.AllocationCutOffTime), writes the registers into the raw archive and is idempotent: running it again for the same day produces identical rows. Metering points whose data comes from EDA are never overwritten, because there the grid operator allocates.

Key figures

Two ratios characterise a community over a period:

• Coverage ratio = Σ 2.9.0 G.03 / Σ 1.9.0 G.01: the share of the members' consumption covered from within the community.
• Surplus ratio = Σ P.01T / Σ G.01T: the share of the offered generation that could not be used within the community.

A community with lots of PV and few consumers has a high surplus ratio at noon and a low coverage ratio in the evening; a community with mostly consumers has a low surplus ratio and a low coverage ratio.