That’s right. To make your solution/binding a success (= make it useable to as many not-as-technically-proficient users, too), data must be available as channels so users can use them right away without additional postprocessing.
But this now is the wrong turn:
For sure it is !
Because anyone who wants to make proper use of this info to control his heating or whatever device
relies on it.
Then again visualizing isn’t so important. A well automated system doesn’t even need any.
But easy access to available pricing information is very important to ease programming the run times of your heat pump or other consumers that you want to run at specific times in order to benefit from cheap power.
Step back for a second and have a look at other threads on the forum, search for Tibber and aWATTar bindings. These are dynamic tariff providers available (also) in Germany.
Check out their binding docs how they represent the pricing information in terms of channels.
The aWATTar binding for example has a “cheap now” switch type channel to allow for the most easiest usage one can think of, see e.g. this thread.
It allows you to create multiple OH things with different setting on a “consecutive hours” parameter which is very similar to your number of slices.
So users have the choice at any time. They can for example create two OH things, one with consecutive=1 resulting in what in your solution would be 1 slice.
In parallel they can create a second thing with consecutive=<some more>.
Depending on their application context (referring to our recent conversation: depending on if it’s a deep winter’s day or not so we want to use 1-slicing or 3-slicing algorithm) they will use a channel of thing1 or the same channel but from thing2.