aWATTar binding: Beta and discussion

christoph_kowatschik · April 21, 2023, 8:49am

Thanks for the tip with evcc.io … looks like it would also cover PV charging which for the time beeing I have not really touched …
Currently I calculate hours needed when I plug in my car (with normal SOC 80% or 100% if I have a business trip planned) only for night loading
I will just double the things and select if I want to have it loaded until 6oclock or until 15:00 … will cover 95% of my use cases …

aMUSEd · March 25, 2024, 3:07pm

@Wolfgang1966 Thanks for this very useful binding. I would like to persist the data in a variable with timeseries support for visualization-support in grafana.
Would you please be so kind and add some functionality like the energidataservice (openhab-addons/bundles/org.openhab.binding.energidataservice/README.md at 2a72e1cab70ffb48047017340f0405f924b6c455 · openhab/openhab-addons · GitHub) provides:

" Persisting Time Series
The binding offers support for persisting both historical and upcoming prices. The recommended persistence strategy is forecast, as it ensures a clean history without redundancy. Prices from the past 24 hours and all forthcoming prices will be stored. Any changes that impact published prices (e.g. selecting or deselecting VAT Profile) will result in the replacement of persisted prices within this period."

That would make your binding working for me perfectly.

Br Thomas

Wolfgang1966 · April 1, 2024, 8:58am

Hi @aMUSEd ,

I read about this persistence some time ago, and of course it would be the correct one to use for the aWATTar binding now as it is available. However, I am not sure about the future of the aWATTar binding at all. There is a far more general solution available with the Entso-E binding, so I think on the long run it will be a successor of the aWATTar binding. This binding also seems not to use the TimeSeries persistence yet, but making it available there would provide a solution for many european energy markets instead of only Austria and Germany. So if I have spare time I think I will use it to assist there instead of further maintaining the aWATTar binding.

aMUSEd · April 2, 2024, 12:39pm

Hi Wolfgang,
sorry to hear that. The Entso-E binding does not gives us all the outstanding capabilities like least cost calculation for configurable timeslots and cost offsets like aWATTar handles the gross pricing. Hopefully you will find some time to enhance this binding to make it as comfortable as your aWATTar binding is.
Br Thomas

tiboth · July 31, 2024, 5:48am

Simple solution to plot daily aWATTar prices on a chart

config:
  chartType: day
  future: true
  label: Prices_today
  sidebar: true
slots:
  grid:
    - component: oh-chart-grid
      config:
        show: true
  series:
    - component: oh-data-series
      config:
        data:
          - value: =items.Today00.state
          - value: =items.Today01.state
          - value: =items.Today02.state
          - value: =items.Today03.state
          - value: =items.Today04.state
          - value: =items.Today05.state
          - value: =items.Today06.state
          - value: =items.Today07.state
          - value: =items.Today08.state
          - value: =items.Today09.state
          - value: =items.Today10.state
          - value: =items.Today11.state
          - value: =items.Today12.state
          - value: =items.Today13.state
          - value: =items.Today14.state
          - value: =items.Today15.state
          - value: =items.Today16.state
          - value: =items.Today17.state
          - value: =items.Today18.state
          - value: =items.Today19.state
          - value: =items.Today20.state
          - value: =items.Today21.state
          - value: =items.Today22.state
          - value: =items.Today23.state
        gridIndex: 0
        name: Price
        type: bar
        xAxisIndex: 0
        yAxisIndex: 0
  xAxis:
    - component: oh-category-axis
      config:
        categoryType: day
        gridIndex: 0
  yAxis:
    - component: oh-value-axis
      config:
        gridIndex: 0
        name: Price/ct
  tooltip:
    - component: oh-chart-tooltip
      config:
        show: true
        formatter: "{c}"

Wolfgang1966 · August 2, 2024, 8:28am

Just to let you know: TimeSeries Support is about to be added to the aWATTar binding now by @J-N-K here: [awattar] Add TimeSeries support by J-N-K · Pull Request #17172 · openhab/openhab-addons · GitHub. So stay tuned

aMUSEd · August 23, 2024, 10:50am

Hi,

