[FEATURE] Support Separate Import and Export Electricity Prices

[depeter2]

Area of the proposal

Energy management or control strategy

What problem would this solve?

In the Netherlands, the net metering scheme (salderingsregeling) will end on January 1, 2027. This fundamentally changes the economics of charging and discharging a home battery.

From that date, the actual import price paid for electricity consists of:

market price + supplier/import fee + energy tax + VAT

When exporting electricity to the grid, the compensation is different:

market price (including VAT) - supplier/export fee

The energy tax is therefore no longer recovered when electricity is exported.

This creates a significant and structural difference between the price of importing electricity and the value of exporting it. The difference can be much larger than the supplier's import/export fee alone.

For battery control, this distinction is important. A battery should not necessarily charge when the market price is low and discharge when the market price is high. The relevant question is the actual economic cost of importing electricity versus the actual value of exporting electricity.

Using a single electricity price sensor for both directions makes it difficult for Omnibattery to make the correct economic decisions in this situation.

Proposed solution

Introduce separate sensors/entities for:

Electricity import price — the actual all-in price paid when importing electricity from the grid.
Electricity export price — the actual compensation received when exporting electricity to the grid.

Omnibattery could then use these two values independently in its energy management and charge/discharge strategy.

Ideally, the sensors should be configurable or supplied by the Home Assistant integration/provider, since taxes, VAT and supplier fees can vary between countries and energy contracts.

This would also make the solution future-proof for other markets where import and export prices differ.

Example use case

For example, assume a dynamic market price of €0.10/kWh excluding VAT, with an import fee of €0.01/kWh and an export fee of €0.01/kWh.

Using the current Dutch electricity tax as an illustrative example:

Import price:

Market price: €0.1000/kWh
Import fee: €0.0100/kWh
Energy tax: €0.09161/kWh
Subtotal excluding VAT: €0.20161/kWh
21% VAT: €0.04234/kWh
Actual import price: €0.24395/kWh

Export price:

Market price: €0.1000/kWh
21% VAT: €0.02100/kWh
Market price including VAT: €0.12100/kWh
Export fee: €0.0100/kWh
Actual export value: €0.11100/kWh

This means that the same kWh has an import cost of approximately €0.244/kWh, but an export value of only €0.111/kWh.

The difference is therefore approximately €0.133/kWh.

Who would benefit from this?

Most Omnibattery users

Alternatives or workarounds

A workaround is to create custom template sensors in Home Assistant that calculate the import and export prices separately and then try to make Omnibattery use those values.

However, this requires users to implement their own calculations and there is currently no clear way to provide Omnibattery with two independent prices for its energy management strategy.

Additional context

This is becoming particularly relevant in the Netherlands because the salderingsregeling ends on January 1, 2027.

I believe separate import and export price sensors would provide a much better foundation for future battery optimization strategies, not only for the Dutch market but for any country or energy contract where buying and selling electricity have different effective prices.

Confirmations

• I searched existing discussions and did not find the same proposal.
• This is a general feature idea, not a request to support a new battery brand or model.
• I understand that community interest and technical feasibility influence prioritization, and that no delivery date is guaranteed.
• I removed passwords, tokens, API keys, complete serial numbers, IP addresses, and other sensitive information.

[github-actions[bot]]

Thanks for the suggestion! 🙌

Here's how this works:

• Vote by clicking 👍 on the original post — not in the comments
• The more votes an idea gets, the higher it moves in the priority queue
• I review feature ideas periodically and implement the ones that benefit the most users

If your idea is very specific to your setup, it may not make it into the core integration — I'll try to suggest a workaround in that case.

Feel free to discuss details or alternatives below.

[alainsch]

If I understand the feature request correctly: this is already the case in Belgium for a few years. We have in the "fixed rate" or "variable rate" contracts, depending on the energy supplier, up to 4 different rates, prices per kW:

• consumption in T1 tariff
• consumption in T2 tariff
• injection in T1 tariff
• injection in T2 tariff

T1 = weekdays from 07:00 - 22:00
T2 = all the other timeslots...

Our energy meter has a telegram to tell in with tariff mode we are now.

[depeter2]

I think the situation in Belgium is quite similar to The Netherlands. We have fixed and variable price electricity contract choices as well.

The major change is the end of net metering (saldering) per 1-12027. Until now, the electricity you imported and exported could effectively be offset against each other. Once net metering disappears, that is no longer the case.

There is also an important additional factor: energy taxes are charged on electricity imported from the grid, but you don't get those taxes back when you export electricity. This creates a substantial difference between the price you pay for importing electricity and the compensation you receive for exporting it — at least around €0.11/kWh, depending on your energy contract.

