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

[aMU5Ed]

Expected Behavior

Best Price items should be recalculated when the new prices 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

[openhab-bot]

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

https://community.openhab.org/t/awattar-binding-beta-and-discussion/110497/111

[cybermcm]

I can confirm this, would really appreciate the desired behavior described in OP

[aMU5Ed]

@J-N-K could you please assign the bug to the maintainer of this add-on?

[Wolfgang1966]

Last changes were done by @tl-photography, as far as I am aware of.

[tl-photography]

Hi,

the refresh handling of 4.2.1 is still the "old" way: https://github.com/openhab/openhab-addons/blob/4.2.1/bundles/org.openhab.binding.awattar/src/main/java/org/openhab/binding/awattar/internal/handler/AwattarBridgeHandler.java#L182

My fix with more refreshes during the day will be probably included in the next release: https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.binding.awattar/src/main/java/org/openhab/binding/awattar/internal/handler/AwattarBridgeHandler.java#L186

The current handling should be once the bridge signals a refresh recalculate. But only at 1500 or when the bridge is reloaded.

[tl-photography]

@aMU5Ed can you share your bridge config?

[cybermcm]

@tl-photography: I've the same problem, values get deleted at 0 a.m.
my config:

UID: awattar:bridge:aabbccddee
label: aWATTar Bridge
thingTypeUID: awattar:bridge
configuration:
  country: AT
  vatPercent: 20
  basePrice: 0

[Herschdorfer]

@cybermcm thanks this looks fine. Doe you have also the thing config handy?

[cybermcm]

@Herschdorfer: Do you mean the best price thing?

UID: awattar:bestprice:aabbccddee:6368db731f
label: aWATTar best price
thingTypeUID: awattar:bestprice
configuration:
  length: 3
  rangeDuration: 24
  rangeStart: 0
  consecutive: true
bridgeUID: awattar:bridge:aabbccddee
channels:
  - id: active
    channelTypeUID: awattar:switch-type
    label: Active
    description: Currently activated
    configuration: {}
  - id: start
    channelTypeUID: awattar:start-time-stamp
    label: Starttime
    description: Starting time of period.
    configuration: {}
  - id: end
    channelTypeUID: awattar:end-time-stamp
    label: end-time-stamp
    description: End time of period.
    configuration: {}
  - id: countdown
    channelTypeUID: awattar:countdown-type
    label: Countdown
    description: Time until start of period.
    configuration: {}
  - id: remaining
    channelTypeUID: awattar:remaining-type
    label: Remaining
    description: Time until end of period.
    configuration: {}
  - id: hours
    channelTypeUID: awattar:hours-type
    label: Hours
    description: A list of all hours within this bestprice range
    configuration: {}

[tl-photography]

I have a suspicion, can you change the duration to 23 instead of 24?

[lsiepel]

I think the change is available in 4.3.0 milestone 1 check release notes here:
https://github.com/openhab/openhab-distro/releases/tag/4.3.0.M1

[cybermcm]

@tl-photography: I'll change the value and report back
@lsiepel: yes that will probably solve our problem

[cybermcm]

@tl-photography: changing the duration to 23 hours solved the problem, values are still there today. A useful workaround! Thank you.
Do you know where the problem is located in the source code?

[tl-photography]

I guess the calculations fail because it tries to retrieve from 0:00 to 0:00 the next day, but 0:00 the next day is not yet available.

@J-N-K I would suspect the changes you made with the time series...

[lsiepel]

For my understanding, the issue is fixed in 4.3.0M1 and there is a workaround for 4.2.1 with a 'minor' issue left of 00:00 not being available. If this is true, i suggest to close this issue or to continue wrokaroudn discussion in the community forums as there is nothing left to fix? Does this make sense?

[cybermcm]

@lsiepel: The workaround is OK for now, but I'm not really sure if the underlying problem is really fixed in 4.3.0M1?

[tl-photography]

I'm also not sure if the issue is fixed.
The refresh rework applies only to the API check, not the thing calculation.

I believe the issue is still present in 4.3.0M1.

[openhab-bot]

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

https://community.openhab.org/t/awattar-binding-beta-and-discussion/110497/114

[aMU5Ed]

@aMU5Ed can you share your bridge config?

Sorry for the delay. The flood catastrophe here in austria kept me busy during the last 2 weeks.

Here is my bridge config:
UID: awattar:bridge:a8cd3bb842 label: aWATTar Bridge thingTypeUID: awattar:bridge configuration: country: AT vatPercent: 20 basePrice: 1.5

and here the thing config:
`UID: awattar:bestprice:a8cd3bb842:45bdec81b4
label: aWATTar Bester Preis 3h
thingTypeUID: awattar:bestprice
configuration:
length: 3
rangeDuration: 24
rangeStart: 0
consecutive: true
bridgeUID: awattar:bridge:a8cd3bb842
channels:

• id: active
  channelTypeUID: awattar:switch-type
  label: Active
  description: Kennzeichnet Zeiträume mit günstigen Preisen
  configuration: {}
• id: start
  channelTypeUID: awattar:start-time-stamp
  label: Startzeit
  description: Start der gefundenen Periode
  configuration: {}
• id: end
  channelTypeUID: awattar:end-time-stamp
  label: Endzeit
  description: Ende der gefundenen Periode
  configuration: {}
• id: countdown
  channelTypeUID: awattar:countdown-type
  label: Countdown
  description: Zeit bis zum Beginn der gefundenen Periode
  configuration: {}
• id: remaining
  channelTypeUID: awattar:remaining-type
  label: Verbleibend
  description: Zeit bis zum Ende der gefundenen Periode
  configuration: {}
• id: hours
  channelTypeUID: awattar:hours-type
  label: Stunden
  description: Eine Liste aller gefundenen Stunden mit günstigen Preisen
  configuration: {}`

