standard-packages

The standard-packages distribution contains the standard Energy Data Management (EDM) packages: pre-built, tested sets of platform configurations — flows, rules, transformation configurations, market adapters, dashboards, and more — that implement common meter-to-cash processes. Instead of building these processes from scratch, you install a package into a namespace and adapt it where needed.

For the functional description of the business processes these packages implement, see the Energy Data Management Module.

Separately licensed — access by agreement only

The standard packages are a paid add-on to the Energyworx platform and are not included in the standard platform subscription. They are distributed through a dedicated, access-restricted Artifact Registry repository (ewx-standard-packages), separate from the other shareable packages, and access is granted only to organizations that have a standard-packages agreement with Energyworx.

• If your organization has an agreement, ask Service Desk to grant your Google Account access to the ewx-standard-packages repository.
• If your organization does not have an agreement and you are interested in the standard packages, contact your Energyworx account manager.

Available packages

Package	Purpose	Functional documentation
vee	Validation, Estimation and Editing (VEE) of meter readings	Meter Reads Processing – VEE
master_data	Master data processing compliant with IEC 61968-9 (meters, metering points, meter-to-metering-point linkage, contracts)	Master Data Processing
billing	Billing determinants calculation	Billing Determinants Calculation
device_control	Device control transactions and meter event processing	Device Control Transactions
energy_communities	Energy community aggregations and calculations	Aggregations and Calculations
network_aggregations	Network area aggregations of VEE meter data	Aggregations and Calculations

Each package bundles the components it needs — rules (with their Python code), flows, transformation configurations, market adapters, channel families and classifiers, datasource classifiers, dashboards, taskboards, task types and statuses, trigger schedules, and namespace properties.

What is in the distribution

The standard-packages source distribution contains everything needed to assemble and deploy a package:

standard_packages-<version>/
├── packages/<package>/package_metadata.toml   ← package manifest: which configurations belong to the package
├── packages/<package>/README.md               ← per-package notes and limitations
└── src/standard_packages/
    ├── configurations/                        ← all configuration files (shared between packages)
    ├── rules/                                 ← Python source code of the rules
    └── scripts/package_creator.py             ← assembles one package from its manifest

Use the source distribution

A Python wheel is also published, but it does not contain the packages/ manifests. Download the source distribution (.tar.gz) as shown below instead of running a plain pip install.

Versioning

Standard package versions track the platform release like the other shareable packages: for platform release YY.MM the version is YY.M.0, see Versioning. The examples below target platform release 26.08 (package version 26.8.0); replace the version to match the release your environment is on. Always deploy the package version that matches your platform release: the standard rules use the rule framework of that release.

Prerequisites

• Python (see the version range on this page)
• The gcloud CLI
• A Google Account with access to the ewx-standard-packages repository in the ewx-global Artifact Registry project. Ask Service Desk to grant it if you do not have it yet.

Authenticate once per machine:

gcloud auth application-default login

• Python 3.11 to 3.14
• ewx-cli for uploading the configurations. It can be installed into the same virtual environment.

Download and install

macOS / Linux

mkdir ewx_standard_packages
cd ewx_standard_packages
python3.13 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install keyring keyrings.google-artifactregistry-auth
pip download standard-packages==26.8.0 --no-deps --no-binary :all: -d . --index-url https://europe-west1-python.pkg.dev/ewx-global/ewx-standard-packages/simple/ --extra-index-url https://pypi.org/simple/
tar -xzf standard_packages-26.8.0.tar.gz
cd standard_packages-26.8.0
pip install .

Windows (PowerShell)

mkdir ewx_standard_packages
cd ewx_standard_packages
py -3.13 -m venv .venv
.venv\Scripts\Activate.ps1
pip install --upgrade pip
pip install keyring keyrings.google-artifactregistry-auth
pip download standard-packages==26.8.0 --no-deps --no-binary :all: -d . --index-url https://europe-west1-python.pkg.dev/ewx-global/ewx-standard-packages/simple/ --extra-index-url https://pypi.org/simple/
tar -xzf standard_packages-26.8.0.tar.gz
cd standard_packages-26.8.0
pip install .

If Activate.ps1 is blocked by execution policy, run Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned once and reopen PowerShell.

pip download fetches the source distribution from the restricted registry, and the final pip install . installs the standard_packages Python module with the dependencies that the packaging script below needs. A 403 or authorization error on the pip download step means your Google Account has no access to the ewx-standard-packages repository — see the licensing note at the top of this page.

If ewx-cli is not installed yet, install it into the same environment following the ewx-cli instructions.

Assemble a package

The configuration files in the distribution are shared between packages, so before uploading you assemble the package you licensed into its own folder using its manifest:

macOS / Linux

python src/standard_packages/scripts/package_creator.py \
    packages/vee/package_metadata.toml \
    src/standard_packages/configurations \
    ./vee_configurations

Windows (PowerShell)

python src\standard_packages\scripts\package_creator.py packages\vee\package_metadata.toml src\standard_packages\configurations .\vee_configurations

This copies the configurations listed in the manifest into ./vee_configurations, inlines the Python rule code into the rule configurations, generates the dashboard queries, and writes a METADATA.json so the folder follows the layout ewx-cli expects. Replace vee with the package you are installing.

Upload to your namespace

Upload the assembled folder to the destination namespace with ewx-cli:

ewx-cli config upload ./vee_configurations <project-prefix>/<namespace>

• See Identifying a namespace for the <project-prefix>/<namespace> format.
• Uploading requires owner-level access on the destination namespace — see Required permissions.
• Run with --dry-run first to review the plan, see Dry runs. Each configuration is labeled (New), (Update), or (Unchanged). If you customized configurations from an earlier package version on the destination, an upload overwrites them; the upload is recorded, so it can be rolled back.

