Thanks for pointing this out. This was not at all clear for me from the information that I could find online before upgrading. Actually, quite in contrast, there were quite a few posts in this forum which talked about doing exactly what I did: install OH 4, restore a backup from OH 3.x, run the upgradetool. I think it was even you, @rlkoshak, who recommended doing it like this here: Upgrade 3.4 to 4, but how? - #2 by rlkoshak
Of course I ran the upgradetool after restoring the backup and before starting OH 4 for the first time.
If restoring a 3.x backup (+ running the upgradetool) to migrate a backed-up OH 3.x configuration into OH4 does indeed not (or no longer) work, this might deserve some clear(er) advice in the documentation? If it does work (as several earlier threads indicate), it might be worth pointing out that this is not the case for full backups.
OH 3.4 to 4.0 can work that way but only for non-full backups.
Or you can clear the cache immediately after restoring the full backup but before running anything else (which essentially converts your full backup to a regular backup since the inclusion of cache and tmp is the only difference between a full and a regular backup.
But that was an exception and not guaranteed to work between any arbitrary OH versions down to the first point level (e.g. 4.2 to 4.3 may not work but 4.3.1 to 4.3.2 should work, though you won’t get any of the updates to your installed add-ons if you use a full backup).
Yep, now we seem to have reached consensus. That’s what I figured out the very hard way.
Therefore, again: a hint in the docs that full backups shouldn’t be used across versions would be very helpful. Or a warning message of the upgradetool, if the cache is not empty. Or a warning message when restoring a full backup into a newer OH version.
Have just added my description to the Github issue.
Have started experiencing this since upgrading to 4.3 from 4.2.
64bit Openhabian, fairly large system, 1100 items, 135 things, >70 JS rules, all files-based.
In my case the issue occurs occasionally (total of six times since upgrade to 4.3, approx every 4th of 5th system restart), but not reproducably. sysctl restart openhabhas so far reliably fixed the issue when it occured. Nothing in the logs that would suggest an error, just that system only gets to runlevel 40 and not beyond, and then rules engine is not loaded. Which leaves the system functioning, but without any automation.
Key difference in my case compared to many of the other reports: virtually no DSL rules. (There was still one (active but unused) one, which I have now deactivated).
I’m not sure where backups and restores are documented in the first place. Not that people read the docs in the first place. But if you know where, there’s a link at the bottom of every documentation page where an edit can be submitted. It’s a great way to contribute to the project.
On a normal upgrade, when upgradetool runs the cache wouldn’t be empty. I think teh cache is cleared as the last step. And you can run upgradetool at any time.
Off topic and sorry to be frank but no!
Upgrade instructions are given where applicable such as in release notes and if users decide to do stuff beyond or ignoring that they must not expect that to work or docs/developers/maintainers to warn them of.
ALL software in general and their docs just don’t work that way.
It’s impossible to list everything one must not do so it remains to be any user’s duty to read and follow the instructions.
Well… I read up as much as I could before going that step. And all I found indicated not only that this is possible, but even that it’s the recommended way of doing it when you are going to a new machine and a new OH version at the same time. I linked an example above.
Saying that it’s the user’s fault is… well… okay. But not if you want this to work for someone who doesn’t spend all their time in the intestines of this particular software.
Oh yes, even and especially in that case. If some user does not want to go the extra mile of understanding the internals and proper context, that’s fine of course.
But then they must be reading the official docs and stick to the documented procedures exclusively and not attempt stuff that’s not officially documented.
So hands off if you don’t find mentioned what you’re about to try.
Note Rich’ post you refer to was a forum post, and forum posts are not part of the official docs.
And on the docs part, I’ll renew my statement that you must not expect any software creator to document any No-Go.
Again, that’s not how any software docs work. It’s on the user to understand that upfront.
Now please get back on the thread topic. What I understood so far is you had a similar symptom after performing some unsupported form of upgrade (which probably caused that in the first place).
Correct? So I don’t think analyzing that contributes to a solution here? or is there anything I missed?
I used the upgrade tool which comes with OH 4.3 and states has the purpose of converting an OH 3.4 configuration to the new version. You are telling me that this despite this tool coming with 4.3 it must under no circumstances be used.
Just doing some testing to validate cron expressions.
WARNING: Installing this rule will likely force you to restart the OH service. Do keep an eye on Load and Temperature if you copy this on your system.
I made a little test file that instantly chocked my install:
rule "junk"
when
Time cron "0 0 8 * * ? *" or
Time cron "0 0 20 * * ? *" or
Time cron "0 0 19 ? * *" or
Time cron "0 0 6 * * ?" or
Time cron "0 0 21 * * ?" or
Time cron "0 0 1 * * ?" or
Time cron "0 0 5 * * ?" or
Time cron "0 0 9 * * ?" or
Time cron "0 0 10 * * ?" or
Time cron "0 0 * * * ?" or
Time cron "0 0 8 * * ?" or
Time cron "0 0 5 * * ?" or
Time cron "0 0 19 * * ?" or
Time cron "0 0 20 * * ?" or
Time cron "0 0 22 * * ?" or
Time cron " 0 0 8 2 1 ?" or
Time cron " 0 0 5 31 2 *" or
Time cron "0 0 12 * * ?" or
Time cron "0 0 9 * * ?" or
Time cron "0 0 19 ? * *" or
Time cron "0 0 17 * * ?" or
Time cron "0 0 22 * * ?" or
Time cron "0 0 22 * * *" or
Time cron "0 * * * * ?" or
Time cron "0 0 * * * ?" or
Time cron "0 0 8 * * *" or
Time cron "0 0 4 * * *" or
Time cron "0 30 20 * * *" or
Time cron "0 0 5 * * ?" or
Time cron "0 0 7 * * ?" or
Time cron "0 0 7 * * 2-6" or
Time cron "0 30 19 * * *" or
Time cron "0 30 20 * * * *" or
Time cron "0 0 8 * * 2-6 *" or
Time cron "0 0 13 * * 2-6" or
Time cron "0 0 18 * * *" or
Time cron "0 0 20 * * *" or
Time cron "0 0 19 * * 2-6 *" or
Time cron "0 25 19 * * * *" or
Time cron "0 45 7 * * * *" or
Time cron "0 30 19 * * ? *" or
Time cron "0 15 6 * * ? *" or
Time cron "0 0 6 * * * *" or
Time cron "0 0 5 * * ? *"
then
end
With the recently released 4.3.2? The cron expression problems should be fixed in that release. Two separate PRs related to cron expression parsing are included.
Great! That means the cron expression cause for this problem appears to be fixed. For everyone else on this thread who are seeing this problem without cron expressions, please test on 4.3.2 and report if the problem still persists. There is strong evidence that there’s more than one problem .
I just upgraded to 4.3.2 and openhab started smoothly without any (unnormal) warning message.
But I just tried to restart once…
And I doubt that my issue was caused by an invalid cron expression.