[tl-photography]

It's the same thing as for @cybermcm. I bet if you change the rangeDuration to 23, all will be good.

[aMU5Ed]

@tl-photography Seems to work(around) :-)

[tl-photography]

I was thinking if this is really a bug or kind of "correct". If a time range of 24 is given from a time of 0:00, then the rang would be always until 0:00 the next day. But these values are not yet defined.

Therefore this is kind of "correct" that the channel goes into "undef". Maybe this should be better documented, but the calculation would be always incorrect when using more than 23 hours, as long as the forecast is 24 hours in the future.

[Wolfgang1966]

In my opinion 24h should work at least for certain definitions. E.g. the range given in your example means the timespan of 00:00 to 23:59:59.999, which is known as soon as the prices for a day are fetched (except for the daylight savings time switch in spring, where the day only has 23 hours, so there will be one day every year where this definition will cause problems :-) ). It will not work well with starting times between 01:00 and 14:00, because there the timespan crosses midnight of the following day and the prices are not available in time. So at times when the binding is able to compute the cheapest hours, it could be that they are already in the past.

[tl-photography]

Alright, that's true there are some cases where it should work. I agree!

But wouldn't then also the recalculation trigger need to be changed? The timespan crossing 0:00 would not be calculated correctly before the next update around 14:00 from the API.

[Wolfgang1966]

Any timespan can only be calculated under the following two conditions:

1. The prices of all hours covered by the timespan are available
2. The previous iteration of the timespan has already passed.
   So timespans starting before 14:00 and crossing midnight do not really make much sense, because they can only be calculated within a part of their time.

I can't remember exactly how I implemented the recalculation originally, but it probably worked this way:

• do I already have current and valid calculated data for the thing? If no then try to calculate it
• did I get new prices since I calculated it? If yes, then recalculate it.
• Is the thing period in the past? If yes, then recalculate it (for the next period).

So overall the calculation originally was done on demand when channels of the things were requested, not when the prices were fetched. I did not check how the code does it now, so I can't tell exactly what (if anything) would need to be changed. So my recalculation "trigger" finally was the request of data from any of the channels.

[asprom]

Hi,

I wanted to calculate e.g. the 10 cheapest hours of a day for the heat pump and used the configuration example from the documentation which defines the timespan from 0 to 24. This has caused the mentioned problem that from midnight to 2 pm the result was undef.

Unfortunately, the hotfix with using 23 as duration is also not fully correct, as it won't select the last hour of a day (23:00 - 00:00) anymore. As an example from today's price level:

If I select the 10 cheapest hours, I would expect 0,1,2,3,4,5,11,12,13,23 but the result from the binding is 0,1,2,3,4,5,11,12,13,22.

As mentioned above, the end time checked by given duration should always be XX:59:59... and not the next full hour. This should also include/fix start=1+ duration=23; start=2+duration=22 and so on.

[asprom]

After a quick look into the code, I might see a change to fix it here, but I didn't find the time to try it out, yet:

openhab-addons/bundles/org.openhab.binding.awattar/src/main/java/org/openhab/binding/awattar/internal/handler/AwattarBestpriceHandler.java

Line 142 in d18df74

if (!(bridgeHandler.containsPriceFor(timerange.start()) && bridgeHandler.containsPriceFor(timerange.end()))) {

I think it should work if the second clause in the if is changed and the timerange.end() is reduced e.g. by one second to move into the previous hour.

[jlaur]

@aMU5Ed, @cybermcm, @asprom - can you try this? org.openhab.binding.awattar-4.3.0-SNAPSHOT.jar

[cybermcm]

@jlaur I'm on 4.2.2, is it safe/OK to use a 4.3.0 jar file?

[jlaur]

@jlaur I'm on 4.2.2, is it safe/OK to use a 4.3.0 jar file?

Let's play it safe, here's a backported version: org.openhab.binding.awattar-4.2.3-SNAPSHOT.jar

[cybermcm]

@jlaur thank you, I'll install it and keep you posted

[cybermcm]

@jlaur: Set "Range duration" back to 24h, tested it from yesterday to today, values are still there! Thank you

[klsystem1]

I am using openhab 4.2.2 with aWATTar Binding 4.2.2.
Is the bug fixed in my version ? if not, how can I update ?
I checked out on github seeing commited to origin/4.2.x
Do I need to wait for a 4.3.x release ?
thanks

[jlaur]

I am using openhab 4.2.2 with aWATTar Binding 4.2.2.
Is the bug fixed in my version ? if not, how can I update ?

No. For now, you can use the version posted here: #17316 (comment)

Do I need to wait for a 4.3.x release ?

The fix will be included in the next 4.2 patch release, but the release date is not yet settled.