Austria Smartmeter for Home Assistant

One integration for Austrian smart meters. It reads your energy data where it actually lives - in the grid operator's web portal, at the meter's own customer interface, on a meter-reading gateway or at an API platform - and brings it into Home Assistant as consumption, feed-in, power and price sensors, together with the long-term statistics the Energy dashboard needs.

Requires Home Assistant 2026.9 or newer. On an older Home Assistant, install the 1.1.8 tag.

📑 Table of contents

• ⚡ Supported providers
• ✨ Features
• 🚀 Installation
• ⚙️ Configuration
• 📊 Entities & sensors
• 🐛 Troubleshooting & debugging
• 📚 Documentation
• 🗺️ Roadmap
• 📝 Changelog
• 📄 License

⚡ Supported Providers

Provider	Status	Notes
Wiener Netze	✅ Supported	Smart Meter Web Portal account required
Netz Niederösterreich (EVN)	✅ Supported	Smart Meter Web Portal account required
energyLIVE (smartENERGY)	✅ Supported	Meter reader hardware, not a grid operator. API key required (see below)
energiedaten.at	✅ Supported	Data platform, not a grid operator. API key required (see below)
DSMR / P1 customer interface	✅ Supported	Local serial cable or network P1 reader. No account required
aWATTar market prices	✅ Supported	Price feed (EPEX day-ahead), not meter data. No account required
Selectra tariff planning	✅ Supported	Third-party tariff API, personal token required. Free tier: 60 calls/month
Salzburg Netz	✅ Supported	API key from the service portal + customer number. 15-minute load profiles
E-Werk Gösting	✅ Supported	Web portal account (mein-portal.at). 15-minute consumption and production per Anlage
Stromnetz Graz	🚧 Planned	In development

Requirements: Home Assistant 2026.9 or newer.

energyLIVE (smartENERGY)

energyLIVE reads the smart meter through a small interface (optionally paired with a gateway that forwards the data over LoRa), so it is neither a grid operator nor a portal login:

1. Get an API key in the smartENERGY app or customer portal (API Key verwalten). Being a smartENERGY customer is not required.
2. In Home Assistant, add the integration, select energyLIVE (smartENERGY) and paste the key. The paired devices are found automatically.

The devices report genuine cumulative meter readings — consumption (1.8.0) and feed-in (2.8.0) in Wh — which is exactly what the integration's total-increasing sensors expect, plus the current power in W. The API has no history and no daily statistics, and the values are only as fresh as the configured scan interval (see Options below).

energiedaten.at (API platform)

energiedaten.at collects smart meter data from the Austrian grid operators and republishes it through a REST API. It is therefore configured differently from the portals above:

1. Create an API key in the energiedaten.at dashboard under Integrations → API Keys with the scopes smart-meters:read and data:read. The key is shown once.
2. Add the metering point there (Smart Meters) and request its consent. Data starts flowing the day after the grid operator accepts; the meter is ready when its status is connected.
3. In Home Assistant, add the integration, select energiedaten.at (API key) and paste the key.

The integration is read-only for this provider: it never creates locations, meters or consents. The platform publishes 15-minute interval readings, which are summed up per local day and reported as daily consumption/feed-in in Wh (the API exposes no cumulative meter register).

A poll reads the last seven days in one request and reports the newest day the platform actually holds, so a grid operator that delivers a day late - or several days late - does not leave the sensors empty. Each register reads exactly one OBIS code, and the meter-wide total (G.01) is preferred over the grid figure (P.01), because that is the one the platform's own analyses use; the two are never added up. The attributes of a sensor name the day it reports (day), where its data reaches (period_from, period_to) and the code it was read from (source_obis_code).

The adapter follows the platform's documented API. The window, the cursor pagination and the client-side OBIS selection were verified against the reference implementation the platform itself ships for Home Assistant, not against a live account of ours - please keep reporting what your meter shows.

DSMR / P1 customer interface (local)

A meter's customer interface can also be read directly. It is a physical port ("H1", 6-pin RJ12) that pushes a DSMR telegram every 10 seconds, so all that is needed is the connection to it:

1. Add the integration and select DSMR / P1 meter (local).
2. Enter the port: /dev/ttyUSB0, a /dev/serial/by-id/… path, or socket://<host>:<port> for a P1 reader on your network.
3. Pick the DSMR version (the Austrian Sagemcom T210-D-R is listed by name) and, for an encrypted meter, paste the decryption key your grid operator provided.

