I'm currently migrating from Smartthings/Webcore. One of my automations I had there was a list of about 20 dimmers. When each of these were turned on, it's value would be set to a variable's current value. (this value changes based on time of day, and i've already migrated that portion).
I've seen several threads that let me accomplish this for a single switch, but I really don't want to maintain/create 20 different rules for this. Is there any way to accomplish this in a single rule?
Someone else may have better ideas, but if that's exactly what you want to do, I'm not sure there's a better way. A rule like this would work, and it's incredibly simple to write so wouldn't take long aside from needing several of them (but as people used to say: "rules are free"):
Trigger: Dimmer 1 turns on
Actions:
Set Level: Dimmer 1 to (global variable name)%
You can clone rules, but for something this simple, that would probably be messier than it's worth.
However, you might also use this as an opportunity to ask yourself if there's another way you could handle this automation. For example, if you could tie your time of day into hub/location mode, you could probably use Mode Lighting or Motion Lighting to get what you want. A custom app might be necessary if you want to do exactly what you're doing without changing anything (or resorting to webCoRE on Hubitat, which has been ported but has historically been problematic; I've stopped using it but some people have used the new fork with success).
Thanks for the feedback. I have several other automations that follow something similar to this which is another reason I didn't want individual rules. I remembered I actually us virtual dimmer for this and not a variable. This allows me to set the dimmer value from a dashboard, so in addition to each switch setting the value when they turn on, all the dimmers (currently turned on) also mirror that virtual dimmer's level when it changes. I do something similar for my RGB bulbs, with a virtual RGB bulb. I think the piece that I'm missing is when the rule is triggered, to get the device that triggered it and modify that device, but not the others in the event list. I haven't seen any system type variables (i think it was called $currentEventDevice) in the 'devices' list like I used in WebCore.
I'm not real familiar with Groovy, but I am a developer. Do you think this would be a pretty straight forward custom app? I would definitely like to stay away from WebCore on Hubitat and use the more supported methods.
You can't do that (set variables to a device object) in Rule Machine, which is why you'd need separate rules for each. You can get the device name, but that won't be any help here. What you're suggesting would actually be a (I think) neat feature request and might be easier for them to implement that a full-on arbitrary device variable, but who knows.
You can do that with global variables in Rule Machine (look up "global variable connectors") if that is of any help, though it won't do you much good in other apps, which is how it sounds like you're also using it.
Maybe, but there's a bit of a learning curve since it's not just Groovy but also the sandbox and (I would assume this is how they implement this...) superclasses that Hubitat apps run inside. It's very similar to SmartThings if you are familiar with that platform. Groovy itself is syntactically similar to Java (and compiles to the JRE) except dynamic in nature.
Hold my beer ... I think you could do it. I don't understand your rule 100% but I also migrated from webcore when I came to hubitat 2 years ago. If you would post your piston and your existing rule, maybe we could figure something out for you. I, personally, would need to wrap my head around what you're doing before I could start to work it out, though.
[EDIT]
I know that you shouldn't overcomplicate things in Rule Machine, KISS is the best method, but as long as your rule isn't running running running, you might get away with it. So, I know better, but I'm still gonna try it.
I went through several iterations of this, it's deceptively simple at this point:
This is the one for updating the 'on' switches when the virtual switch changes.
Appreciate the help!
I think that @Cobra might be of some assistance here. I'm terrible with variables, but I'll try to work this out.
[EDIT]
Can you put in "girl" terms what the outcome of this rule is? if you change one of any dimmer in the group, then the rest follow? is that correct?
Not quite, it's more like a shared rule for multiple switches. Just by adding a switch to that dimmer variable, it follows the same 'rules' as all my previous dimmers. I don't have to recreate/clone rules each time I get a new z wave dimmer.
The dimmers don't directly affect one another, but when they're turned on individually, they all get the same value ( from a virtual dimmer). It's similar to a mirroring a switch, but with multiple switches mirroring it. And with the option to only mirror it when you're turned on.
Did that clear it up at all, or make it worse?
Unfortunately not, I don’t have rule machine installed on any of my hubs and have never used webcore either 
Andy
Would the %device% variable help with this? It states which device triggered the rule.
You have a bunch of switches at the trigger
Action:
Set Dimmerlevel to masterdimmervalue
If %device% is Switch1
Set dimmer1 to Dimmerlevel
Else if %device% Switch2
.........
On and on forever..
This isn’t as elegant as webcore but it works
EDIT: I just realized I brought this post back from the dead. 
@Hasty1 thanks for resurrecting! I am also new to hubitat and am trying to get a similar piston replicated locally to get rid of the crushing delays. Running the below rule works magically for a single dimmer (Leviton, Generic Zigbee Dimmer), but when you try to add multiple dimmers to the trigger any of them will essentially turn on all of the lights in the house to that set global dim level based on mode. With about 20+ dimmers in the house I really would like to avoid cloning the rule for each dimmer... (Note that I only have two dimmers added at this point and had a suspicion this would happen so I only added them both to the first day mode conditional action).
At the moment I do not see a lot of configuration options for the trigger, and your suggestion seems like a ton of editing for each mode change listing each switch, leading me back to potentially just cloning the damn rule in the first place being less work.
Perhaps the 20+ rules will not bog down the hub? That I am unsure of so am looking for some advice from the forum.
Thank you for any suggestions.
Fizz!
It would be a heck of lot simpler if someone would just write a small Groovy app to do this. There isn't much to it. It's the sort of thing I could whip out in 10 minutes.... Ah, perhaps I shall.
So what is it, dimmer-per-mode, but just for the dimmer that turns on, right? Could almost be a variant of Mode Lighting too, because it does dimmer-per-mode for a dimmer that turns on, but then acts more like a group.
Further to the above: This is about 5 lines of code to add to Mode Lighting. This can be in the next release. It would be a simple option to select that it only set the triggering device. Have to figure out what to do about an option concerning adjusting lights when the mode changes. It could be that with that option, it adjusts any of the triggering lights that are on. Will have to think about that one a bit...
Linking this thread to the code I ended up actually using for this. My use case was a little different than dimmer level per mode. I have a Global virtual dimmer that all the dimmers in my house mirror. It fades slowly over time as the night progresses. Haven't looked at that code in awhile, but it's been working for me. The only odd quirk is if you turn on a light it turns on to it's current value, then adjusts to whatever the global is.
Turning on a physical dimmer will always do this, and there is nothing that can be done about. Nothing, that is, except not using the physical switch. If the light is turned on by some other means, a button device, a motion sensor, an app, etc., then it can avoid this burst of wrong level.
I once tried an app to fix this by quickly turning on dimmers when the mode changed to set their level to a new level, and then turning them off. Sometimes this worked ok, especially if no one was in that room. But for someone in the room, usually they'd see a flash of light, and wonder what-the-h was going on.
Could Mode Lighting also have a feature to send level or CT commands to devices that are off as well, but have level prestaging or color prestaging enabled? With the recent addition of level prestaging to the GE Zigbee dimmer driver, this is becoming a more widespread feature. I have this working with multiple rules, but it would be nice for others that may not be comfortable with RM.
Exactly what I was hoping mode lighting could do. Can you share the code to implement or we need to wait for a mode lighting update? I am new here so apologies for the uneducated questions.
The next use case I had previously and sought to replicate was when the mode changes and if lights are on (and not already <= to the new value) they fade to the new value so it is unnoticeable to the occupant. Perhaps this is another enhancement to mode lighting.
Even if lights don't support level set w/out turning on, I have found if you fade correctly you won't see a bright jump.
Lifx does a great job of changing level/color/temp throughout the day without turning on so you can truly have a circadian experience. Just have to block your switches on and let the bulbs make chaos on your WiFi network. Which is why I have found dimmers and switches to be easy for the rest of the household who don't share the same "automation enthusiasm".
Motion lighting isn't always an option in my opinion if you are passing through spaces and don't want to leave an illumination trail behind you...
Thanks for the help and very cool possibilities here.
Fizz
I don't know which prior comment you are referring to.
Most users, just from observation here, use way too long a period for turning lights off that are turned on by motion. For any transient space, like a hall, 1 minute is ample. The only place more time is needed is where someone may be in a room but not moving. A woman putting on makeup at a mirror is a good example. Of course, in some situations, no amount of time will be enough, for example sitting at a chair reading. For those situations, a button controller makes sense; set the lights to an appropriate level, leave them on, hit another button when done. Reading in bed at night would be a good example of where that works well, with a bedside button device.
Light switches are so 1900s technology, it's a shame to put such effort into them...
This feature will be incorporated into Mode Lighting for the next release, 2.2.5. Mode Lighting already has all of the needed UI and functional elements to implement this feature, so I chose not to write a special app that does it.
Hi @bravenel when this feature is implemented would you consider enabling some additional lighting specific features like the transition time or ability to ignore if the light is already less than the dim to value (assuming you are going from a higher value to a lower value).
Essentially the user experience would be:
Mode lighting to accomplish auto brightness if physical on (with fade option), and auto adjustment for lights that are already on (with fade option and ideally logic to ignore for unique situations).
IE if I turn on the kitchen light in the Morning it will come on at full brightness, if the light is on all day and the mode changes, it will gradually dim to the new level but potentially slow enough with the fade so it is not a noticeable reaction. However if someone dims it lower intentionally, and it is lower than the next mode level, it remains unchanged and does not the brighter. Note that if a physical change interrupts the level transition then it is cancelled for that device only.
The reason the fade is critical is when you are using physical dimmers, an instant ramp from 1% to 100% is very jarring (a longer fade is needed to correct) while going from 100% to 1% I have found that if a low or no fade you can time it really nicely to not be noticeable at all. Now this would all be moot if Leviton would release an OTA to support level adjust without turning on, but such is life.
Hopefully these are generic use cases enough to help others, and wanted to request during the implementation process.
Thanks for considering.
Download the Hubitat app
