@epilot/app-client 0.12.6 → 0.12.8

package/dist/openapi.d.ts

@@ -1519,10 +1519,19 @@ declare namespace Components {
              * Hook that returns runtime metadata describing how a visualization (consumption / price / cost chart) should be rendered for a given portal context (meter, contract, etc). It is invoked by the portal before fetching data, with the same context the data hook would receive, so that the discovery shape can vary per meter/contract. The expected response to the call is:
              *   - 200 with a JSON body of shape:
              *     {
-             *       "type_options": [{ "id": "ht", "label": { "en": "High tariff" }, "aggregation_group": "consumption", "unit": "kWh" }, ...],
+             *       "type_options": [
+             *         { "id": "feed-out", "label": { "en": "Grid import" }, "aggregation_group": "grid", "statistical_method": "sum", "direction": "out", "unit": "kWh" },
+             *         { "id": "feed-in",  "label": { "en": "Feed-in"     }, "aggregation_group": "grid", "statistical_method": "sum", "direction": "in",  "unit": "kWh" },
+             *         ...
+             *       ],
              *       "intervals": ["PT15M", "PT1H", "P1D", "P1M"],
              *       "data_range": { "from": "2024-01-01T00:00:00Z", "to": "2026-05-01T00:00:00Z" }
              *     }
+             *   Each type option carries its own `statistical_method`, which describes the method already applied to that type's data and dictates the chart shape: `sum` is rendered as a bar chart; `min`, `average`, and `max` are rendered as a line chart. A single visualization can therefore mix bar-shaped types with line-shaped types. Defaults to `sum` when omitted.
+             *   `direction` declares whether a type adds to or subtracts from the period total: `out` is grid-to-consumer (consumption, additive); `in` is consumer-to-grid (export, subtractive). With both present in a prosumer setup the chart computes a *net* consumption per period and can flip its label to "Total production" when the result is negative. Defaults to `out` when omitted.
+             *   `aggregation_group` controls how types within a group are visually combined (depends on the per-type `statistical_method`):
+             *     - bar chart (`sum`): same-group types are stacked into a single bar (e.g. ht/nt summed into total consumption); different-group types render side-by-side.
+             *     - line chart (`min` / `average` / `max`): same-group types are rendered as an area chart; different-group types render as separate lines.
              *   All fields are optional; the consumer falls back to its defaults for whatever the hook does not return.
              * The portal looks up this hook implicitly per extension (one `visualizationMetadata` hook per extension) — there is no need for a data-retrieval hook to reference it explicitly.
              *
@@ -2035,10 +2044,19 @@ declare namespace Components {
          * Hook that returns runtime metadata describing how a visualization (consumption / price / cost chart) should be rendered for a given portal context (meter, contract, etc). It is invoked by the portal before fetching data, with the same context the data hook would receive, so that the discovery shape can vary per meter/contract. The expected response to the call is:
          *   - 200 with a JSON body of shape:
          *     {
-         *       "type_options": [{ "id": "ht", "label": { "en": "High tariff" }, "aggregation_group": "consumption", "unit": "kWh" }, ...],
+         *       "type_options": [
+         *         { "id": "feed-out", "label": { "en": "Grid import" }, "aggregation_group": "grid", "statistical_method": "sum", "direction": "out", "unit": "kWh" },
+         *         { "id": "feed-in",  "label": { "en": "Feed-in"     }, "aggregation_group": "grid", "statistical_method": "sum", "direction": "in",  "unit": "kWh" },
+         *         ...
+         *       ],
          *       "intervals": ["PT15M", "PT1H", "P1D", "P1M"],
          *       "data_range": { "from": "2024-01-01T00:00:00Z", "to": "2026-05-01T00:00:00Z" }
          *     }
+         *   Each type option carries its own `statistical_method`, which describes the method already applied to that type's data and dictates the chart shape: `sum` is rendered as a bar chart; `min`, `average`, and `max` are rendered as a line chart. A single visualization can therefore mix bar-shaped types with line-shaped types. Defaults to `sum` when omitted.
+         *   `direction` declares whether a type adds to or subtracts from the period total: `out` is grid-to-consumer (consumption, additive); `in` is consumer-to-grid (export, subtractive). With both present in a prosumer setup the chart computes a *net* consumption per period and can flip its label to "Total production" when the result is negative. Defaults to `out` when omitted.
+         *   `aggregation_group` controls how types within a group are visually combined (depends on the per-type `statistical_method`):
+         *     - bar chart (`sum`): same-group types are stacked into a single bar (e.g. ht/nt summed into total consumption); different-group types render side-by-side.
+         *     - line chart (`min` / `average` / `max`): same-group types are rendered as an area chart; different-group types render as separate lines.
          *   All fields are optional; the consumer falls back to its defaults for whatever the hook does not return.
          * The portal looks up this hook implicitly per extension (one `visualizationMetadata` hook per extension) — there is no need for a data-retrieval hook to reference it explicitly.
          *

package/dist/openapi.json

@@ -3252,7 +3252,7 @@
         "additionalProperties": false
       },
       "PortalExtensionHookVisualizationMetadata": {
-        "description": "Hook that returns runtime metadata describing how a visualization (consumption / price / cost chart) should be rendered for a given portal context (meter, contract, etc). It is invoked by the portal before fetching data, with the same context the data hook would receive, so that the discovery shape can vary per meter/contract. The expected response to the call is:\n  - 200 with a JSON body of shape:\n    {\n      \"type_options\": [{ \"id\": \"ht\", \"label\": { \"en\": \"High tariff\" }, \"aggregation_group\": \"consumption\", \"unit\": \"kWh\" }, ...],\n      \"intervals\": [\"PT15M\", \"PT1H\", \"P1D\", \"P1M\"],\n      \"data_range\": { \"from\": \"2024-01-01T00:00:00Z\", \"to\": \"2026-05-01T00:00:00Z\" }\n    }\n  All fields are optional; the consumer falls back to its defaults for whatever the hook does not return.\nThe portal looks up this hook implicitly per extension (one `visualizationMetadata` hook per extension) — there is no need for a data-retrieval hook to reference it explicitly.\n",
+        "description": "Hook that returns runtime metadata describing how a visualization (consumption / price / cost chart) should be rendered for a given portal context (meter, contract, etc). It is invoked by the portal before fetching data, with the same context the data hook would receive, so that the discovery shape can vary per meter/contract. The expected response to the call is:\n  - 200 with a JSON body of shape:\n    {\n      \"type_options\": [\n        { \"id\": \"feed-out\", \"label\": { \"en\": \"Grid import\" }, \"aggregation_group\": \"grid\", \"statistical_method\": \"sum\", \"direction\": \"out\", \"unit\": \"kWh\" },\n        { \"id\": \"feed-in\",  \"label\": { \"en\": \"Feed-in\"     }, \"aggregation_group\": \"grid\", \"statistical_method\": \"sum\", \"direction\": \"in\",  \"unit\": \"kWh\" },\n        ...\n      ],\n      \"intervals\": [\"PT15M\", \"PT1H\", \"P1D\", \"P1M\"],\n      \"data_range\": { \"from\": \"2024-01-01T00:00:00Z\", \"to\": \"2026-05-01T00:00:00Z\" }\n    }\n  Each type option carries its own `statistical_method`, which describes the method already applied to that type's data and dictates the chart shape: `sum` is rendered as a bar chart; `min`, `average`, and `max` are rendered as a line chart. A single visualization can therefore mix bar-shaped types with line-shaped types. Defaults to `sum` when omitted.\n  `direction` declares whether a type adds to or subtracts from the period total: `out` is grid-to-consumer (consumption, additive); `in` is consumer-to-grid (export, subtractive). With both present in a prosumer setup the chart computes a *net* consumption per period and can flip its label to \"Total production\" when the result is negative. Defaults to `out` when omitted.\n  `aggregation_group` controls how types within a group are visually combined (depends on the per-type `statistical_method`):\n    - bar chart (`sum`): same-group types are stacked into a single bar (e.g. ht/nt summed into total consumption); different-group types render side-by-side.\n    - line chart (`min` / `average` / `max`): same-group types are rendered as an area chart; different-group types render as separate lines.\n  All fields are optional; the consumer falls back to its defaults for whatever the hook does not return.\nThe portal looks up this hook implicitly per extension (one `visualizationMetadata` hook per extension) — there is no need for a data-retrieval hook to reference it explicitly.\n",
         "type": "object",
         "properties": {
           "id": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@epilot/app-client",
-  "version": "0.12.6",
+  "version": "0.12.8",
   "description": "JavaScript client library for the epilot App API",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",