The integration reads one telegram per scan interval and reports the cumulative registers (1.8.0 consumption / 2.8.0 feed-in in Wh) plus the current power (1.7.0/2.7.0 in W). Gas and water values that a telegram carries over M-Bus are not exposed.

Note: Home Assistant's own DSMR integration reads the very same interface with push updates (every 10 seconds). Use it if you want real-time data; this integration polls, with a minimum interval of 60 minutes.

aWATTar market prices

aWATTar publishes the EPEX Spot day-ahead prices of the Austrian and German market over a public API — no account, no token:

1. Add the integration and select aWATTar market prices.
2. Pick the market area (Austria or Germany).

The integration then adds a Market Price sensor in ct/kWh for the hour that is currently running, with the rest of the horizon as attributes: the next hour's price, the cheapest upcoming hour (and when it starts), the min/max/average of everything still ahead, and the price exactly as the API delivered it. Negative prices are passed through unchanged, because they are the interesting ones.

This provider reads no meter. It is included because the hourly price is what makes load shifting (heat pump, wallbox, battery) automatable. aWATTar asks for fair use of 100 requests per day; one request per scan interval uses 24 of them.

Selectra tariff planning

Selectra publishes the Electricity Planning API: it qualifies a household's actual tariff — provider, offer, option, network area — and returns the priced time bands of exactly that contract: high/low tariff, night hours, dynamic prices, plus the feed-in price of a PV contract.

1. Create a token at api.selectra.com, then add the integration and select Selectra tariff planning.
2. Paste the token, your country code (at) and your postcode.
3. Answer the questionnaire the API returns (which provider, which offer, which option …) until it reports itself satisfied. The qualified offer is stored with the entry.

The integration then adds a Tariff Price sensor in ct/kWh for the band that is running now, with the other bands as attributes: the next band, the cheapest upcoming band (and when it starts), the min/max/average still ahead, the feed-in price and the moment the plan will be updated next.

This is a commercial third-party API, not a grid operator. Every call needs a personal bearer token and calls are metered:

• Free tier: 60 calls per calendar month (all markets, all endpoints, no credit card). Qualifying a new entry costs a few calls, one price plan costs one.
• Paid plans start at 1 €/month per market; Austria is 200 €/month with per-request tiers above 10 000 calls.

The integration spends as few calls as possible: a price plan carries a next_update timestamp and is cached until then, so a household uses one or two calls per day no matter how short the scan interval is. When the monthly quota is exhausted, the last plan keeps being served and its reading is flagged plan_expired instead of failing every poll.

The adapter was written against the public OpenAPI document (Electricity Planning API 1.0.0), because every call is token gated: it is not verified against the live service. Prices, the questionnaire and the error mapping follow the published schema.

Salzburg Netz

Salzburg Netz (part of the Salzburg AG) runs its own interface next to the service portal. It reports the 15-minute load profile of a metering point, which is the same data the portal's data analysis shows:

1. In the service portal, open Mein Benutzerkonto → API Schlüssel and create a key. Pick a validity period; a key lives at most two years, and up to ten keys can exist.
2. Add the integration and select Salzburg Netz.
3. Enter the API key and your customer number (GPNR, 8 digits, starting with 1).
4. Leave Metering points empty to let the integration discover them, or type them in separated by commas - a 33-character metering point (AT00…) or a 10-digit facility number (003…).

The integration adds a load profile sensor per metering point and register: the 15-minute consumption and feed-in values in Wh, with the day's total for that register as an attribute next to the meter number and type from the API's device data.

Two things are worth knowing. The API is documented as a POST-only interface: your key goes into the Authorization header, the customer number, metering point and the optional dates AB/BIS go into the body. And the operator updates load profiles once a day (between 10:00 and 12:00) and explicitly asks not to query the same period more than once a day - which is why this provider reads a period at most once per day and checks the key with the same rhythm, so a 60-minute scan interval costs one request per metering point per day.

The shape of a successful response is not documented. The operator's description shows its example output as a CSV table; the JSON variant is not published anywhere, and /docs or /openapi.json do not exist. The parser therefore reads records tolerantly (instead of assuming a structure) and the endpoint addresses, the request body and the error format were verified against the live API, but the JSON field names are not verified. If a sensor stays without a value, the log says so and the raw response is worth reporting: open an issue.

The readings (meter registers), consumption (billed amounts) and partner categories are not read yet.

