I have per-user rules that I write once and then clone to each user, which include following the cloning-wizard's prompts to update the selected devices in the rules.
Can I clone a rule over an existing rule, updating it by overwriting it? It will there just be a new rule with the same name?
Another issue is with per-user global variables. Post-cloning, I have to manually update the rule to point each variable to the correct one for that user. Is there an easier way to do this? Has someone made a virtual device that just has custom attributes for me to store any data, acting like an object with properties? This way, when I clone a rule for a new user, I just need to select that user's device and since the rule will reference those device attributes, no manual code changes are needed.
Or it would be cool if hubitat would introduce "user profiles" that can be referenced in rules. Hey, maybe the hubitat app can be updated to transmit back user data (location, battery level, etc) in case life360 goes away...
I'm not exactly sure what you're asking for here; do you need it to have the same app ID so that other rules that reference "Run Rule Actions" or similar point to this rule instead? If so, cloning can't do that--it will get a new app ID. The name is only there for you (and display purposes) and doesn't matter for anything else. If you just want to remove "clone" from the new name automatically, I'm not aware of any way that is possible, and it's generally helpful so you know which rule is the "old" and "new" rule. But, again, I'm not sure of the reason you're asking.
If changing out hub variables isn't desirable, I see two alternatives. One is creating a connector for the hub variables, then using the resulting device instead of the variable itself. This will depend on the type of data you're storing and what connector you use, but in general, you'll need regular device actions or custom actions rather than "Set Variable" to work with these. They are devices as far as the rule is concerned (or any app; that's the entire point of their existence, to trick apps into using variables as devices).
Another is using a device like Virtual Ominisensor that has various fields of its own, including a "variable" attribute that you can set to a string. Depending on the type of data you're storing, you could also use another virtual device or even a custom driver for a virtual device with whatever you want to store.
Thanks for the tip on the omni sensor. I'll try assigning it as a "user" as using it's various attributes to store user data.
As for the rule clone, I'm just seeing how people normally update their rules that are based off a master "template" rule. So it seems like to update a rule from template: 1) delete rule (to avoid confusion from having two rules with the same name) 2) clone template rule to new rule using the old name
I'm confused; you can't clone a deleted rule. But the original and clone should be distinguished by the "clone" at the end of the new app/rule name. I suppose as long as you have a system that works for you to identify different ones, that would work. (If I had a "template" rule I never actually used for anything other than to make new clones, I'd probably name it with "Template" or something at the end and then rename the clones after they were made, so everything would always have an easy-to-understand name.)
And yeah, rooms at the moment are basically for organizing devices, and mostly just on the Rooms page itself. Room Lighting is an app that takes advantage of them to make educated guesses, and I'm sure we'll see more in the future.
I do a lot of what I think you are doing.
The virtual omnisensor suggested gets a lot of abuse and use.
Each hub has one at minimum, and it's values are changed, and looked for across 9 hubs.
"Acceleration=quiet"
As in if acceleration changes on "flo.control" then enable\disable noisemakers.
Speech output, fans, tv etc all go quiet. Or not\re-enable.
Fun part is remembering what value is associated with what action?
I would like to have a "multisensor" device that I could call an apple an apple.
Hub variables do work well, but the use of multisensor may predate them.
And do not fully apply to what you want.
Guessing.
If you just remove "clone" from file name, you have 2 rules with the same name.
Sure, but isn't the point of re-naming them to remove "clone" from the name and add something useful (like another descriptor or removing the "template" descriptor if you're doing something like I suggested above)? If not, that's my suggestion. I guess I don't understand how this ends up happening for you in your process.
You can have two apps, including rules, with the same name; this issue isn't unique to cloning and just depends on how you name apps. Most people would find this confusing and undesirable, and adding "clone" to the cloned app name is the built-in way to avoid that initial confusion. What you do before or after that is up to you.
Only time I don't do what you describe, is when I forget, and then am very glad for the addition of "clone"!!!
I have found my self confused when I get it wrong.
So basically you can't overwrite a rule using cloning, So only way to replace a rule with a new version requires a deleting the original at some point.
To set values in omni sensor, I need to use customActions.
But there doesn't seem to be a way to read those stored values into a variable.
You can read any device attribute into a variable. If it's not a commonly used attribute, you may need to use "Custom Attribute," but it should work.
A clone, again, cannot overwrite an existing app, as the intent of the feature is to create a new app. But you can remove the old one when you're done if that's what you want, and use consistent naming to help you see which rule is which (or open them to see if nothing else--you normally would to remove, anyway).
A problem with the omni sensor is that while it has custom actions to set several fields, only one of those fields is selectable when trying to set a variable.
So with only one device field to work with, my plan is to store all the values I use in the one field as a comma-delimited string. The trickiest part involves some trial and error figuring out which variable assignment syntax is needed to convert strings to numbers.
In the example rule below, it uses a omni sensor device named 'user template'.
