Can you safely rename rules? I want to say renaming devices hasn't caused any issues, they update where they are used after a bit it seems. Rules, however, did not do that for me. More specifically, renaming a rule that other rules used (in my case, I renamed rule a where where rules b and c set rule a's private boolean var)
I've noticed that when I dive deep into the Rule, where I'd actually pick a new Rule (repick the old) the name is correct/selected. OK'ng out updates the outer layers.
That's assuming what I'm seeing is actually what you're questioning.
Renaming rules that are referenced by other rules doesn't really work in a direct way. You would have to also reconstruct the other rules that made the reference.
To shed some light on how this works: The parent app (Rule Machine) is the repository of all of the rules by name, and all of the rule "subscriptions", also by name. Rule truths are also kept in the parent, again, by name. If you change the name of a rule, there is no mechanism in place to chase down the subscriptions to update them to the new name (feature request I suppose). Hence, you have to effectively rebuild those subscriptions to use the new name. When you do that, you will notice that the list of available rules will have been updated to include the new name.
It turns out that to fix this issue would break all existing rules that use the features of rule to rule. We are thinking perhaps it's better to leave it as is, and simply note the restriction in the documentation.
That restriction is this: If you choose to rename a rule that is used in rule-to-rule contexts, you must rebuild all of the rules that touch the renamed rule. Until you do so, those rules would be broken by the name change.
Just saw this thread. I just got burned big-time by going through my rules and renaming them all (trying to figure out a convention to keep them organized).
With all due respect, this is a HUGE design flaw in Hubitat and needs to be addressed. In a good design, each rule SHOULD have an ID number and the rule display name is simply a property. All under-the-covers work done by Hubitat should refer to the immutable ID number and not the display name.
If it's too much reengineering to change this, I suggest not allowing rule names to be changeable, or at least throw up a dire warning that the name change has consequences.
Thanks for the response. I've just upgraded to 1.1.6.116 a few days ago.
A made a few changes to names and then saw the old names in other rules. For example, I have a Zone Motion Controller that I renamed, but every reference I see to it in the Rule Machine has the old name of the Motion Controller, and I don't see the new name anywhere. This morning an event triggered on this motion controller didn't fire, so I figured something was amiss with my name change. Hence I searched for help and ended up at this topic.
So I hope you're right about the ID issue but that would mean changing any name willy-nilly should propagate that name to any rule that uses it. Am I missing something?
These names are not dynamic in the sense of auto-propagation, nor are the pages of apps. Underlying the name is an app id (which you can see in app details). The name won't actually be updated unless and until you open the section of Rule Machine where the name is selected and Done your way back out. But, irrespective of the name displayed, the mechanism underneath is either app id or device id (for a device, such as Zone Motion Controller).
So I'm still seeing a number of Motion Events with old names when the list is pulled up from a RuleMachine. (For example, mZone - old name). I've pulled up the Motion Event and resaved it, pulled up the Rule and resaved it, and the name doesn't change to the new one. The old name seems stuck at this point.
Now you've got me thinking about what it would take to make all of these names (which are just text strings) more dynamic, and update better. It would not be a small undertaking, but would sure cut down on the confusion. Those labels and descriptions you see in the app are generated at the very lowest level (the original selector) and then passed up the chain. The fix would be to make the ui code always look up the device name from it's id, not just use a generated string. I'm sure this is TMI, but interesting to contemplate.