E-Werk Gösting

E-Werk Gösting (E-Werk Gösting Stromversorgungs GmbH, Graz) shows its customers' consumption and production in a web portal, goesting-dav.mein-portal.at. This provider logs in to that portal and reads the same 15-minute values that its Zum Verbrauch / Erzeugung page shows and exports:

1. Make sure you can log in to the customer portal in a browser - the integration uses the same account.
2. Add the integration and select E-Werk Gösting.
3. Enter the e-mail address and password of the portal account.

After a change of the portal password, remove the E-Werk Gösting entry under Settings → Devices & Services and add it again: the integration cannot ask for a new password yet.

Every active Anlage (facility) of the account becomes a device of its own; Anlagen whose contract has ended are left out. A device is identified by the Anlage's Zählpunkt, which it shows as its Metering Point ID, and named after the address plus the Anlagennummer, e.g. Musterstraße 1/2 (Anlage 20001234), so that two Anlagen at one address stay apart. Each device gets a Consumption Latest Day sensor (Verbrauch (gemessen)) and, when the portal reports feed-in, a Production Latest Day sensor (Lieferung (gemessen)). Both show the total in Wh of the latest complete day that counts as final (96 quarter hours, 92 or 100 on the days of the DST switches).

A day counts as final from 12:00 of the following day on. The portal publishes a day by then, usually earlier - but while it publishes one in the morning, the values can still change: on 30.09.2026 the previous day read 10,385, then 11,808 and finally 13,128 Wh within an hour, and the portal marks no value as provisional. Until 12:00 the latest day is therefore the day before yesterday (or the day before that, when the portal lacks a quarter hour of it); from 12:00 on, it is yesterday. When a poll before 12:00 already holds yesterday's values back, the integration refreshes once more at 12:05 (unless polling is disabled for the entry): yesterday's values arrive then, independent of the scan interval. The rule goes by the clock - should the portal ever still be publishing a day after 12:00, its provisional values are counted and imported, and a later poll corrects them, with a warning in the log that ends in "values had changed or were missing".

The sensors' attributes are the day (last_reading_date), data_until (the end of the newest quarter hour that counts), held_back (the quarter hours already read that do not count yet) and settles_at (when they will), latest_validated (true when all the day's values are measured values), latest_intervals, the statistic_id of the long-term statistic below and history_start (the contract start). These sensors have no state_class, on purpose: the values reach Home Assistant's statistics with their real timestamps instead (see below). The diagnostic Latest Data sensor is the end of the newest quarter hour that counts; Home Assistant shows it as x hours ago, which tells how fresh the data is. The meter's serial number, the contract, the load profile and the address appear as device details, diagnostic entities and attributes.

Production values follow the portal's channel naming (Lieferung (gemessen), channel 1-1:2.9.0 G.01) but have not been verified with a feed-in Anlage yet. Only the measured channels are read: the channels of an energy community (Energiegemeinschaft) and the other shares the portal may list are not, and the log names them once at INFO level.

The values are exactly the portal's: its export button builds the .xlsx file in the browser from the very data this integration reads. This was checked quarter hour by quarter hour against the live portal, and verified on payloads captured from the live portal for both DST days. A timestamp is the end of its 15-minute interval in Europe/Vienna time - 2026-08-01T00:15:00+02:00 is the quarter hour from 00:00 to 00:15 - and a value counts towards the day in which its interval starts.

The portal publishes a day's values on the next day, by 12:00 at the latest and usually earlier: today's values are never there yet, and yesterday's can arrive late. A poll therefore reads the last four days (today and the three days before), one request per Anlage, so that the sensors show a complete day even while yesterday does not count yet. The portal serves 15-minute values only while a request spans at most 30 days between the midnight of its first and the midnight of its last day - beyond that it silently answers daily values. A 31-day month therefore fits into one request, while the month of the autumn DST switch (30 days and one hour) takes two, and a longer period is read in as many requests as it needs.

Energy dashboard and long-term statistics

A sensor's state is recorded at the moment it is polled, so statistics compiled from it would put values that the portal publishes a day late at the wrong time - and they could not hold the history that the portal already has. The integration therefore writes the values into Home Assistant's long-term statistics with their real timestamps. They are hourly, because Home Assistant's long-term statistics are: the four quarter hours of an hour are summed, and a quarter hour counts towards the hour in which it starts. Each Anlage has a statistic named after its device, <device> Consumption (statistic ID asm:<Zählpunkt>_consumption, e.g. asm:at0082100000000000000000000012345_consumption), and <device> Production when it feeds in.

