I’ve got a few instances where one item needs to be switched according to the newStateof another item. A motion detector switching on a light, or a physical switch for one light which I want to combine with another light.
Very basic one line code, in other words
Is it good practice to use one rules file, and put every possible triggering item in the array for triggers? Or would it be better to have different rule files to avoid all too many (logically maybe unrelated) triggers in one file?
Unless you have thousands of such rules, you should organise them in the most logical, elegant, and manageable way to you. Using Groups and triggering on group members help a lot in code that deals with many similar things in the same way.
If you can post some actual code, we can probably give more specific ideas.
I use file-based rules and I usually group relevant rules into the same file, e.g.:
I would recommend against one rule file, because every time you save it all of your rules are reloaded. That’s fine if there are no syntax errors, but…
As for how to organize them, I agree with what @jimtng says: whatever makes sense to you makes sense to you.
Most of my rules are relatively simple, and I’ve been planning to move them into the UI for a long time. The main benefits are being able to edit them from any computer and not having to worry as much about syntax errors. However, there’s also value to being able to apply multiple tags to a rule.
Say you have a rule that turns on the kitchen lights at a certain time of day, or when there’s motion, or when a door opens. With files, you have to pick a single grouping based on the file name. With UI rules, you can add tag the rule with everything that’s relevant: kitchen, lights, cron, motion, contact. This appeals to me. I just have to find time to do it.
Don’t do this. Like @jimtng mentions, there’s a “Member of GroupItem” set of triggers that will trigger the rule when any member of the Group emits the indicated event. You can find out the name of the Item that triggered the rule through the implicit variables (assuming Rules DSL) or the event Object for the other rules languages.
In addition, sending a command to a Group Item forwards that command to all the members of that Group. So if you have three Switch Items that control all should be controlled together, you can make them all a member of the same Group and send ON/OFF commands to the Group to control the lot of them all at once.
Beyond that, if you are using files for rules organize them as makes the most sense to you. I recommend a functional organization where rules that do similar functions (e.g. lighting) are all in the same file. These rules are more likely to have common code and common needs so putting them together makes it easier to reuse code and whatnot.
Don’t miss out on profiles too. Some of this might be able to be done from the follow profile or a script profile instead of a rule.
In the UI, definitely use tags and the developer sidebar (alt-shift-d) to find and pin all the stuff you are working on at any given moment. What I like about the developer sidebar is you essentially get to set up an adhoc organization for exaclty what you are working on at any give time. And this includes Items, Things, Pages, etc, not just rules.
For example, if I wanted to work on my time based rules I just search for “time” and pin the stuff I need.
Clicking the pencil icon navigates striaght to the entity. Once pinned, Items can be controlled, rules run, enabled, disabled, etc all from the sidebar.
So far I find that if you use maningful names, fill out the descriptions, and add comments to the code and that’s enough. I actually rarely use tags for rules any more (though it makes me happy rules instantiated from a template are automatiaclly tagged with the template ID). They aren’t always needed.
Also note that the search function also searches inside the rules/items/things configs so it can also be used, for example, to find all of your JS Scripting rules that are using the old .history instead of the new .persistence.
If you have managed confilgs, it’s worth the effort to learn the developer sidebar. It is where your organization is going to happen.
