Bringing electricity information from eloverblik.dk and energidataservice.dk into Openhab

[laursen (Jacob Laursen)]

@somy

I don’t seem to get value for the below item, it says “UNDEF”:

Number NetTariff "Current Net Tariff" <price> (TotalPrice) { channel="energidataservice:service:energidataservice:electricity#net-tariff" [profile="transform:VAT"] }

My things configuration below:

Thing energidataservice:service:energidataservice "Energi Data Service" [ priceArea="DK2", currencyCode="DKK", gridCompanyGLN="5790000705689" ] {
    Channels:
        Number : electricity#net-tariff [ chargeTypeCodes="DT_C_01", start="StartOfMonth" ]}

You do not need to configure this filter manually, the binding comes with pre-configured filters, also for Radius. If you remove the channel configuration, it should work. The start parameter is wrong since it will exclude records still valid, but starting before the beginning of current month. The pre-configured filter has 2023-01-01 as cutoff date.

You can also see this in the records you receive - they are only valid in the future:

ChargeOwner	GLN_Number	ChargeType	ChargeTypeCode	Note	Description	ValidFrom	ValidTo	VATClass	Price1	Price2	Price3	Price4	Price5	Price6	Price7	Price8	Price9	Price10	Price11	Price12	Price13	Price14	Price15	Price16	Price17	Price18	Price19	Price20	Price21	Price22	Price23	Price24	TransparentInvoicing	TaxIndicator	ResolutionDuration
Radius Elnet A/S	5790000705689	D03	DT_C_01	Nettarif C time	Nettarif C time	01/10/2024		D02	0,1509	0,1509	0,1509	0,1509	0,1509	0,1509	0,4528	0,4528	0,4528	0,4528	0,4528	0,4528	0,4528	0,4528	0,4528	0,4528	0,4528	1,3584	1,3584	1,3584	1,3584	0,4528	0,4528	0,4528	0	0	PT1H
Radius Elnet A/S	5790000705689	D03	DT_C_01	Nettarif C time	Nettarif C time	01/04/2024	01/10/2024	D02	0,1509	0,1509	0,1509	0,1509	0,1509	0,1509	0,2264	0,2264	0,2264	0,2264	0,2264	0,2264	0,2264	0,2264	0,2264	0,2264	0,2264	0,5887	0,5887	0,5887	0,5887	0,2264	0,2264	0,2264	0	0	PT1H

A potential feature request if you don’t mind: today I created 48 items grouped in Today and Tomorrow groups, and I update total prices when they become available. Then every night I copy Tomorrow prices to Today and set Tomorrow price to empty (please see the screenshot below).

I would need to understand your use-case to comment on that. What I can say is that having this amount of items is bad design and will not be implemented in the binding. Most likely this was “invented” to work around the lack of timestamped states. In 2025 we should start receiving spot prices in intervals of 15 minutes. Then what - 192 items that will be rotated every 15 minutes? I can’t even wrap my head around how to use that for calculations.

This pull request will probably pave some of the way:

Allow sending historic states and forecasts

I recently renamed all channels to prepare for supporting time series (e.g. from current-spot-price to just spot-price).

For now, instead of using the serialized JSON content, you could also simply use the thing action getPrices for retrieving all the prices in a rule. This will also perform much better.

Perhaps some of the thing actions could be helpful for some of your use-cases, for example if you need to calculate periods with lowest prices.