The imported history does not appear in an entity's History panel: that shows the states an entity had, and the sensor only ever shows the latest day. It is in Settings → Dashboards → Energy, in Developer tools → Statistics (search for asm:) and in a Statistics graph card, for example:

type: statistics-graph
title: Consumption
entities:
  - asm:at0082100000000000000000000012345_consumption
stat_types:
  - change
period: day
days_to_show: 30

• In Settings → Dashboards → Energy, pick <device> Consumption as grid consumption. It is a statistic, not the sensor entity, and the picker lists it by its name. Home Assistant cannot attach a fixed price or a price entity to an external statistic like asm:…_consumption (the Energy dashboard rejects it), so its costs cannot be tracked there at the moment.
• On the first poll, the whole available history is imported, from the contract start on: a few dozen portal requests, once. For the account this provider was developed with, the data starts on 2025-02-27, and the months before it are empty. The import runs in the background - the sensors are updated right away - and logs one line per statistic at INFO level when it is done.
• Later polls add the new hours, a day at a time: a day is imported once it counts as final, with the refresh at 12:05 or the first poll after 12:00. After Home Assistant was off for a while, the missing days are read as well. Quarter hours that the portal marks as estimated (substitute values) are imported as the portal reports them.
• The settled days among the last four days (yesterday counts from 12:00 on) are compared with what was imported and corrected when the portal changed a value, so a value can be corrected for about two and a half days after its day: every poll writes such hours again, with running sums that stay continuous, and the log names them with a warning ("values had changed or were missing"). An older day is not compared any more. A manual adjust sum of this statistic (Developer tools → Statistics) within that time can be undone by such a correction.
• An hour that the portal has not delivered holds the import back, because the portal may still deliver it. Once newer values have existed for more than 7 days, the gap is skipped, with a warning in the log that names it ("so this gap is skipped").

Updating from the preview? The former Consumption 15 min sensor is now Consumption Latest Day (with feed-in, Production 15 min is now Production Latest Day). It keeps its entity ID, sensor.…_consumption_15_min: Home Assistant never renames an entity ID, but it can be changed in the entity's settings. It had state_class: total, so Home Assistant compiled statistics from its state at poll time; now that the state class is gone, Home Assistant reports that it "no longer has a state class" (Settings → Repairs), and its old statistics can be cleared in Developer tools → Statistics. Consumption Yesterday and Consumption Day Before Yesterday are no longer provided: Home Assistant marks them as such, and they can be deleted on their entity page (their old statistics in Developer tools → Statistics). If one of these sensors was selected in the Energy dashboard, replace it with the <device> Consumption statistic. An earlier version imported a day as soon as the portal showed it, also in the morning while its values could still change; this version corrects such values once the day counts as final, as long as it is one of the settled days among the last four days (about two and a half days after the day).

Troubleshooting. Authentication failed during the setup means that the portal rejected the e-mail address or password - check them in a browser. Connection failed, with the log message "The E-Werk Gösting portal did not accept its login action", means that the portal is down or was updated in a way the integration cannot follow by itself (it looks the login up again after a portal update; this message appears when that fails) - try again later, and please open an issue if it persists. Any other Connection failed means that the portal could not be reached, answered with an error page, or reported a problem of its own ("The E-Werk Gösting portal could not log in"); the log names the address, the HTTP status and the content type, or the portal's message. An Anlage for which the portal names no Zählpunkt is left out, with a warning in the log. When the statistics import "could not read" a month of history - also when the portal answered it with "daily value(s) instead of 15-minute values" - it stops there and goes on with the next poll. A register whose values the client cannot read (it says so with "the portal's values could not be read") is not imported either, and nothing is skipped over it.

Enable debug logging (see Troubleshooting & Debugging below) before you report a problem. The log never contains the password or the portal's session cookies, but it does contain your Anlage and Zählpunkt numbers and can contain your e-mail and street address - check it before you post it.

✨ Features

