File based persistence configurations where not even visible in the UI in versions before 5.1. With 5.1, they are visible and locked for editing. This is similar to file based configuration for items and things vs managed configurations. So I would say it is clearer now than it used to be.
For one persistence service, it is all or nothing. It is either managed, or it is fully defined in a persist file. That has always been the case. People had errors before where they had both (managed definition and in a .persist file). And one of them would lead depending on startup sequence.
You don’t need a line if you upgraded and were relying on default behaviours, because the upgrade took care of it. If you had a .persist file, you were not relying on default behaviour.
Only when you create a new configuration, it will not apply defaults anymore.
I totally agree with that, and it was not something I like either. I had this code ready even before the 5.0 release and it had been sitting in review until just before OH5.1 cut-off. It forced some rushed fixes even in the release candidates and didn’t leave much time.
Regarding persistence, I feel that there are factors that aren’t being discussed, that nonetheless are factors for why people make the decision they do.
I can only speak for myself, but I don’t find it unlikely that many others have a somewhat similar situation: For years, I’ve been aware that I should configure persistence to what I want it to, and not leave it at the default and “hope for the best”. But, I’ve been procrastinating for reasons that I don’t think have changed or been addressed. By removing the default strategy, you force people to stop procrastinating and deal with it right now. Which might have been the intention, but it can also be very inconvenient to suddenly have to do something that you might not even be aware that was dumped in your lap at that time (let’s face it: lots of people don’t read release notes).
When I ask myself why I’ve been procrastinating configuring persistence for so long, I come to the following:
I’m worried that I will forget to persist new Items that I add later
I can’t seem to wrap my head around how to make a strategy that does what I would like. What I would like isn’t even clearly defined, but it is clearly based on exclusion: Everything is persisted, unless… and the unless can’t be individual Items. That will just never work for me, I will forget. Ditto with adding them to groups. I feel like I would need to define “more advanced” rules to apply based on “the type of Item” or certain properties of the Item. I don’t have the details pinned down, because what’s the point in making a detailed plan of how I would want it to be, when that’s not reflected in what I can actually do. I try to marry the two (my wish and what I can actually do), and each time I’ve done that, I’ve giving up in the end. Thus the “long-term procrastination”.
Part of why I fail to reconcile my needs with the actual possibilities, is that the whole thing feels like it lacks information. Individual options might be somewhat explained, but I get no bigger picture out of it. I’m not able to effectively “navigate” the matter, at least not without taking a really deep dive into it all - which again leads to the procrastination situation.
To illustrate what I mean, just look at how the configuration in the UI looks:
There are lots of options there, but no descriptions. Sure, I understand what an include or exclude filter is, but I have no context here, so I have no idea what I include or exclude. It’s the same with pretty much all of them. They just don’t give me the information I need to understand what possibilities they give me. I’m sure I can find out by digging, but that isn’t really suitable when I’m trying to get an overview over how to approach this. Having to “read an entire manual” to understand all the options before I’m able to get an overview over how to make a strategy that fits me is a big part of what makes me procrastinate.
It’s the same with the different persistence “engines”. I feel that they aren’t sufficiently exlained that I know what I shoud choose. In-memory persistence for example seems like an oxymoron to me. I’m sure it has its uses, but it’s not apparent to me, and I don’t quite understand why I’m faced with having to make some decision about it - it is “recommended” for installation, and if I install it, I’m also expected to make a configuration for it, that makes it do something meaningful.
To try to avoid writing a novel, I’ll stop here, but I could write much more “in the same direction”. The gist of it is that I feel that I must make decisions about things where I don’t have the necessary information, and acquiring that information feels a bit overwhelming. On top of this already existing “dilemma”, people are now being forced to do this, in the middle of an upgrade where lots of other things are going on.
Apropos persistence: I would like to give you guys my actual real example.
My operative system is still currently on OH v4.3.x. Below are my actual *.persist files. These have been like this since probably OH v2.x.
I am quite pleased that I did not upgrade my operative system to v5.1.x on Christmas day since I have the feeling from this thread that had I done so it would have munged my system. Or am I wrong??
Also I have the feeling from this thread that I need to edit these files in some way. But neither from the update instructions, nor from this thread, do I get any clear instructions about what exactly to change in either of these files. Indeed I have the feeling that different people are saying different things. Furthermore it is not clear whether I should make changes before the upgrade (while still on v4.3.x) or after the upgrade to v5.1.x..
I meant that to mean if you wanted to change to the old default behavior from a more constrained config but clearly on rereading it I didn’t say that at all.
But if you’ve created a .persist file, you’ve already dealt with it. If you didn’t have a .persist file upgradeTool created a config for you.
You are only forced to do anything if you had a .persist file. And if you had a .persist file, all you had to do was remove one line and possibly modify others if you actually used the default strategy.
I think some explanation needs to be made here in what the default strategy was and how it was used. Because this change really isn’t as big as it’s being made out to be.
First of all, the default strategy has not been in the docs at all since OH 3.2. Since OH 3.3, this strategy has essentially been deprecated. If you’ve created your .persist files since that version, you likely do not have a default strategy in the first place.
But back then, the docs for the default strategy was as follows:
The default parameter assigns a strategy to be used if one is not specified in the Items section below. The default parameter may be omitted from the Strategies section, but only if a strategy is provided in each line of the Items section. If the strategy portion of the itemlist is omitted in the Items section, the default strategy specified in the Strategies section will be applied.
So, the default strategy was only being used if you had a line in the Items section of the file that did not list strategies after the :. Something like
*:
Therefore:
If you had a managed persistence config, you’ve nothing to do
If you had no config, a managed config was created for you, you’ve nothing to do
If you had a .persist file without a default strategy, you’ve nothing to do
If you had a .persist file with a default strategy that was not being used, you only need to remove that line from the strategies section.
For example, if your .persist file looked like this:
// persistence strategies have a name and definition and are referred to in the "Items" section
Strategies {
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
// if no strategy is specified for an Item entry below, the default list will be used
default = everyChange
}
/*
* Each line in this section defines for which Item(s) which strategy(ies) should be applied.
* You can list single items, use "*" for all items or "groupitem*" for all members of a group
* Item (excl. the group Item itself).
*/
Items {
// persist the Item state of Heating_Mode and Notifications_Active on every change and restore them from the db at startup
Heating_Mode, Notifications_Active: strategy = everyChange, restoreOnStartup
// additionally, persist all temperature and weather values every hour
Temperature*, Weather* : strategy = everyHour
}
it needs to become
// persistence strategies have a name and definition and are referred to in the "Items" section
Strategies {
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
}
/*
* Each line in this section defines for which Item(s) which strategy(ies) should be applied.
* You can list single items, use "*" for all items or "groupitem*" for all members of a group
* Item (excl. the group Item itself).
*/
Items {
// persist the Item state of Heating_Mode and Notifications_Active on every change and restore them from the db at startup
Heating_Mode, Notifications_Active: strategy = everyChange, restoreOnStartup
// additionally, persist all temperature and weather values every hour
Temperature*, Weather* : strategy = everyHour
}
If you had a line in the Items section that did not list any strategies, copy the stuff after the “=” on the default line under strategies after the : on that line. Then delete the default line.
If it looks something like this:
// persistence strategies have a name and definition and are referred to in the "Items" section
Strategies {
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
// if no strategy is specified for an Item entry below, the default list will be used
default = everyChange
}
/*
* Each line in this section defines for which Item(s) which strategy(ies) should be applied.
* You can list single items, use "*" for all items or "groupitem*" for all members of a group
* Item (excl. the group Item itself).
*/
Items {
// persist the Item state of Heating_Mode and Notifications_Active on every change and restore them from the db at startup
*:
Heating_Mode, Notifications_Active: strategy = everyChange, restoreOnStartup
// additionally, persist all temperature and weather values every hour
Temperature*, Weather* : strategy = everyHour
}
It needs to become
// persistence strategies have a name and definition and are referred to in the "Items" section
Strategies {
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
}
/*
* Each line in this section defines for which Item(s) which strategy(ies) should be applied.
* You can list single items, use "*" for all items or "groupitem*" for all members of a group
* Item (excl. the group Item itself).
*/
Items {
// persist the Item state of Heating_Mode and Notifications_Active on every change and restore them from the db at startup
*: everyChange
Heating_Mode, Notifications_Active: strategy = everyChange, restoreOnStartup
// additionally, persist all temperature and weather values every hour
Temperature*, Weather* : strategy = everyHour
}
If the change impacts you, you haven’t procrastinated. You created a .persist file. All you need to do is move the stuff after the “default =” to the lines that don’t list a strategy and you are done. You don’t need to deal with anything else right now.
Create a catch all line that applies to all Items.
*: everyChange, restoreOnStartup
Add everyMinute if using rrd4j.
You don’t have to make any new decisions now. You can continue to procrastinate. You just need to move what you’ve already configured from the default line to where you actually used the default strategy, if you used it at all in the first place.
You can use a rule instead of the persistence config. That’s the only way I know that you could achieve this.
But it definitely could be achieved through a rule and calling .persist on the Items. Your strategy would be filtering on all Items for what ever criteria you want. We can take this to another thread to discuss if you want more about the idea.
I can’t see this happening with the current persistence config without a lot of additions. Not impossible to add them, but it will be a lot of work. An issue would be good to track the idea.
I agree, the inline docs here should be improved. An issue would be welcome I think.
In the mean time, each of these is covered in the docs reasonably well. There’s always room for improvement.
Note, the developer sidebar always will link you to the specific page and often the specific part of a page in the docs based on what screen in MainUI you have open.
But there is a good opportunity here. The help section implements a wizard for some parts of OH. We could implement an initial persistence configuration wizard to walk the user through creation of a custom config.
An issue for this would be good too.
I thought the docs for it, though a little terse, were pretty clear.
The main use-case is to store data that is needed during runtime, e.g. temporary storage of forecast data that is retrieved from a binding.
Bindings like weather bindings and electricity price forecast (e.g. tibber) can use this to limit the number of Items one needs to create. For example, if you have the weather forecast every hour for the next 24 hours, instead of needing 24 individual Items to store this information you can have one with the in memory persistence (or any persistence that supports forecast if you want to save them to persistence storage) and then retrieve the forecast values using persistence calls on the Item. This data can change on every call to the weather APIs and it gets restored by the binding so there’s no reason to save it to disk.
I don’t know why it’s recommended by the first run wizard. Perhaps more explanation should be given there. I would not have chosen to recommend that in the first run wizard at all. And I think we’ve some work to do to improve the experience for first time users and new persistence add-on installs. Maybe create a persistence config automatically with reasonable defaults?
Not mangled but OH would have complained.
All you need to do is remove the line default = everyUpdate from mapdb.persist. No other changes are required. You are not using that default strategy in that file anyway and you don’t have a default strategy in the rrd4j.persist file.
The breaking changes states:
If you have a file based configuration with an existing .persist file, you may have to update your configuration: remove “default” from Strategies and make sure all Items definitions have a strategy defined.
A more robust discussion of that with examples is above under 4 and 5.
Either way will work. OH 5.1 won’t complain about it if you do it before. And the change you make is comparable with OH 4.3 so it won’t break anything. You’ll just be removing a line in that file that isn’t doing anything anyway.
Lets assume for a seond one shoud really not persist everything, a warning saying that there are items persisted that do not actually need it would have done the trick for starters. A litttle more effort and you could already determine which ones are used in rules and sitemaps. Of course there is more, even those persisted items, OH could not possibly know about as they go to influx and from there who knows where.
Anyway, breaking things like this for no real reason makes me speechless.
How did this make it through the milestone builds ? Did no one object ?
Most of the problems caused by 5.1.0 compared to 5.0.3 are solved in version 5.2.0 but the pictures in widget “photoframe_2” are still not moving in 5.2.0.
How would OH know? Even with the semantic model OH doesn’t have enough information to know what Items need to and do not need to be persisted.
That has nothing to do with whether an Item needs to be persisted.
It was discussed a lot, reviewed by the maintainers and approved. It solves a real problem experienced by many. And it has low impact on end users. I’m pretty convinced the problems you are experiencing have nothing to do with this change. I would encourage you to open a new thread and post as much info as you have regarding what problems you are experiencing, and we can figure out what the cause is.
In the mean time, see my post above to determine whether the change means you have to do anything and the edits to your .persist file you need to make if you do. I’m willing to bet that the only change you need to make is to remove the default line from the strategies section because almost no one actually used the default strategy anyway.
I appreciate that, I haven’t made a .persist file because of the aforementioned procrastination - but as I’m running 4.2.3 because of other blockers (Frontail, 64bit/full reinstallation of openHABian which no longer supports installation via Wi-Fi +++), I haven’t actually faced this issue. I don’t think that the upgradetool would “help” me since I have to reinstall and restore/apply my configuration, so I would probably be left with no persistence and several “heath warnings”.
My comment was meant as context for what is generally “challenging” with the persistence setup, since I observe that a number of people seem to have had a bad experience in this “transition”, I assume that the upgrade hasn’t “been handled automatically” for them. That means that they are suddenly faced with the same “challenges” that have already prevented me from making a persistence configuration.
Regarding what you are “forced” to do, it’s not that it’s a lot of work to do the required changes. It is gathering the information that enable you to make the changes that can feel a bit overwhelming. One you know what to do, it’s fine.
As I said above, I’m pretty sure that it will impact me, because I doubt that the upgradetool will ever run since I have to reinstall to get past the 64 bit OS requirement.
And, this is a situation I do know something about. Because, I’ve made lots of test installations since this was introduced. So I know what you’re faced with when making a new installation, and as has been mentioned furher up in this thread, I think it’s less than ideal. In the startup wizard I have to choose what persistence engines to install, without having enough information to make an informed choice (and yet, I could stop there and visit the documentation, but that might not be my primary concern at this time, so it might not be the time and place to do that). So, I half-way guess what to change from the default selected options.
This takes me into a new, fresh installation with an immediate big, red “health warning”. One of the warnings are bugged and take me to a non-functional page (the one about choosing a default persistence, although I have no idea what that even means). The others are one warning per installed persistence engine about missing configurations. Which leads me to the aforementioned configuration pages that I have no idea what to do with. A desperate attempt to just save whatever is there by default doesn’t help, so I have to figure out enough of this to be able to make some changes.
If those for which the planned “smooth” upgrade path fails for whatever reason, find themselves in a similar situation to you do after a fresh install, with the added stress that they are losing persistence data in their production system until they have figured it out, I absolutely understand the frustration.
Yes, as said above, the problem isn’t making the changes, it’s gathering the information needed to make the changes.
That sort of aligns with what I’ve concluded when trying to wrestle with it in the past, which again has lead to “it’s probably better to just persist everything until I can figure this out” aka procrastinating.
I must admit that I’m not very good at using that, because I feel that it eats to much of already scarce screen real estate (because of the “mobile first” F7 layout, things are way too big and there’s lots of wasted space, leading to lots of scrolling and little overview). I know that I’ve found valuable information there when I’ve occasionally opened it. But, part of the process I’ve experienced takes place in the first-start wizard, where the developer sidebar isn’t available (as far as I know). I can never remember the shortcut for it anyway, so I need to open it from the menu.
I definitely think that there’s a need from some sort of wizard process for configuring persistence, at least for very basic configurations.
Probably, the problem is that at the time when I have to make the decision, I’m in the middle of the first-start wizard, and don’t have the documentation in front of me. I sort of have to make the decisions based on what the wizard gives me, and I find that lacking for me to make informed decisions, which is why I fall back to “the defaults probably aren’t that bad” - which then bites me because I later have to make 3 different configurations and make a choice about a default that doesn’t work and that I don’t know what means anyway.
Exactly, and that’s probably my primary concern here. Not that it’s not useful, not that it’s not possible to figure out what it does, but the fact that it’s “suggested” to me and I don’t feel that I know enough to say no to this suggestion.
Yes, but then we’re almost back to having a default configuration..? As I said, we discussed this briefly further up, and I think that the first-time wizard needs to be extended to include something that guides you through this, but as also mentioned above, there should probaby be some way (other than manually entering the path for the wizard) to re-run it after the first startup - in case you missed something the first time.
openhabian@openhabianpi:/var/lib/openhab/cache/org.openhab.voice.tts $ ls
openhabian@openhabianpi:/var/lib/openhab/cache/org.openhab.voice.tts $
and producing this error message:
2026-01-06 19:04:41.495 [DEBUG] [core.voice.internal.VoiceManagerImpl] - Error saying 'Audiotest und test mail gesendet': org.openhab.core.audio.AudioException: Error while executing '[Ljava.lang.String;@19eab4a1'
org.openhab.core.voice.TTSException: org.openhab.core.audio.AudioException: Error while executing '[Ljava.lang.String;@19eab4a1'
at org.openhab.voice.picotts.internal.PicoTTSService.synthesizeForCache(PicoTTSService.java:84) ~[?:?]
at org.openhab.core.voice.internal.cache.TTSLRUCacheImpl.lambda$0(TTSLRUCacheImpl.java:124) ~[?:?]
at org.openhab.core.cache.lru.LRUMediaCache.get(LRUMediaCache.java:198) ~[?:?]
at org.openhab.core.voice.internal.cache.TTSLRUCacheImpl.get(TTSLRUCacheImpl.java:122) ~[?:?]
at org.openhab.core.voice.AbstractCachedTTSService.synthesize(AbstractCachedTTSService.java:41) ~[?:?]
at org.openhab.core.voice.internal.VoiceManagerImpl.say(VoiceManagerImpl.java:285) ~[?:?]
at org.openhab.core.model.script.actions.Voice.say(Voice.java:151) ~[?:?]
at org.openhab.core.model.script.actions.Voice.say(Voice.java:57) ~[?:?]
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source) ~[?:?]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1195) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1170) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._invokeFeature(XbaseInterpreter.java:1156) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeFeature(XbaseInterpreter.java:1101) ~[?:?]
at org.openhab.core.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:151) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:1011) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:974) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:247) ~[?:?]
at org.openhab.core.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:225) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:227) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:475) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:251) ~[?:?]
at org.openhab.core.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:225) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:227) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:213) ~[?:?]
at org.openhab.core.model.script.runtime.internal.engine.ScriptImpl.execute(ScriptImpl.java:80) ~[?:?]
at org.openhab.core.model.script.runtime.internal.engine.DSLScriptEngine.eval(DSLScriptEngine.java:142) ~[?:?]
at org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler.eval(AbstractScriptModuleHandler.java:265) ~[?:?]
at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.lambda$0(ScriptActionHandler.java:99) ~[?:?]
at java.util.Optional.ifPresent(Unknown Source) ~[?:?]
at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:86) ~[?:?]
at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1322) ~[?:?]
at org.openhab.core.automation.internal.RuleEngineImpl.runRule(RuleEngineImpl.java:1078) ~[?:?]
at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData.run(TriggerHandlerCallbackImpl.java:86) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[?:?]
at java.util.concurrent.FutureTask.run(Unknown Source) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:?]
at java.lang.Thread.run(Unknown Source) [?:?]
Caused by: org.openhab.core.audio.AudioException: Error while executing '[Ljava.lang.String;@19eab4a1'
at org.openhab.voice.picotts.internal.PicoTTSAudioStream.createInputStream(PicoTTSAudioStream.java:71) ~[?:?]
at org.openhab.voice.picotts.internal.PicoTTSAudioStream.<init>(PicoTTSAudioStream.java:51) ~[?:?]
at org.openhab.voice.picotts.internal.PicoTTSService.synthesizeForCache(PicoTTSService.java:82) ~[?:?]
... 39 more
Caused by: java.io.IOException: Cannot run program "pico2wave": error=2, Datei oder Verzeichnis nicht gefunden
at java.lang.ProcessBuilder.start(Unknown Source) ~[?:?]
at java.lang.ProcessBuilder.start(Unknown Source) ~[?:?]
at java.lang.Runtime.exec(Unknown Source) ~[?:?]
at java.lang.Runtime.exec(Unknown Source) ~[?:?]
at org.openhab.voice.picotts.internal.PicoTTSAudioStream.createInputStream(PicoTTSAudioStream.java:64) ~[?:?]
at org.openhab.voice.picotts.internal.PicoTTSAudioStream.<init>(PicoTTSAudioStream.java:51) ~[?:?]
at org.openhab.voice.picotts.internal.PicoTTSService.synthesizeForCache(PicoTTSService.java:82) ~[?:?]
... 39 more
Caused by: java.io.IOException: error=2, Datei oder Verzeichnis nicht gefunden
at java.lang.ProcessImpl.forkAndExec(Native Method) ~[?:?]
at java.lang.ProcessImpl.<init>(Unknown Source) ~[?:?]
at java.lang.ProcessImpl.start(Unknown Source) ~[?:?]
at java.lang.ProcessBuilder.start(Unknown Source) ~[?:?]
at java.lang.ProcessBuilder.start(Unknown Source) ~[?:?]
at java.lang.Runtime.exec(Unknown Source) ~[?:?]
at java.lang.Runtime.exec(Unknown Source) ~[?:?]
at org.openhab.voice.picotts.internal.PicoTTSAudioStream.createInputStream(PicoTTSAudioStream.java:64) ~[?:?]
at org.openhab.voice.picotts.internal.PicoTTSAudioStream.<init>(PicoTTSAudioStream.java:51) ~[?:?]
at org.openhab.voice.picotts.internal.PicoTTSService.synthesizeForCache(PicoTTSService.java:82) ~[?:?]
... 39 more
as documented in the above logfile, this program
diff --git a/persistence/jdbc.persist b/persistence/jdbc.persist
index 5bd3999..f4d3d4c 100644
--- a/persistence/jdbc.persist
+++ b/persistence/jdbc.persist
@@ -1,11 +1,9 @@
// persistence strategies have a name and a definition and are referred to in the "Items" section
Strategies {
- // if no strategy is specified for an item entry below, the default list will be used
everyMinute : "0 * * * * ?"
every5Minutes : "0 */5 * * * ?"
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
- default = everyChange
}
/*
I’ve not had a single issue. And I’ll add also that I’m pretty happy with the removal of the default strategy. From time to time I was doing manual data correction because items, that shouldn’t be persisted, suddenly existed in my MySQL database because of some random timing issue during startup. Kudos to @Mherwege for that.
Actually it’s fixing the regression, but offset still doesn’t work for oh-state-series. Probably we should get this PR finished and backport it to fix the regression and care about oh-data-series later.
I am working on both, but I would expect this is rather 5.2 timeframe and nothing to backport to 5.1.
There is probably a documentation need here. If you install, copy in your existing config, and then run the upgrade tool manually before startion openHAB, it will do all adjustments, and the wizard will not even be shown. Running the upgrade tool manually is in the documentation, but the whole process isn’t.
I’ve seen nothing metntioning this anywhere and wifi is still listed in the docs as an option. Where did you get the impression wifi is no longer supported?
The normal process is:
Install the same version of OH on the new machine (SD card in this case), there is a property in the config file you edit on the boot partition prior to that first boot where you can set that when using openHABian. For package installs you can choose the version on the command.
Restore your backup from the old install.
Upgrade OH.
If you follow this process upgradeTool will run and will create a persistence config for you.Ensuring that upgradeTool runs is a major reason we recommend this procedure.
If you install from scratch and rebuild, then as soon as you install a persistence add-on the health check will probably complain. If you use files create one that looks like the following:
under configuration choose “persist all Items” and under strategies choose everyChange and restoreOnStartup. Add everyMinute if rrd4j. The yaml for my mapdb config is:
Until we have some other evidence, these users already had .persist files. upgradeTool does not touch these files. You all would scream bloody murder if it did. TANSTAAFL. If one chooses to use text file configs so they have full control over everything, part of the cost that comes with that is the need to read and apply the breaking changes.
Which is a different discussion and probably needs a separate thread to figure out how to improve the new user experience. For certain much needs to be improved there.
But for upgrades, not even you will have to face this issue if you follow the procedure I outline above and which has been repeated in many places as the best way to move from one machine to another, which is essentially what you will be doing.
One place that does need an update is Persistence | openHAB. New users should definitely be using Getting Started during their initial setup. So that’s one place we can improve things, But like I said, that;s probably best for a different thread.
For the curious who may not know it, it’s alt-shift-d.
I think for very basic configurations they should just be created. There’s hardly enough to do to make a default persist everything restoreOnStartup config to warrant a wizard. Maybe during the first start wizard offer to create that. Even better if when installing any persistence add-on at any time create a default persist everything with restoreOnStartup config. Bindings and push config to Items, why not persistence add-ons too? But again, another thread…
The original problem this solves is this. Let’s say you know what you want your persistence to do. You have your persistence config all layed out and you are very happy with it.
If the persistence add-on happens to come online before the .persist file is read, the add-on’s default will kick in and start saving all your Items. This pollutes your database and explicitly ignores what you’ve clearly indicated you want, i.e. only the configured Items get saved under the indicated strategies.
Every restart of OH could result in a load of cleanup using external tools to modify the databases involved.
So the defaults built into the add-on were removed. Before a persistence add-on will save anything it needs to have an explicit configuration telling it to do so. This is what’s causing the issues you point out for new users. But something had to be done and this is what was decided upon.
I’m not 100% certain the link between this and the default strategy in the .persist file. It was related somehow though, and it was removed at the same time. And it’s really this and only this that is really causing anyone any problems with the upgrades. The default strategy was always kind of odd and redundant from the very beginning. I don’t think many ever deliberately used it because it really only served to make .persist files harder to read and understand. And it’s been at least half a decade since it’s even appeared in the docs anywhere. But upgradeTool won’t touch .persist files so those who use them have to do it manually.
Anyway, I say all this to point out that having a default policy isn’t what was the problem. The problem was that it kicked in before the .persist files were read in. Creating a default persistence config still avoids that problem.
I thought there was a PR open to add the link somewhere. Maybe it was only discussed. I think that’s a great idea. Settings and Help and About make sense to me. But having it anywhere would be better than nothing.
This will work too. I like to tell people to restore to the same version of OH first mainly to ensure their restore works before throwing in the upgrade. But if one is confident that step could be skipped.
I thought it was and coundn’t find it either. It seems to come up enough maybe it’s warranted. I’m not sure the best place to put it though, and it’s going to be different from one type of install to the next in the details if not the overall process.
After upgrading my installation to openHAB 5.1 the Locations, Equipment and Properties view on the home page do not work any more. Did I miss a breaking change there?
The pages only show a loading indicator but no error is shown (neither in browser debugging tools nor on the openhab side.
Also when opening the Home page from the pages view it only shows the loading indicator.
That might be wrong, I don’t remember the details, but I concluded that to install a more recent version of openHABian, I must first figure out how to handle Wi-Fi myself - which has become another “mental blocker” preventing me from upgrading.
I know that it’s recommended to do it this way, but I’m hesitant to if that’s what I would actually do. My experience is that upgrades themselves often make some level of mess in a system, so I prefer a “clean install” if I can choose. That doesn’t mean that I wouldn’t normally have upgraded, but since I have to do a manual restore, reconfigure everything (my customization of the openHABian installation that I don’t even remember what I did where), I’m tempted to go directly to the version I want to use, to not start out “already in debs” with some obscure details that didn’t go quite as intended. I think manually running upgradetool is more appealing to me personally.
I don’t have the overview, you’re probably right that those affected are primarily those with file-based persistence configuration. And, I haven’t for a second suggested that one should try to modify these files automatically. All I’ve been trying to say is that, when you’re in a situation where you suddenly have to figure all this out, it can be kind of overwhelming to gather the necessary information so that you know what to do.
In hindsight, I think it might have been preferable to first have released a version that made ample warnings about default persistence configurations and how to deal with it, but where it still worked. That would still only have helped those that follow every release, but it would at least have given those users a bit more time to figure it out.
It’s not that I don’t “know” it - it’s shown when you open the dev panel. But, for some mysterious reason, it won’t stick in my mind - so it’s not there when I need to use it
I understand this problem, and that it can be very annoying for those that care about their databases. But, I’m wondering if this “fix” was the best way to solve the problem (it might be, I haven’t dug into the details). I would say that one could argue that the fact that Item activity starts before persistence is fully up and running (configured and ready to go) in itself is a problem. Won’t this change create a new problem, caused by the same underlying cause? Won’t you have a period during startup where nothing is persisted, until the configuration has been loaded, and as such, you end up having “holes” in your data instead of having “too much” data?
Yes, @Mherwege said above that he’s working on this. I think there might be a need to at least backport some kind of relief to 5.1 though, but again, I don’t know the details.
Clear cache and reload was of course done. The browser console does not actually show anything when clicking on locations/equipment/properties. But I see the following when refreshing the homepage.
That’s not true and never has been, and the Wi-Fi menu option you refer to in that issue actually has never been relevant for installing it. And it is ancient, IIRC this was even pre-bookworm.
You can statically define your Wi-Fi credentials in openhabian.conf or use the hotspot that fires up when openHABian detects it has no connectivity during the install process.
Current image is confirmed to work by many, and even the trixie beta is known to work.
And frontail also is still available.