Dashboards are stored per user, not per namespace, so config upload does not ship them. For the packages that include a dashboard (vee, master_data, billing, device_control) upload it with a separate command, once per dashboard file:

ewx-cli config upload_dashboards ./vee_configurations/dashboards/vee_dashboards.json --dest-namespace <project-prefix>/<namespace>

With neither --user nor --group, the dashboard is uploaded to every user in the destination namespace, skipping service accounts. Pass --group <group-name> to restrict it to the members of a permission group, or --user <user-email> to target a single user, repeating --user for more than one.

The dashboard files are:

Package	Dashboard file
vee	dashboards/vee_dashboards.json
master_data	dashboards/master_data.json
billing	dashboards/billing.json
device_control	dashboards/device_events.json and dashboards/meter_events.json

Widgets whose query references a flow by ID carry a string replacement that ships empty -- billing_flow_id for billing and vee_flow_id for vee. Set it to the ID of the uploaded flow in the console after uploading, or pass --src-namespace so the CLI remaps it by matching flow names. Until it is set, those widgets render without data.

After uploading

• Timezones: the transformation configurations (and, for energy_communities and network_aggregations, the trigger schedules) ship with timezones set to Europe/Amsterdam. Change them in the configuration files before uploading, or in the console afterwards, if you need a different timezone.
• Trigger schedules are always disabled by an upload. Enable them in the console after uploading.
• Dashboards are uploaded separately, see above.

Package notes

Each package ships a README.md under packages/<package>/ in the distribution with its notes and limitations. The points that matter for a deployment:

vee

Validation, estimation and editing of meter readings. See Meter Reads Processing – VEE for the process and rules. The dashboard widgets reference the VEE flow through the vee_flow_id string replacement (see above).

master_data

Master data compliant with IEC 61968-9 messages: MeterConfig creates a meter datasource and its tags, UsagePointConfig a metering point datasource, CustomerAgreementConfig adds or updates the agreement on the metering point tags, and MasterDataLinkageConfig links meter and metering point. Acknowledging received MeterConfig messages requires a Pub/Sub topic named after the value of the master_data_pubsub_topic_name namespace property; create the topic and set the property before the first message arrives. See Master Data Processing.

billing

Billing determinants calculation. The dashboard widgets query the billing flow by ID through the billing_flow_id string replacement; set it to the ID of the uploaded Standard_Billing_Calculation_Flow, or pass --src-namespace when uploading the dashboard. See Billing Determinants Calculation.

device_control

Device control transactions and meter event processing, with two dashboards: device_events covers critical events and event types, meter_events the commands executed on devices. The taskboard parameter of the standard_annotate_critical_event_validation rule is not ID-mapped by the upload: set it to the task board ID on the destination namespace after uploading. That rule creates tasks from a rule, see Task creation for the limitations that apply. See Device Control Transactions.

energy_communities

Aggregations and calculations for energy communities. Its trigger schedules are disabled by the upload and need to be enabled in the console afterwards. See Aggregations and Calculations.

network_aggregations

Network area aggregations of VEE meter data. Two bigquery_ingest trigger schedules (BQ_Network_Area_Aggregation_Daily_Trigger and BQ_Network_Area_Aggregation_Monthly_Trigger) sum the previous day's and month's VEE data per network area — resolved from the network_contract tag — and write the result to the File manager, where the BQ_Network_Area_Aggregation_Ingest_MA market adapter and BQ_Network_Area_Aggregation_Ingest_TC transformation configuration ingest it back onto the network-area datasources. Its trigger schedules are disabled by the upload and need to be enabled in the console afterwards. The package expects a VEE setup alongside it: datasources tagged with network_contract and data in the ACTIVE_(RE)DELIVERY_INT15T/READ15T_VEE channel classifiers. See Aggregations and Calculations.

Automated tests

Every package contains tests/unit (unit tests of the rules) and tests/automated (pytest-bdd-ewx scenarios). The automated tests upload all configurations to the target namespace and run scenarios against example datasources they create, so run them with pytest -v tests/automated/ against a dedicated test namespace only: they delete the existing configurations in that namespace before uploading. The energy_communities suite creates 30 households, 3 solar installations and 2 energy communities; if a scenario fails because a datasource is not found yet, wait until it is created and run it again. See pytest-bdd-ewx for installing the plugin.

Updating to a new release

To update a package after a platform release, download the matching new version of standard-packages, assemble the package, and upload it again. Existing configurations on the destination are updated in place; rules whose content did not change are skipped as (Unchanged). Review the upload overview before confirming, especially if you have customized any of the standard configurations.

Installation issues

Symptom	Cause and fix
401/403 or Authorization error from pkg.dev	Your Google Account is not authenticated or has no access to the repository. Re-run gcloud auth application-default login; if it persists, ask Service Desk to check your access. With uv, re-export UV_INDEX_EWX_GLOBAL_PASSWORD, the token expires after an hour.
No matching distribution or doesn't match any versions	pip is not looking at the Energyworx index (check --index-url) or the pinned version does not exist. Pins follow the platform release, see Versioning; 2.x versions are no longer published.
keyring backend not found	Install keyring keyrings.google-artifactregistry-auth in the same environment before running pip install against the index.
Activate.ps1 cannot be loaded (Windows)	Run Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned once and reopen PowerShell.
Plugin not loaded in pytest	Confirm pytest-bdd-ewx is installed in the active environment (pip show pytest-bdd-ewx).

If the problem persists, contact Service Desk with the full command, the full error output, your Python version and whether you use pip or uv.

A 403 on the pip download step means your Google Account has no access to the ewx-standard-packages repository. Verify with Service Desk that it is covered by your organization's standard-packages agreement.