How to use two different Configurations for one persistence service t

Hi,
I’ve tried the first time to store forecast data.from the Solar binding using Solcast.
I have the influxdb and use the MainUI.
When i setup the config i did it like shown below.
Question 1:
Is tit plausible (logical) like i configured it with 2 section in configuration?
Question 2:
In that case I phase an issue when I edit one of the “Configuration” then both will be overwritten with the same settings. (I createda n animated gif)

configurations:
  - items:
      - Forecast_Solcast_Solarmodul_Average_Energyestimate
      - Forecast_Solcast_Solarmodul_Average_Powerestimate
    strategies:
      - everyChange
      - forecast
      - restoreOnStartup
    filters: []
  - items:
      - "*"
      - "!Grunbeck_per_Http_GrunbeckXMLAnswer"
      - "!Grunbeck_Uhrzeit"
      - "!MinIlluminance"
      - "!Forecast_Solcast_Solarmodul_Average_Energyestimate"
      - "!Forecast_Solcast_Solarmodul_Average_Powerestimate"
    strategies:
      - everyChange
      - restoreOnStartup
    filters: []
aliases: {}
cronStrategies: []
thresholdFilters: []
timeFilters: []
equalsFilters: []
includeFilters: []

This is what happens.
Persistence

It looks reasonable to me.

That looks like a bug. Please file an issue on openhab-webui.

As an aside, if these are values supplied by a binding you should be using the in memory persistence. The forecast isn’t usually fixed. It changespotentially every time the binding pulls new data. So it isn’t something that needs to be saved to disk.

This is what the in memory perisistence was created for.,

Thank you Rich!
Just one more question.
If i want to keep the forecast information for comparison like in this solar plugin i can adjust a factor of eficieny like 90%.
Is here a way to keep the “real” forecast in memory but store the “archived” one?
If i click on he forecast at the moment i see:
The time point shows my “now”.

Means i can also see “old” archived foracasted measurements.

Do i need to remove then

- everyChange  <-REMOVE
- forecast
- restoreOnStartup <-REMOVE 

for the inMemory?
Because i’m a but nervious that this might increase the memory demand.

As the forecast becomes “now”, persistence updates the Item automatically. So you can include the Item in your InfluxDB persistence, just don’t use the forecast strategy there, just use every update or everyChange. For in memory, only use forecast.

Then as the forecast becomes the “now cast”, the item is updated and saved. InfluxDB. will shower the past values but it won’t show the future values.