If you are on an RPi this is known and expected behavior.
You can speed things up a tad by avoiding the use of primitives in your Rules. I’ve seen some reports of that saving several minutes by itself. I see a whole lot of primitives in those Rules.
A RPi 1 is not recommended for use as it doesn’t have enough RAM to run OH properly. A RPi 3 is probably the most popular host for OH right now, though in the coming months I expect the RPi 4 with at least 2 gig to replace that as most used. For most users and most uses the RPis are perfectly adequate, though the startup times are exaggerated.
Also, this may be obvious but it should be stated anyway, long Rules will require more effort by the computer to parse than shorter Rules. I see lots and lots of ways you can shrink this code by at least 50%. For example:
- use Design Pattern: Associated Items and Design Pattern: Encoding and Accessing Values in Rules to replace your initialization Rule with something that looks like
import org.eclipse.smarthome.model.script.ScriptServiceUtil
rule "Rollershutter Kueche Init"
when
System started
then
// Wait for everything to be loaded and parsed before trying to initialize stuff
createTimer(now.plusMinutes(30), [ |
RollerShuttersInitialize.members.forEach[ rsItem |
val initVal = ScriptServiceUtil.getItemRegistry.getItem(rsItem.name+"_Init")
rsItem.postUpdate(initVal.state)
]
])
end
Make sure that the Init Items are restoreOnStartup.
That takes a rule from 112 lines to 13 lines, including the comment.
The second Rule is probably a nightmare for the Rules Parser to handle. You ints on almost every line of code. And you don’t need a one of them. As rossko57 suggest, just use Number. It is far easier for the Rules engine to figure out the type of stuff at runtime than it is for it to parse and ensure the type of everything at compile time. When you use primitives you give the engine no choice but to figure it out at compile time greatly increasing your Rules parsing time.
A lot of this second Rule also looks like it could benefit from Design Pattern: How to Structure a Rule and Design Pattern: DRY, How Not to Repeat Yourself in Rules DSL and perhaps Design Pattern: Separation of Behaviors which can separate some of the calculations into another Rule which will simplify both sets of logic. This is especially the case as it appears that the second and third Rule are very similar in parts. For example, move all the stuff at the top of both Rules where you calculate the upTime and downTime into their own Rule that gets triggered when Rolladen_EG_Kueche_Nighttime_Mode changes and store the result in a Items. Then your second and third Rule don’t need to duplicate that logic and can just use those Items.
I realize that most of the triggers are commented out in the third Rule, but they could all be replaced with a Group and the Member of trigger.
Member of Rolladens changed