Time series support for Group items

[jlaur]

See #3597 (comment)

Currently bindings can publish time series for channels. Transformation Profiles are supported as well.

I don't know if it would be possible to extend time series support to Group items as well, since they can also be persisted?

Example configuration:

Group:Number:SUM EnergiDataService_TotalPrice "Total [%.2f DKK]" <price>

Number EnergiDataService_SpotPrice "Spotpris [%.2f DKK]" <price> (EnergiDataService_TotalPrice) { channel="energidataservice:service:energidataservice:electricity#spot-price" [profile="transform:VAT"] }
Number EnergiDataService_NetTariff "Nettarif [%.2f DKK]" <price> (EnergiDataService_TotalPrice) { channel="energidataservice:service:energidataservice:electricity#net-tariff" [profile="transform:VAT"] }
Number EnergiDataService_SystemTariff "Systemtarif [%.2f DKK]" <price> (EnergiDataService_TotalPrice) { channel="energidataservice:service:energidataservice:electricity#system-tariff" [profile="transform:VAT"] }
Number EnergiDataService_ElectricityTax "Elafgift [%.2f DKK]" <price> (EnergiDataService_TotalPrice) { channel="energidataservice:service:energidataservice:electricity#electricity-tax" [profile="transform:VAT"] }
Number EnergiDataService_TransmissionNetTariff "Transmissionsnettarif [%.2f DKK]" <price> (EnergiDataService_TotalPrice) { channel="energidataservice:service:energidataservice:electricity#transmission-net-tariff" [profile="transform:VAT"] }

Here EnergiDataService_TotalPrice represents the total price. Unfortunately time series are not supported, so the future total price cannot be persisted.

Historical values can currently be shown in a sitemap chart like this:

Text item=EnergiDataService_TotalPrice {
    Chart item=EnergiDataService_TotalPrice forceasitem=true refresh=60000 period=D
}

[J-N-K]

But isn't the group correctly updated when the member states are restored?

[jlaur]

But isn't the group correctly updated when the member states are restored?

Indeed it is. I'm wondering if it would also be possible to have the group receive time series and create a new time series, similar to what TimeSeriesProfile does for profiles? I realize it would be more complex, since it would have to "replay" received time series for all related children. E.g.:

Group:Number:SUM SumGroup
Number Item1 (SumGroup) { channel="acme:acme:channel1 }
Number Item2 (SumGroup) { channel="acme:acme:channel2 }

Events:

• Now: 12.11.2023 20:00;00
• channel1 has state 1.
• channel2 has state 0.
• acme binding publishes time series for channel1:
  • 12.11.2023 20:30:00 2
  • 12.11.2023 20:45:00 3
  • 12.11.2023 21:00:00 4
• acme binding publishes time series for channel2:
  • 12.11.2023 20:20:00 10
  • 12.11.2023 20:35:00 20
  • 12.11.2023 20:50:00 30

As a result, the following time series would be produced and published for item SumGroup:

• 12.11.2023 20:20:00 11
• 12.11.2023 20:30:00 12
• 12.11.2023 20:35:00 22
• 12.11.2023 20:45:00 23
• 12.11.2023 20:50:00 33
• 12.11.2023 21:00:00 34

I guess this would have been easier achievable with a closer state integration, i.e. #3597 (comment) - if the magic happens only when reaching the event bus?

[J-N-K]

I still fail to see what the use-case would be? Calculating future states is extremely difficult, because it needs to be re-done every time a single value for any item in the group has changed.

[jlaur]

I still fail to see what the use-case would be?

It's in the description, and some reasoning for not providing a "total price" channel from the binding is here:
https://www.openhab.org/addons/bindings/energidataservice/#channel-group-electricity

At least, at the time it seemed elegant to use the Group SUM aggregate function for this because it already existed and it removed a lot of complexity from the binding itself.

Now, it would be cool to be able to create a chart of the future total price. With #3896 it would be possible to create a rule for calculating this instead of using a Group, but it still feels like it would be more elegant simply having the Group do the work without any rules needed.

Calculating future states is extremely difficult, because it needs to be re-done every time a single value for any item in the group has changed.

Yeah, I came to the same realization when I created the example above in my previous post. 😓

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/bringing-electricity-information-from-eloverblik-dk-and-energidataservice-dk-into-openhab/143470/101