I like some others suffer from the delay in rules starting. From the forum it seems that this is caused by openhab having to load the rules. I can confirm that during the delay cpu usage by openhab spikes.
On the forum I have found the advice to make sure the critical rules are executed from time to time, to prevent openhab from unloading the rules again. I just noticed that when openhab encounters an error, it apparently decides to unload the rules. What I did was the following.
Start openhab normally
Stop influxdb and wait for a log message from influxdb complaining that openhab was not able to report a value to influxdb
restart influxdb
test to see if rules have been unloaded by triggering them while monitoring cpu usage.
This works every time. When I cause an error using this method, the rules have to be reloaded on first execution. If I restart influxdb fast enough so that openhab does not encounter an error, the rules do not need to be reloaded.
This explains why I keep suffering from delays from time to time. Some bindings cause errors from time to time, for example because an internet site could not be reached (weather binding).
My ‘solution’ is to use the logreader binding and trigger the critical rules once openhab encounters an error.
That is sort of a misunderstanding. Yes depending on HW, OS and Java parameters, rules may get “unloaded” in that they are no longer present in memory in compiled form so on next use, they need to be parsed/compiled which takes times.
But they do NEVER disappear or break all by themselves, so normally there should not be any openhab error ! Unless your programming is timing sensitive.
They only can break if you modify them and place errorneous code, and in that case they will be gone forever until you manually find and fix the error to get them back to work.
Don’t confuse that with partially executed rules: If for example you have an uninitialized item and run item.sendCommand or access item.state, this can result in an error and rule execution stops, often silently or unnoticed.
The rule isn’t gone then but on next run it’ll stop at the same stage. Note the immediate error is in the item state not the rule. Careful programming will test for items before it uses them so rules can run til their end even with bad state items (which is hard to avoid at all times).
So an (elaborated) retry mechanism.
That is an interesting approach but will only work when the causing items by chance change in the meantime.
I’d run an initialization rule instead that validates all or parts of the items and eventually reinitializes them. Like a Java exception handler.
