i believe everyone is aware on the first .rules run (or save after change). i think it is some kind of ocmpilation of the .rules files, this on a raspberry pi shoots the CPU usage to 100%+ ( don’t ask me how but it is more than 100%.
every time openhab is started the same amount of time is used, it would be a good idea to check if .rules file has changed (time stamp check ?) before recompiling them, otherwise use existing (binaries ?!).
Each CPU core gets 100% so a fully pegged CPU number for a four core processor ( I think the Pi 2 and 3 have 4 cores, maybe only 2) would be 400%.
That being said, the spike is caused by the rules being parsed and loaded into memory. Rules are not compiled like a C or Java program but are interpreted like Ruby or Bash. There are no binaries to reuse when OH restarts.
Nothing wrong with maximum CPU usage (it’s calculated per core, on a 4-core RPi2 or 3 you’ll see close to 400%).
That’s how it works (Java, Xtext, …), you cannot change that fundamentally.
You can adjust the sensitivity (how often to check if rules changed before recompilation starts) in the General section of openhab.cfg.
You shouldn’t be restarting OH often, and if you change one rules file, it’ll only recompile that single one (which shouldn’t take noticeably long).
If it does recompile all of them, that’s an error, and - just guessing now - you might have the problem because you have a rule like ‘on system init … exec(touch all rules files)’.
Someone posted it once, I think it’s even in the Wiki. It’s meant to speed up retrieval of persisted values, but it would apply not just on system startup but on every rule change, so it does more harm than good, and I removed it.
Another possibility is a rules file that fails to load, resulting in a busy loop. Increase script debugging to get hints on that.
Unless you are on OH 2. Unless something has changed I don’t think JSR233 works on OH 2 yet. Though it isn’t actually listed as incompatible on the docs. Is that an oversight or is what I’ve read incorrect?