• Easy setup: configuration directly through the Home Assistant UI (config flow).
• Ten providers behind one entry: a portal login, an API key, a serial port or a market area - the setup asks each provider only for what it actually needs.
• Multi metering point support: supports accounts with several metering points/addresses.
• Automatic detection: detects consumption (1.8.0) and production/feed-in (2.8.0).
• Reads that survive a late portal: a provider that publishes its data a day late is read over a window, so its sensors report the newest day that exists instead of staying empty until the portal catches up.
• Statistics: daily consumption statistics ("Consumption Yesterday", "Consumption Day Before Yesterday") where the portal provides them.
• Long-term statistics with real timestamps: values that a portal publishes a day late (E-Werk Gösting) go into Home Assistant's long-term statistics hour by hour, with their history, for the Energy dashboard.
• Diagnostics: detailed technical information exposed as diagnostic entities:
  • Full address (street, city, ZIP)
  • Facility type (e.g. consumption/feed-in)
  • Contract status (active/inactive)
  • Market readiness (communicative status)
• Clean naming: uses the friendly names assigned in the web portal instead of long ID numbers.
• Downloads diagnostics: Settings → Devices & Services → Austria Smartmeter → Download diagnostics.
• Brand images included: the integration ships its own icon and logo, so it shows up properly in the Home Assistant UI.

📚 Documentation

The project documentation lives in the wiki, which covers two lines of the integration at the same time:

Document	What it covers
🏠 Documentation home	Landing page: which document applies to which version.
📐 Architecture Design Document (ADD)	Requirements, system context, component decomposition, architectural decisions, risks, roadmap. Applies to 1.2.x.
🧩 Software Design Document (SDD)	Module inventory, interface contracts, component design, sequence diagrams, error handling matrix, release process. Applies to 1.2.x.
🗺️ Workflow Diagrams	Repository map (generated with GitDiagram) plus setup, update, login and entity-creation workflows.
🛠️ Adding a New Provider	Developer guide for adding a provider.
🗄️ Archived 1.1.8 documentation	The pre-2026.9 design, kept for reference.

The documents describe the 1.2.x line, which is what this release belongs to. They require Home Assistant 2026.9 or newer. If you are still running 1.1.8 (an older Home Assistant), install it from the 1.1.8 tag and read the archived documentation.

🚀 Installation

Option 1: Via HACS (recommended)

Since this is a custom integration, add it as a custom repository:

1. Open HACS in Home Assistant.
2. Go to "Integrations".
3. Click the three dots (...) in the top right corner and select "Custom repositories".
4. Paste the URL of this repository.
5. Select "Integration" as the category.
6. Click "Add" and then install "Austria Smartmeter".
7. Restart Home Assistant.

Option 2: Manual

1. Download the custom_components/asm folder from this repository.
2. Copy the folder to your Home Assistant directory under /config/custom_components/.
3. The structure should look like this: /config/custom_components/asm/__init__.py, etc.
4. Restart Home Assistant.

⚙️ Configuration

1. In Home Assistant, go to Settings → Devices & Services.
2. Click "+ Add Integration" in the bottom right.
3. Search for "Austria Smartmeter".
4. Select your grid operator (e.g. Wiener Netze).
5. Enter your username (usually email) and password for the operator's web portal. For energyLIVE (smartENERGY) enter the API key instead, for DSMR / P1 meter (local) the port your meter's customer interface is connected to, for aWATTar market prices the market area, and for Selectra tariff planning your API token, country code and postcode (followed by its questionnaire). For Salzburg Netz enter the API key and customer number (GPNR) from the service portal; the metering points are optional. For energiedaten.at enter the API key of its dashboard as well. For E-Werk Gösting enter the e-mail address and password of the customer portal (mein-portal.at).
6. Upon successful login, your meters will be added automatically.

Options

Clicking the "Configure" button on the integration entry allows you to set the scan interval (default: every 360 minutes / 6 hours, minimum: 60 minutes). Since the portals usually only publish new data once a day, frequent polling is not necessary.

📊 Entities & Sensors

The integration creates one device per metering point ("Smart Meter [name]") and the following entities.

Main sensors

• sensor.<meter>_energy_consumption_total (consumption, OBIS 1.8.0, in Wh)
• sensor.<meter>_energy_production_total (production/feed-in, OBIS 2.8.0, in Wh)

Wiener Netze reports cumulative meter readings, so these are total_increasing sensors and can be used with the Home Assistant energy dashboard directly.

Netz Niederösterreich only exposes the consumption of a period, not the cumulative meter reading, so that provider gets a Daily Consumption sensor instead (also in Wh, state_class: total).