with the upgrade from 4.2.0 to 4.2.1 the addon fetches the prices and delivers the value to the configured items for the best-price calculation.
This works from 2 p.m. until 0 a.m. With 0 a.m. the timeslots and the switches are set to UNDEF and therefore do not work until 2 p.m.
Does experience anyone else such an issue?

Br Thomas

chris4789 · August 23, 2024, 12:18pm

Yes, I can confirm that, same behavior here.

aMUSEd · August 23, 2024, 12:25pm

I just opened a bug report - [aWATTar] Bestprice items are set tu UNDEF at 0 a.m. · Issue #17316 · openhab/openhab-addons · GitHub

Klaus_Schuster · September 16, 2024, 6:07am

has anyone a workaround for that problem? I just saved the hours, and use them if UNDEFINED is represented.

Wolfgang1966 · September 16, 2024, 6:34am

@tl-photography @J-N-K Can you have a look at this? Is it maybe related to your last changes to the binding?

tl-photography · September 20, 2024, 3:52pm

FYI, the discussion of the UNDEFINED topic should be continued on the linked issue.
A workaround is available and we are going to investigate this.

github.com/openhab/openhab-addons

[aWATTar] Bestprice items are set to UNDEF at 0 a.m.

opened 12:24PM - 23 Aug 24 UTC

aMU5Ed

bug

## Expected Behavior Best Price items should be recalculated when the new price…s are fetched from the aWATTar API ## Current Behavior With the upgrade from 4.2.0 to 4.2.1 the addon fetches the prices and delivers the value to the configured items for the best-price calculation. This works from 2 p.m. until 0 a.m. With 0 a.m. the timeslots and the switches are set to UNDEF and therefore do not work until 2 p.m. ## Possible Solution Best Price items should be recalculated when the new prices are fetched from the aWATTar API ## Steps to Reproduce (for Bugs) 1. Items are properly filled at 2 p.m. 2. Wait for 0 a.m. ;-) ## Context Bestprice calculation ## Your Environment Raspberry Pi 4 8GB Ubuntu 24.04 LTS zulu Java 17.46.19 aarch64 OpenHab 4.2.1 Release build

Quautiputzli · November 18, 2024, 2:17pm

Hello @Wolfgang1966
I saw in the logging, that there ist a update on each price channel every minute. Is this really necessary? Because the value will only change once a day. There are a lot unnecessary data in the logging:

2024-11-18 15:14:00.019 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'aWATTarHourlyPrice_Today00_Totalgross' updated to 7.78
2024-11-18 15:15:00.018 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'aWATTarHourlyPrice_Today00_Totalgross' updated to 7.78
2024-11-18 15:16:00.034 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'aWATTarHourlyPrice_Today00_Totalgross' updated to 7.78

Wolfgang1966 · November 29, 2024, 12:14pm

Hi @Quautiputzli that looks strange. In my logs I see no updates but only changes:

2024-11-28 16:00:00.015 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 34.04 to 36.02
2024-11-28 17:00:00.018 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 36.02 to 37.08
2024-11-28 18:00:00.013 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 37.08 to 36.57
2024-11-28 19:00:00.007 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 36.57 to 35.39
2024-11-28 20:00:00.017 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 35.39 to 34.02
2024-11-28 21:00:00.019 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 34.02 to 32.79
2024-11-28 22:00:00.022 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 32.79 to 31.65
2024-11-28 23:00:00.012 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 31.65 to 31.38
2024-11-29 00:00:00.010 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 31.38 to 30.99
2024-11-29 01:00:00.007 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 30.99 to 30.57
2024-11-29 02:00:00.007 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 30.57 to 30.49
2024-11-29 03:00:00.011 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 30.49 to 30.79
2024-11-29 04:00:00.008 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 30.79 to 31.97
2024-11-29 05:00:00.018 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 31.97 to 35.52
2024-11-29 06:00:00.013 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 35.52 to 38.40
2024-11-29 07:00:00.011 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 38.40 to 39.84
2024-11-29 08:00:00.007 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 39.84 to 37.59
2024-11-29 09:00:00.003 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 37.59 to 35.27
2024-11-29 10:00:00.007 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 35.27 to 34.49
2024-11-29 11:00:00.007 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentPrice' changed from 34.49 to 33.32

In principle the binding triggers an update every minute to update the countdown values. But I wonder where that logging comes from.