I want to thank you for the great work about OH 2.5. To reinclude a lot of stuff from eclipse looks very fine.
But I discovered some behaviour changes from OH 2.4 to OH 2.5.8
In OH 2.4 only the running timer in the rule which is reloaded are crashing if they are run to end before reload (totally clear, because timer variables are recreated by reload of rule). In OH 2.5.8 it looks like all timers in all rules are effected not only the times in the reloaded rule?
It looks like the rule engine is a little but more instable in OH 2.5.8. If I change/reload rules more then 20 times at the runtime of OH (I mean changing rules over a period of 1 to 10 days) the rule engine will stop to reload changed rule files. I have to restart rule runtime binding via console to get it back to work. Is this a known problem?
In Visual Studio code I get sometimes the message, that the .rules-file which is open is no longer accessable. I have to close and reopen it, to solve it.
It looks like the sequence of loading add-ons (bindings) and .rules file is different. .rules got loaded before bindings are fully loaded. This causes problems in my rules which uses pushbullet or mail action. I use this code:
val mailActions = getActions("mail","mail:smtp:samplesmtp")
rule "Test mail"
when
Item Test is changed
then
mailActions.sendHtmlMail("mail@example.com", "Test subject", "This is the mail content.")
end
At start of OH and after load of rule file the log tells me, that this cannot be done
val mailActions = getActions("mail","mail:smtp:samplesmtp")
due to not loaded binding. To avoid this I put the line into every rule instead on top of the rule file outside of the rules.
It should generate an error for all running Timers that were created in that .rules file. It’s been well over a year since I’ve looked at 2.4 so I can’t say for sure, but I believe that was the case then too.
This is the first I’ve seen it reported. Normally I’d say create an issue but OH 2.5 core is frozen and all new work is being done on OH 3 So you’s have to load the OH 3 snapshot and see if the same behavior is still there. There are lots of changes to how rules are loaded and a new rules engine so I’d be surprised if this would still be a problem. And it’s an exceedingly rare problem given it’s never been reported in the more than a year and half since 2.4 was released. What’s the CPU doing when it stops being loading rules?
The sequence has always been undefined. If it’s always loaded properly for you it’s largely a matter of luck, and your luck has run out. This is an issue that has been well known and well discussed since OH 2.0 came out. Note, when using the NGRE this is not a problem. Rules do not load until everything else is loaded.
As far as I’m aware, this has always been required for Actions connected to Things (i.e. not the old style 1.x Actions).
If I were to guess, this is the root of problem 2. Every time there is a file event OH is going to try and reload that file. On an RPi loading .rules files can take quite some time and consume lots of CPU. And OH queues up the changes so if any file (even the same one) changes three times there will be a ful reload three times. It becomes very easy to end up in a case where you’ve starved the machine of CPU and the rules just wont run because OH is stuck in a reload loop.
Alternatively, this could be a symptom of a bad network connection between VSCode and your OH. Are you using Remote SSH or editing through a SAMBA share?