E-Werk Gösting gets a Consumption Latest Day sensor instead - the total of the latest day that counts as final, from 12:00 of the following day on - without a state class: its values reach the long-term statistics with their real timestamps, as the statistic <device> Consumption that its Energy dashboard uses. Its diagnostic Latest Data timestamp shows how far the data that counts reaches (see E-Werk Gösting above).

Statistics

• sensor.<meter>_consumption_yesterday
• sensor.<meter>_consumption_day_before_yesterday

Diagnostics & info

• Metering point ID (Zählpunktnummer)
• Customer ID (Geschäftspartner)
• Address (full address string)
• Detailed address (street, ZIP, city, stair, door as individual entities)
• Market ready status
• Contract active status

🐛 Troubleshooting & Debugging

If you encounter issues or no data is being returned, enable debug logging in your configuration.yaml to see exactly what the API returns:

logger:
  default: info
  logs:
    custom_components.asm: debug

After a restart, check the Home Assistant logs for detailed output. You can also download the diagnostics file from the integration page, which contains the (credential redacted) config entry and the last received payload.

"No metering points (contracts) found in this account" – the login worked, but the portal account has no active contract, or the account is not enabled for the smart meter portal yet.

"Connection failed" – the portal could not be reached, or it answered with something that was not JSON (for example an HTML error page). The debug log contains the HTTP status code and a snippet of the response.

"energiedaten.at: no data for … between … and …" – the API answered the window without a single record. That is a platform-side statement, not a failure of the integration: the metering point's consent is not connected yet, or the grid operator has not delivered that period. Integrations → API Keys and the smart meter page of the energiedaten.at dashboard tell you which of the two it is.

"energiedaten.at: the data window … was truncated …" – a warning, not an error: the window held more records than the server returns in one response, and the integration resumed it with the cursor the API sent. The daily total stays complete unless the log says it carried no cursor.

Netz Niederösterreich: "check username and password" – the portal rejected the session (HTTP 401/403) or answered the login with success: false. The portal's own login page in a browser is the quickest way to tell a wrong password from an account that has no smart meter portal access yet.

Netz Niederösterreich: "returned a non-JSON response" – the portal answered a data request with something that was not JSON, which is its way of saying that the session is not established. With 1.2.1 and newer this can no longer happen during setup: the login endpoint's body is no longer required to be JSON. Please report it if you still see it.

📝 Changelog

The full history of this integration is in CHANGELOG.md.

1.2.1

