Add ability to set sitemap chart period to a future period
higgers opened this issue · comments
Which UI are you reporting an issue for?
- Basic UI
- HABPanel
- HABot
- CometVisu
The problem
I have changed my electricity supply tariff to the Agile tariff with Octopus in the UK. This is a dynamic tariff with a unit price per each 30 minute period of the day. The future (the prices for the next day are released at 16:00GMT every day) prices can be read via the Octopus API, for instance the prices for the North West can be found here.
I have persisted the future prices with some rub code with the help of JimT using a timeseries item and would like to be able to show the future prices in a chart in a sitemap but can only configure the chart to show historic prices.
Your suggestion
Allow charts in sitemaps to be configured to show future periods as well as past periods. Maybe allow future periods for the same durations as the current past periods.
Your environment
OH 4.1.2
Additional information
I opened a thread in the OH community about this here and was advised to raise an issue here.
We just need to define the sitemap syntax to request a chart in future
We could use a negative period value to request in the future. It has the advantage there is nothing to change in the syntax I believe, but this is not really intuitive.
Doing the reverse, positive for the future and negative for the past would be more intuitive, but this will be an unexpected breaking change.
Or we could add another attribute in addition to the "period" to choose between past and future with a default being past for backward compatibility, something like "direction" with value "past" or "future" ?
Waiting for the best proposal.
@openhab/android-maintainers for info.
The change in Basic UI will then be easy.
I just checked, a value starting by a minus for the period would be rejected by the current syntax.
So in any case we have to enhance the sitemap syntax first.
Ok, I believe I found an easy and relatively intuitive solution that is also backward compatible. The idea is to extend the value of the period attribute to accept an optional prefix, either "last:" or "next:".
So "2D" or "last:2D" for 2 days in the past and "next:2D" for 2 days in the future.
Maybe a stretch, but what if someone comes up with the request to have a timerange from past to future? I don't have a use for it, but I could see it being useful. The way this is going we would need yet another syntax to make that possible. I am not saying we should support this, but we may create something that would allow a reasonable syntax when we would do something like that. And in such a case I don't think we can get away from 2 (or even 3) arguments: "history", "future" and "resolution". You could skip "resolution" if you expect the user to always use the same for history and future (and give an error when not).
a value starting by a minus for the period would be rejected by the current syntax.
"2D" or "last:2D" for 2 days in the past and "next:2D" for 2 days in the future
request to have a timerange from past to future
I suggest that we should not consider '-' as 'minus' symbol but consider rather as a 'range-until' marker. The new syntax would be X-Y meaning "from-x-in-past-until-y-in-future". Examples of such a range being as follows..
- existing day range (always past) =>
Done day in past until now - future day range (always future) =>
-Dnow until one day in future - combined day range (past and future) =>
D-Done day in past until one day in future - combined week range (past and future) =>
W-Wone week in past until one week in future
// last one day
Chart item=g_Boiler_Setpoint_Monitoring refresh=60000 period=D service="rrd4j"
// next one day
Chart item=g_Boiler_Setpoint_Monitoring refresh=60000 period=-D service="rrd4j"
// last one day until next one day
Chart item=g_Boiler_Setpoint_Monitoring refresh=60000 period=D-D service="rrd4j"
Maybe a stretch, but what if someone comes up with the request to have a timerange from past to future? I don't have a use for it, but I could see it being useful. The way this is going we would need yet another syntax to make that possible. I am not saying we should support this, but we may create something that would allow a reasonable syntax when we would do something like that. And in such a case I don't think we can get away from 2 (or even 3) arguments: "history", "future" and "resolution". You could skip "resolution" if you expect the user to always use the same for history and future (and give an error when not).
This is a good point, what if we want a chart that spans a period from the past to the future?
I like the suggestion of "last:" and "next:" to indicate past and future periods though I think the terms "past:" and "future:" are possibly more self documenting/intuitive.
What if we used symbols such as brackets or square backets to indicate that new syntax is being used? The existing syntax could be left as is and a new syntax introduced such as:
[past:2d-future:1W]
To indicate a period of two days into the past and one week into the future. The previous syntax could maybe be deprecated at a future point.
What about something like an offset?
// last one day
Chart item=g_Boiler_Setpoint_Monitoring refresh=60000 period=D service="rrd4j"
// next one day
Chart item=g_Boiler_Setpoint_Monitoring refresh=60000 period=-D service="rrd4j"
// last one day until next one day (from one day in the past, two days)
Chart item=g_Boiler_Setpoint_Monitoring refresh=60000 period=2D offset=-D service="rrd4j"
[past:2d-future:1W]
As I suggested in my prior post, you do not need the prefixes. The syntax for the above range can be simplified to '2D-W' ..
I am ok with @andrewfg proposal.
This would also require a change in the chart servlet to support this new syntax and compute automatically start and end date/times from this period if not provided.
[past:2d-future:1W]
As I suggested in my prior post, you do not need the prefixes. The syntax for the above range can be simplified to '2D-W' ..
Indeed it can be simplified, yes. There are pros and cons to both verbose intuitive syntax and concise less intuitive syntax for users with a variety of skill levels and... ability to read documentation. I know, because I don't always read the documentation fully myself :)
don't always read the documentation fully
Apropos this, @lolodomo, can you make a note that any eventual PR should also update the doc. :)
Apropos this, @lolodomo, can you make a note that any eventual PR should also update the doc. :)
Yes, obviously.
Remains to do an update of openHAB documentation.
Also remains to adjust sitemap UI configuration.
Also remains to adjust sitemap UI configuration.
You mean sitemap generator in Main UI ?
Also remains to adjust sitemap UI configuration.
You mean sitemap generator in Main UI ?
Yes, indeed, parser and configuration UI. I will have a look into that.
@lolodomo maybe also the dropdown list for the time series button ??
@lolodomo maybe also the dropdown list for the time series button ??
Already done and merged.
I have now proposed the change in the documentation.
@openhab/ios-maintainers
@openhab/android-maintainers
Any change required in the iOS and Android app ?
The Android app handles the chart period as string, but doesn't try to parse it. So I guess it should work with the new syntax.
The Android app handles the chart period as string, but doesn't try to parse it. So I guess it should work with the new syntax.
Fine.
Through the "menu" to update the chart period, you could now also propose predefined periods in the future, like I did in Basic UI.
Documentation now updated.