That is why, for us, treating import and export prices as separate values is becoming important. Optimising the battery based on a single electricity price source (e.g. Nordpool) simply doesn't reflect the actual economics anymore.

[alainsch]

Exactly, that’s what happened here in Belgium a few years ago when the "terugdraaiende teller" (net metering) was phased out. Prior to that, injected power was subtracted 1-to-1 from consumption.

Today, you pay the full rate for imported power (energy cost, transmission, taxes, and VAT), while the feed-in compensation is only a fraction of the raw energy cost — roughly one-third.

To give you a real-world example from my current contract:

• Import (peak): 25.14 ct/kWh (all in)
• Import (off-peak): 21.09 ct/kWh (all in)
• Export (injection): 6.02 ct/kWh (flat rate all day)

Treating import and export prices separately is indeed the only way to model battery optimization accurately here.

[rrozema]

I created several automations and other scripts that build a battery strategy on this principle. Many of the scripts, including ones that implement, use and build on the sensors you describe here, are in my request #237.
I think however the price sensors you propose here were better put into a separate integration so that they can be re-used for other purposes too, not just battery charging/discharging strategies. Have a look for example at my power dashboard in that same feature request. It a.o. keeps track of the price for energy used (derived from import, export and battery prices) and also the ratio for the sources used to produce the used energy.

[depeter2]

What you describe in request [https://github.com//discussions/237] is exactly what I am looking for. I have 15kWh battery capacity. My house consumes about 10kWh daily and my solar panels produce up to 25kWh on sunny days. I have a dynamic pricing energy contract (PowerPeers) with quarterly changing prices. The optimal charge and discharge strategy would be discharge the overproduction when the dynamic price is at maximum and prevent needing electricity import from the grid. (espescially from 1-1-2027 onwards).
During wintertime my strategy needs to be different. I have a hybride heat pump and my electricity consumption increases up to 30 kWh. Here I need an opposite strategy to charge the batteries at the lowest price (most likely during night) and discharge over the heat pump when the price is high. (And there is another trade-off choosing between heating with the gas boiler or with the heat pump, depending on efficiency and total costs)
If the OmniBattery team could implement an optimization like this, I would be very happy.

[ffunes]

Hi,

Thanks for the additional examples from Belgium and the Netherlands. I will implement separate import and export electricity prices in Omnibattery 1.5.0.

The intended model is two optional price inputs:

• Import price: the all-in price paid when buying energy from the grid.
• Export price: the compensation received when sending energy to the grid.

Existing single-price configurations will remain compatible through a fallback.

Before I finalize the implementation, could you please confirm:

1. Should both values be all-in prices, including taxes, VAT and supplier fees, expressed as positive currency/kWh values?
2. Do your providers expose future hourly or 15-minute prices for both directions, or would separate forecast entities be required?
3. What should happen when only one price is available: fail safe for the affected strategy or fall back to the current single-price behavior?
4. For fixed or dual tariffs, should Omnibattery consume already-calculated tariff entities, or should it model tariff periods itself?

This will allow me to define the backward-compatible behavior correctly.

[depeter2]

Having thought about this a bit more, I believe there may be an even simpler solution than introducing a separate export price sensor.

The existing electricity price sensor could simply be treated as the import price. In my case, I have configured Nord Pool so that this sensor already represents the all-in import price, including taxes, VAT and supplier surcharges.

The export price is effectively the same price with a (negative) offset. If Omnibattery could provide a configurable parameter for this offset, I think that would achieve the desired result in a much simpler and more flexible way.

For example:

• Import price = current electricity price sensor
• Export price = current electricity price + export price offset
• Offset = 0 → import and export prices are identical
• Offset = -€0.15/kWh → export price is €0.15/kWh lower than the import price

I actually think this may be preferable to introducing a separate export price sensor. Otherwise, Omnibattery becomes more dependent on what individual energy providers expose through their integrations. So far, I have seen no providers that actually provide separate import and export prices.

This approach would also work equally well for fixed-price tariffs and, importantly, would be fully backwards compatible. Existing configurations would simply use an offset of 0, meaning that import and export prices remain identical.

So, on further consideration, I think a configurable export-price offset might be the simplest and most robust solution.

[rrozema]

I would still like to ask for selecting 2 separate price sensors. That way everyone can have their own implementation of how to determine the export price when only an import price is available. Or maybe some utilities/integrations are going to provide those export prices in a separate sensor too, just like they do with the import price now.