I have a number of Rules that are run from within other Rules.
I am upgrading/rewriting v5.0 rules to v5.1.
So before rewriting a Rule to v5.1 it would be good to determine which other Rules invoke it.
Something like the list of In Use By for Devices..but for Rules
3 Likes
I requested this awhile ago.
1 Like
Okies and I assume nothing came of it?
How can we get some focus on this @bravenel ?
This isn't on our list to do; we can add it to the list, but it's not going to be a high priority. There is no mechanism to show this information anywhere useful.
Add me to the list wanting that feature...
1 Like
Definitely need this!
I requested an alternate solution to provide a complete listing of all rules. Dump into a text editor and could easily find who calls who. Also a lot easier to debug a complex set of rules when everything is in one listing.
2 Likes
yea I have same issue .. would very much like some solution
1 Like
This would be great
Even just an exported file.
Or, a "referenced by" list (or button with a pop-up) on the rule's initial display page.
1 Like
I also would like to see something like this. I do use the Run Rule Actions a lot and being able to tell which rule is calling which rule is pretty important when debugging items.
1 Like
@bravenel please look at the idea of a single list of rules with their called rules
Tasker has a great menu item for their tasks, that gives you calling profile.
@rob9 wanted a way to see the connected rules on the home page of the rule.
How about one link for a popup display with the Calling Rules and another link for the Called Rules. That would not take up much space.
An off the wall suggestion would be a network diagram like the Z-Wave links.
I also use many rules where the result of a rule is a Hub Variable or Virtual Device that the next rule uses as a trigger. This limits the scope of each rule and they only run when needed.
This is not something that's straight forward to accomplish. Rules don't have any way (currently) of even being aware that another rule might reference them. So anything along these lines would entail a major undertaking. Not currently something I'm keen on taking on.
All of the rule calls are in the Rules. Just like Tasker there must be a structure to the database behind RM that could be used to determine the rule connections. In a past life I wrote SQL queries to get that info.
Yes there are things in a database, but that isn't relevant to how this feature would have to be addressed. There is no SQL query that would return what is needed, in fact a new 'database' would have to be built and corresponding UI elements created along with all of the associated methods to make it work. Like I said, a major undertaking that can't find its way very far up any priority list for engineering resources.
Appreciate the level of effort here. But this makes it very challenging when debugging. I love the device to rule connection as I can quickly look at any rule that impacts that device. It would be a significant help to know which rules call other rules.
As one of the first to request this, I suggest we quit pestering @bravenel and document our setups ourselves somehow. There is always the Notes field to enter that kind of information.
1 Like
I wouldn't call it pestering. Customer feedback is obviously very important to the platform. And when the Hubitat team says, and I paraphrase, "I don't see the effort here being worth the outcome and therefore will not get prioritized very high" then it means one of two things.
Either we haven't described the problem well enough, or it truly isn't worth the work.
The reason I went looking for help, and found this thread is because I use a number of rules that have no trigger. I use them to combine commands that I use repeatedly in other rules, sort of like a macro. I then use the run rule events command to run this "macro" rule.
But this of course makes debugging difficult as I can trace from the device to this "macro" rule but then I don't know what is calling the macro rule.
I guess I could stop doing this and just duplicate the commands in every rule where I do this.
Or perhaps I can add a log command in to the calling rule to indicate that I am calling this rule, or something like that. Definitely open to suggestions.
2 Likes
Or, the feature request fails for other reasons.
This is the case of no good deed going unpunished. Adding the ability to call other rules was a nice feature add to RM, and allows for uses such as you describe. The feature request here is to undertake a large and not well defined effort, not to improve automations or even to add new automation features, but to assist in documenting your rules. It's basically static information, that would further increase the size and complexity of RM, etc. I'm not a fan of this, and certainly can't put it ahead of other things we are working on (this is probably a steady state situation).
What's worse, is that over the past few years we have worked to reduce certain complexities in RM (the most notable case being the introduction of Hub Variables to replace RM Global Variables). This request pushes in the opposite direction in terms of loading RM up with inter-rule complexity. Again, I'm not a fan of this. This particular feature request is one with a lot of hair, a lot of unanswered functionality questions (how to access the information, for example). Feature creep is poised to jump out of this no matter how it were to be approached. Reading the posts above carefully reveals this:
No thanks.
1 Like
This request does not add to complexity of the database. All that we want is a query that looks at the links between rules.
I don't want any additional data in the rules database. Most of my desires are for changes to the way the data is displayed or additional queries so users can document their rules and see how they fit together.
Think you missed the part above where it was stated that the information currently isn't stored in the database in a way that can be retrieved via a query and that to enable this functionality a new table or database would be required.
2 Likes
Really? But you don't actually know anything about this.
3 Likes
