Persistence stores items despite definitions in config file (OH3, later switch to OH4)

Its been a long time since I set this up and there probably have been improvements, but I recall going into mysql to set up openhab as a user.

Also have a jdbc.cfg file with


Maybe this is not needed anymore?

@apella12: A file is indeed not needed anymore (as of OH3 already). The persistence configuration in the GUI is sufficient, the connection is not the issue.

Understood, I will test it like that. What surprises me though is that the system wanted to store data before any persist configuration was done. More than that, even before any connect information was provided (see the log entry in my previous post from 2023-08-30 22:58:10). It was right after the clean system setup of OH4 and after configuring the according things and items. Persistence addons installed but not configured yet.

It seems that with the below configuration, the system is behaving in a stable matter and as envisioned.

Still wonder what the “defaultStrategies” does? Without having any items in the configurations part, the persistence model stayed silent and did not log anything.
Now with the items in the configuration, it uses the according strategies, which renders the “defaultStrategies” further down quite useless or am I missing something? :thinking:

  - items:
      - HeatingSystem*
      - every5Minutes
    filters: []
  - items:
      - MaintenanceInfo*
      - everyChange
    filters: []
  - name: everyMinute
    cronExpression: 0 * * ? * *
  - name: everyHour
    cronExpression: 0 0 * * * ?
  - name: everyDay
    cronExpression: 0 0 0 * * ?
  - name: every5Minutes
    cronExpression: 0 0/5 * * * ?
  - every5Minutes
thresholdFilters: []
timeFilters: []
equalsFilters: []
includeFilters: []

Anyways, for me, the topic is solved in general. Thanks so much for the very timely replies and all the continous support!! Much appreciated. :smiling_face:

Since it’s all asynchronous and event driven I’m not sure there is much of another alternative. The event bus doesn’t know if the persistence is configured or not, it just knows that a certain Item event occurred and the JDBC add-on cares about those events.

The JDBC add-on probably doesn’t know the difference between not configured and incorrectly configured when it processes an event also so I think the behavior here is absolutely appropriate.

They were never really all that useful in the first place and are not even mentioned in the docs any more. They were just a way to save a few characters of typing. You’s still have to define the Items but if you don’t supply any strategy the defaultStrategy is applied.

Right, because you’ve overridden the default add-on behaviors with your custom one and your custom one didn’t identify any Items to persist so it didn’t persist anything.