binderth
(Thomas Binder)
September 27, 2024, 12:52pm
292
i just filed a feature request/improvement on github:
opened 12:49PM - 27 Sep 24 UTC
enhancement
## Your Environment
* Version used: openHAB 4.2.1-release (openHABian, raspberr… y Pi 4/4GB)
## Problem statement
The "Current Total Price"-channel (`current_total`) refreshes with the configured "Refresh Interval" of the binding.
Therefore it refreshes "randomly" - according to the setting and not "on the hour". If you need all the "cumulative" channels in a long interval it could be, that the current price is only refreshed every 6hours or 25minutes or so. The interval starts not "on the hour", but on the time, the binding is restarted and/or changed are made.
## current behaviour
In my case, I wanted to have the not live-channels refreshed every 25minutes and therefore set the refresh interval accordingly. I did so on minute 3 of the hour, so the interval was started there: 3 - 28 - 53 - 8 - 31 - ... But you will never get the change "on the hour".
## expected behaviour
The current-price is heavily reliant on (at least my) rules. I decide on the current price (and price level, ...) the behaviour of my high-power devices (wallbox, Heating, ...). So I relied on the value of the price is exactly the current one "on the hour". So, I'd like to have a refresh regardless of configuration "on the hour" of all releated channels, which provide information on the "current hour".
## suggested solution
Perhaps the easiest would be to treat the intervall like cron: starting with 0 "on the hour" and then in the configured refresh intervall. In my case of 25 minutes: 0 - 25 - 50 - 0 - 25 - 50 -0 -...
or to additionally refresh every hourly channel on the hour regardless of the configured refresh intervall.
Channels I think should be refreshed on the hour are all the "non-live" ones, currently:
* current_total
* current_startsAt
* current_level
* hourly_from
* hourly_to
* hourly_cost
* hourly_consumption
## bonus
I came across my prolonged refresh interval, because I got spamming events.log, described in https://community.openhab.org/t/oh4-2-tibber-binding-shall-process-timeseries-multiple-logentries/157290
So, as a bonus it would be great, if the binding only logged that INFO, if the price information changed, meaning the first time after 13:00h, that the prices change.
to add more context:
this was the origin, that I got too many events.log entries:
Using openHAB 4.2.0 release on openHABian.
Since upgrading to 4.2 everytime the “Current total price” of tibber gets updated I receive a lenghty entry in the logs:
2024-07-19 09:24:35.118 [INFO ] [openhab.event.ItemTimeSeriesEvent ] - Item 'TIB_Current_Total_Price' shall process timeseries [Entry[timestamp=2024-07-18T22:00:00Z, state=0.2934], Entry[timestamp=2024-07-18T23:00:00Z, state=0.2819], Entry[timestamp=2024-07-19T00:00:00Z, state=0.2812], Entry[timestamp=2024-07-19T01:00:00Z, state=0…
and then I changed the “refresh interval” to 25 minutes, which led to the behaviour, that all non-live channels refreshed “randomly”, but not “on the hour”:
I think, there’s a opportunity for improved behaviour on the tibber binding side.
following this thread:
I set the change to 25mins. My thinking was to eliminate the change every minute, which was logged excessively!
This led to the binding “rotating” also the hourly price every 25mins. So it was randomly ok for a time, but could be as much off as 25mins. I’ll try to file an improvement issue for it on github.
for the time being, I changed it to 60mins exactly on the hour, so until a…
So my suggestion is to change all the hour-related channels “on the hour” as described in the github-issue.