Strompriser

Strompriser is a robust microservice to fetch and process Norwegian electricity prices.

The goal of Strompriser is to be a robust microservice to fetch and process Norwegian electricity prices, particularily for custom smarthome systems. The day-ahead price data can for example be used to optimize energy usage to the cheapest hours.

The upstream APIs used for prices have historically been unreliable for personal use. To solve this, Strompriser has support for multiple price sources, with automatic fail-over. It supports Nord Pool, and the ENTSO-E Transparency Platform (requires API key). The collected market data must then be processed to a universal data structure, currency, and timezone. Norges Bank's API is used to convert from Euros to Norwegian Kroner. Strompriser always delivers prices in NOK/kWh.

Strompriser exposes an HTTP API for other applications to receieve the processed data from. The API responses are in JSON and easy to work with. The exposed API is versioned, and no breaking changes will be made to existing versions. No authentication is implemented in Strompriser itself as there are numerous methods of authentication. This is trivial for users to implement using reverse proxies, and authentication would add unnecessary complexity to the software. There is also no graphical user interface implemented due to the scope of the project. Complexity could directly reduce the robustness of the service, undermining the primary goal. These scope constraints are similar to those of microservices. The microservice architecture is also beneficial to security, as the electricity price fetcher is unable to access user data.

Users of Home Assistant or those outside of Norway, might be better of using the ge-spot project. It has the same relibability features, but also integrates with Home Assistant and is not specific to Norway.

Deployment

Strompriser will attempt to bind to port 3000. If that is not possible, it will exit with an error. The software is designed to be ran inside virtual or containerized environments like Docker, which allows re-mapping the port.

Compiling

Cross-compiling to Raspberry Pi 3:

cross build --target armv7-unknown-linux-musleabihf --release

General configuration

Configuration Option	Environment variable	Value type
Delivery areas to fetch and push data for. REQUIRED	STROMPRISER_DELIVERY_AREAS	Comma seperated list of areas (e.g NO2,NO3)

Price sources

Nordpool the preferred price source, and does not require any configuration. ENTSO-E is available and recommended as a failover, but requires an API key. API keys are given for free to those who apply following their guide.

Configuration Option	Environment variable	Value type
ENTSO-E API key	STROMPRISER_ENTSOE_API_KEY	UUID of API key, sometimes refered to as "security token"

Taxes and fees

There are several taxes and fees in electricity costs. These are regularily updated, so configuration options let the administrator change them without updating the software. The fees are applied as follows:

1. Electricity price
2. Fees
   • Energy tax ("Energiledd")
   • Consumption tax ("Forbruksavgift")
3. VAT ("mva")
   • Not in NO4

Configuration Option	Environment variable	Value type
Energy tax daytime override	STROMPRISER_ENERGY_TAX_DAY	Float NOK/kWh
Energy tax nighttime override	STROMPRISER_ENERGY_TAX_NIGHT	Float NOK/kWh

Design decisions

Strompriser attempts to fetch prices using the enabled datasources in order until the entire day is fetched. If all datasources fail, retry later.

Timezone is generally in Europe/Oslo in as much as the program as possible. In locations this is not possible, such as for interacting with upstream APIs, UTC is used instead. Timezone handling is based on the IANA database using the chrono_tz crate. During compilation it is made sure that only Norwegian timezones are compiled in order to reduce binary size and compilation time.

Testing

To ensure a robust and consistent experience with as few bugs as possible, Strompriser is developed with a suite of unit tests and integration tests. googletest is used as assertion library. It is recommended to use nextest to execute the tests, however cargo test can also be used.

A combination of unit tests and integrations tests is used. The unit tests test a standalone function or piece of code. These tests are located in the bottom of sourcecode files. The most important tests are the integration tests, these test the software in action, what actually happens. Integration tests are located in the /test folder of the project.