These are all UI based rules with script actions. Though I am starting to wonder if file based configurations are actually better for me.
Saving through the web ui seems to send the exact REST api requests that I use to update my scripts, so I might have to use that approach until I rethink my setup.
It’s still strange, perhaps @dalgwen has some idea, but a normal “UI rule” gets compiled during startup, just as they do after being re-saved. Is this a one-time operation, or do they need re-saving every time OH has started?
Between restarts of OH is fine, it’s just an issue when upgrading OH. For example I had this issue last upgrade cycle with JS scripting trying to use the publishMQTT action.
Furthermore, in regards to my Java223 scripts, doing a mass update of them through my REST script also reduces their execution latency.
It’s well above my head, but I wonder if all scripts are compiled to some JVM code which the JVM can optimise through JIT compilation. The old code my not be optimised after update and so resaving is essentially resetting the process and doing a fresh optimisation.
The scripts are compiled, but this isn’t cached to disk anywhere as far as I know. That’s the point, the exact same compilation takes place during startup as it does after you’ve saved/reloaded the rule, as far as I know. I’m not saying that what you’re reporting is wrong, just that I can’t quite understand how it could make a difference.
Next time, take a copy of the automation_rules.json in the JSONDB before doing the resaving, and then compare that with what is stored after the resave. If there’s a difference, we’re probably onto the culprit.
On the first start after upgrade, there can be glitches. The reason is that add-ons need to be downloaded, the jar-cache filled, and this just changes the usual order how pieces are loaded. I guess the same happens after openhab-cli clean-cache. As alternative to re-uploading rules, restarting openHAB after the cache is refilled (from internet), also makes openHAB run normal.
The posted by you thread, why it works between restarts, but not on the first start after upgrade, contains comprehensive explanation why this happens. The explanation is valid for all add-ons (bindings, automation, etc). It is apparently also valid for Java223, which is possibly not downloaded over internet after upgrade, but is present as .jar file in the share/openhab/addons folder. In this case the add-on starts executing rules too early, before the other needed add-ons are downloaded and initialized.
I forgot to answer here, no, I have no idea.
I also had issues with starting delay, generated scripts not ready, etc. This is really tricky.
So I have the habit of, after an openHAB upgrade, to restart it once after reinstalling marketplace addons.
Since it looks like 5.2.1 is out, maybe I can capture some data. Are there any other files other than the JSON database that might give some clues to why scripts play up after upgrades that I should A/B compare?
I upgraded to 5.2.1 and checked the automation_rules.json file before and after upgrade. They are both identical as confirmed by a SHA256 checksum. That didn’t surprise me, since it just contains the source code and configuration of my scripts which haven’t changed.
After reinstalling the Java223 addon, the only thing of note in the logs is:
Level
WARN
Logger Class
org.openhab.automation.java223.internal.codegeneration.DependencyGenerator
Message
Failed to found classes to export in package
I suspect you’ll have to set the logging level to trace to find some clues, but then I probably won’t know what I need to look for in all the noise.
The same symptoms as last time occurred, ie the easiest to spot was the non-functioning @ReuseScriptInstance annotation.
As usual, re-saving the scripts seems to flush something and fix the issue.
Edit: Upon re-reading your request, you wanted to know whether the automation_rules.json was the same upon re-saving scripts rather than upgrading OH. The answer that is still yes though, the checksum is still identical.