• The energiedaten.at provider reads data again (issue #6). The adapter sent an obis_codes[] filter that the documented data endpoint does not have, and asked for one hard-coded day per poll. A poll now reads the last seven days in one request - from, to and the order parameter the platform's own Home Assistant integration sends - follows the is_truncated/next_cursor pagination of the server's record cap, selects the OBIS codes client-side, and reports the newest day that actually carries readings. It also prefers the meter-wide total (G.01) over the grid figure (P.01), as the platform's own analyses do, instead of the other way round. A "no data" log line now names the whole window that was read, and every reading carries the day it belongs to.
• The Netz Niederösterreich setup no longer fails at the login (issue #5). The portal answers POST /orchestration/Authentication/Login with HTTP 200 and an empty body while it sets the session cookie; requiring JSON of that body made every setup attempt fail with returned a non-JSON response (HTTP 200): ''. HTTP 200 is now accepted as the success it is - only a non-200 status, a 401/403 or an explicit {"success": false} is a failed login - and an unauthenticated data call is reported as a credentials problem instead of a connection problem, so the config flow shows the right message. The metering point endpoints are asked with context=2, the context both independent third-party clients of this portal use, and a meter that is in an energy community no longer has its own record and its community records summed up together.
• E-Werk Gösting - the customer portal on mein-portal.at, read with the portal account's e-mail address and password. Every active Anlage of the account becomes a device with the consumption of the latest day that counts as final, in Wh (Consumption Latest Day), and a Latest Data timestamp that tells how far that data reaches. A day counts from 12:00 of the following day on, because while the portal publishes a day in the morning, its values can still change. The portal publishes a day's values on the next day, so the 15-minute values go into Home Assistant's long-term statistics with their real timestamps: hourly, as the statistic <device> Consumption for the Energy dashboard, with the whole history from the contract start on the first poll. The settled days among the last four days are compared with what was imported and corrected when the portal changed a value, and a refresh at 12:05 fetches yesterday's values, independent of the scan interval. Production (feed-in) values follow the portal's channel naming but have not been verified with a feed-in Anlage yet. The values are the data behind the portal's own export: against the live portal, the integration reads the same quarter hours with the same values as the portal's .xlsx export, and this was verified on payloads captured from the live portal for both DST days. Energy-community channels are not read. A portal update that changes the login is followed automatically.
• Long-term statistics for late data - readings that carry a statistic ID are imported into the recorder as external statistics (asm:…) with their real timestamps, and their sensors compile no statistics of their own. Every poll compares its own values with the imported hours and corrects those that changed, with continuous sums. A reading that holds values back until a moment (settles_at) gets one refresh five minutes after it. The manifest lists the recorder as an after-dependency.

1.2.0

The first stable 1.2.x release. On top of the 1.2.0-beta.1 foundation (Home Assistant 2026.9 compatibility, the repaired Netz Niederösterreich login, brand images) it adds six providers to one integration:

• energiedaten.at - an API platform that republishes Austrian smart meter data. Configured with an API key; its 15-minute interval readings are summed up per local day.
• energyLIVE (smartENERGY) - meter reader hardware with an API key, reporting cumulative meter readings (1.8.0/2.8.0) and the current power in W.
• DSMR / P1 customer interface - the meter's own interface, read over a serial cable or a network P1 reader, encrypted meters included (twelve DSMR dialects, among them the Austrian Sagemcom T210-D-R).
• aWATTar market prices - the public EPEX day-ahead feed of Austria and Germany in ct/kWh, which is what makes load shifting automatable. No account required.
• Selectra tariff planning - the tariff a household actually pays, with its time bands and its feed-in price. Commercial API with a personal token and a free tier of 60 calls per month, which the adapter spends carefully.
• Salzburg Netz - the grid operator's own POST-only interface with 15-minute load profiles, read with an API key from the service portal plus the customer number. One request per metering point per day.

The providers that are not grid operators (energyLIVE, energiedaten.at, aWATTar, Selectra) and the APIs that could not be checked against a live service (energiedaten.at, Selectra, Salzburg Netz) say so in their section above.

Requirements: Home Assistant 2026.9 or newer.

1.2.0-beta.1

• Fixed the Netz Niederösterreich login (issue #1): the login endpoint was misspelled, so every setup attempt failed. The client now also reports a readable error instead of Expecting value: line 1 column 1 (char 0) when the portal answers with HTML.
• Netz Niederösterreich now uses the current metering point endpoint, with an automatic fallback to the older two step API.
• Netz Niederösterreich consumption values are read from the current API shape and converted from kWh to Wh.
• Compatibility with Home Assistant 2026.9: the coordinator is stored in entry.runtime_data, the config/options flow uses ConfigFlowResult and the read only config_entry property, and the manifest declares integration_type.
• Added integration brand images (icon and logo, light and dark).
• Added a documentation wiki with an Architecture Design Document, a Software Design Document and workflow diagrams, and archived the pre-2026.9 design documentation.
• Added diagnostics support.
• Removed the requests and python-dateutil requirements, they are provided by Home Assistant Core.
• Fixed the integration name typo and several documentation issues.

🗺️ Roadmap

Item	State
Stromnetz Graz - grid operator	🚧 in development
e-netze.at	💡 proposed
Salzburg Netz - the readings, consumption and partner categories	💡 open
E-Werk Gösting - feed-in Anlagen verified against a real one	💡 open
energiedaten.at - reporting the community share next to the total	💡 open

Ideas, providers and pull requests are welcome. The provider guide walks through everything a new provider needs, and the issue tracker is the place for what is missing.

🙏 Acknowledgements

• energiedaten.at publishes the API contract the energiedaten.at provider follows and ships its own Home Assistant integration. The window parameters, the cursor pagination and the client-side OBIS selection of this adapter are aligned with it.
• The Netz Niederösterreich portal has no published API. Its login contract was pinned down with the two independent implementations that talk to the same endpoints, TobiKr/hass-NetzNOESmartMeter and schue30/NetzNoe-SmartmeterPortal-Api.
• The brand images are built from this project's own banner, austria_smartmeter.jpg.

⚠️ Disclaimer

This is a private community project and is not officially affiliated with Wiener Netze, Netz Niederösterreich (EVN) or any other grid operator. Use at your own risk. The provider APIs may change at any time.

📄 License

GNU General Public License v3.0 — the licence the LICENSE file of this repository ships.