Hi all, I have a set of rules that turn down my radiators when windows are open and turn them back to schedule mode when a window is closed again. I have about eight of these for different rooms.
My question is -- should I keep them as eight independent rules or merge into one long rule? I initially assumed having them as separate rules was going to be less resource intensive but now I am not sure. Is there any difference worth even thinking about?
Bruce (@bravenel) is the authority but I seem to recall him saying there was no "penalty" in having more, small rules. I do it because I think it's easier to write them and, when necessary, edit them.
Ditto! I learned this the hard way, having once written a full Inventory/AR/AP package for a medium-sized wholesaler. The package took 2 years of active development and by the 2nd year I was oh-so-clever in the use of loops, counters, conditions, sub-routine jumps. ...Then I had to maintain it. I can't tell you how many times I thought "What was this guy smoking when he wrote this!?!?" Over time, I switched to what I call "flat" code --dumbed-down, easier-to-read, linear logic. So what if it took more machine cycles? That's what we have machines for.
I agree with each of the responses so far, simpler rules will in the long run be easier to maintain, and a number of smaller rules is not an issue in a general sense.
The only other point I would make is that applying this approach to your current situation with the thermostats is, in my opinion, ok because there is very little chance for the number of rules growing in any significant way, and the overhead in maintaining the rules is relatively small. If you had a situation where the number of devices could grow significantly, then you start to get to the point where an app which can apply the same logic reliably starts to make sense, with you filling in the gaps with devices, etc. Does that make sense... I'm not suggesting you need to do that here, as there is also a cost to developing an app and maintaining it.