I just fresh install a openhabian on RPI 3B+ with 64G SSD on USB, for test purpose, I clone my current in use openhab all info to 3B+ and run in off grid , I remove few binding it get some improvement but not much, mean problem I have now is system first load items, then rules, get hold around 10 mins, bundle still loading slowly on background, big issue is Persistence Bundle service on very end of queueing, then lot of warning that can’t read data from here, I got few rules for calc the power consumpton, it require to get previous value to add current value and database still not active yet, it cause the value always not accurate,
during the time, after rules been load after 5 mins, CPU usage turn high and keep around 9x-12x%, it makes progress become very slow, about 30-40 mins to complete all loading,
Can I set suspend all load until 50-60% of bundle have been active (especially Persistence Bundle, then start items> mapdb recover data > rules start>
if it’s not possible, how can I adjust the bundle startup sequence or priority ?
I don’t think there’s a way to do that, but you can have a System started rule that triggers a delayed change in some Item, and then only let your rules which rely on persistence run after that Item changes.
Sounds your persistence service performance is the root of the problem - save less data, choose faster storage?
the fact is persistence service is at end of bundle loading list, if I don’t manually start persistence service, it will auto activated after system start about 2x mins, during the time, I found change bundle list level won’t help, and it will turn to original list level after 2-3 time restart.
I much more prefer on Rpi, in fact, after system startup around 40 mins and let all loading completed, rpi 3B or 3b+ is fully fulfill for openhab runs as it only run openhab, I move influxdb and grafana service to another rpi,
rpi power consume much less then pc and as it only run openhab, iot service also won’t be affect by PC software (eg play high cpu load software or game)
I’ve seen this reported by many others. I think it is just a limitation with running on an RPi. Even mstormi, one of our foremost OH experts reports these sorts of startup times on the RPi.
No
You have no control over the startup sequence.
So what can you do? It sounds like you have done some of this already, e.g. moving InfluxDB and Grafana off of the RPi. rossko57’s approach is another one.
Write your Rules to check for NULL on any Item they use and behave accordingly. Then your Rules will know how to behave when not everything has been loaded from your Persistence.
Optimize your Rules to improve parsing performance. These include avoiding the use of primitives except where necessary, applying DRY (Don’t Repeat Yourself), and taking advantage of language features that result in fewer lines of code.
Move all the .rules files out of the rules folder except one System started Rule that waits for a certain amount of time to move them back. Given enough time this will ensure that Items and Persistence have loaded before any Rules are loaded. You could even use the LogReader binding to watch openhab.log for the “Loading model influxdb.persist” entry and trigger this Rule to run then.
When editing Rules, make the edits then move the .rules files over with all the changes rather than changing files in place. The high CPU usage is caused by the Rules parser so making lots and lots of changes kicks off lots and lots of rules parsing which can slow everything down.
Hi, Rikoshak, Thanks, great hints for me to keep try,
just a short question, will openhab relese this part for people to modify the boot up loading way?, not in this hacking way? I think this will finetune most of the Rpi kind equipment and run or smooth, in forum, some of them cpu keep 1xx% for few hours to get lower.
There are many issues open to address the startup order. I don’t know if it will be configurable or just be set to run correctly so Rules won’t start running until everything is loaded.
That’s correct (for the time being at least) but there should not be a need (and no benefit) to change the order of bundle startup except for a hack to delay rules loading until items are loaded. If your statements above are correct that does not seem to be your problem though.
See here for a solution just in case.
If it’s really the persistence service to delay things then possibly your persistence data is corrupted. I once had encountered that, too. Try disabling persistence just as a test. Deleting persisted data made the problem disappear in my case.
Another possible reason is that you hit swapping/paging. Check this post and see if it helps to move swap to your SSD.
I understand open adjustment on bundle startup may cause some core bundle of openhab been modified by user and cause openhab malfunction, I think that is easy to avoid, eg core system bundle will be 1st priority to loadup and not modifiable or ignore the modify, or limited open, can let bundle be 3 grade of priority, core be first, second be some persistence and communication bundle like mqtt, exec Jason path, and third for some bundle like NTP server, RSS reader, also during the time I found " Items things, rules loadup sequence will changed if I clean up the tmp folder “/var/lib/openhab2/cache and /var/lib/openhab2/tmp”, I only sure the openhab cloud will be first to load, I think an ordered sequence loadup would be much better for limited performance hardware like rpi or nas.
I am not sure the persistence service data is corrupted or not, but I keep monitor the bundle list during startup and found it’s almost last to load up, status keep RESOLVED till 2x-3x mins after startup
I finally realize when system startup with no rules, system complete loading without rules in 3-4 minutes,
and take about 6 mins extra to load the rules,
if load with rules at startup, I found “MQTT openHAB Mqtt Action” keep very long time (at least 10-20mins) at Waiting status, I don’t know why, but I am happy with change rule method, thank you all
I still think as most people have issue with rules at startup, then why openhab won’t force startup sequence to load rules when everything else have completed loading?
Because all developers use fast computers so they don’t get to see this
But they’re aware of this and are looking to resolve this but it’s not an easy thing to do.
In the meantime, see if the workaround to delay rules processing I linked to will do the trick for you.
Btw, @rlkoshak I just opened this issue.
Can you try to reproduce on your system(s) ?
In fact I did, but I got problem with openhab startup and shutdown rules, most of time, shutdown rule won’t trigger, I finally choice modify system services way, and that one is super easy although I don’t completely understand that bash command, but it works
regarding the items, I test on rpi3+ (clone form openhab operating RPI and currently on test purpose), I create a new items file with 20 items all no relate to current rules and cpu go up to around 100% for at least 3 mins
