[NEW APP] Room Lighting

Yeah I do see it there, thanks. I noticed open is also missing from the off options as well. Seems like both closed/open should be in activate/turn off, but at least there is an option.

The list gets too long and cumbersome. So only the more obvious means are in the list, and Custom Attribute is used to pick up the remainder. Otherwise, every app tends towards becoming Rule Machine.

Others missing: motion inactive, illuminance rises, acceleration inactive, lock locks, etc etc.

1 Like

True, but motion and contacts are prob some of the most common means to activate/turn off lights.

1 Like

Motion active almost always is used to activate (not turn off) and motion inactive is used to turn off (not activate). So why populate all possible choices into every element of a UI?

There is always going to be this tension between 'completeness' as an abstract ideal (that you are implicitly advocating) and usability/understandability of an app. Room Lights started out much simpler than it is now, and it make no sense to me to keep pushing into more and more 'features'.

So I resist.

Tell me, how many instances do you have where a contact closing is the obvious means to turn on a light, as compared to one opening?

2 Likes

Yeah the motion inactive would rarely be used in turning on a light I agree.

Regarding contacts I was setting up a fade time after the door was closed for a bathroom in this case. So for example person enters bathroom a light turns on low, door closes and light fades up.

2 Likes

It appears that if you have a Transition for Activation set and a Turn Off event happens during the transition, it doesn't stop the transition:


So by pushing the toggle button to activate the scene, the transition started. If the toggle is pushed again before the transition completes, the lights turn off... then back on when the next step of the transition fires.

Presumably Turn Off events should cancel any remaining transition steps from having turned on? (And vice versa, if activation happens during a transition to off, though I haven't tested that.)

1 Like

I'll look into that. You're right that turning it off should cancel the activation transition.

Fix will be in the next release.

3 Likes

I'm using CoCoHue, and in my Room Lighting app, all my Hue lights are shown as Type: null and don't give me any Activation Settings (so I can control the brightness, etc.). What am I doing wrong?
-Hank

1 Like

Click the null what happens?

1 Like

Show the Current States from one of these lights device page.

omg, i'm a dummy, sorry. i thought i had tried that but i think i had only clicked on the device itself. i see now that you can set the activation type from there.
-hank

1 Like

There is still something quite funky about this. It shouldn't have been null. Please show the Current States from the device page for one of the lights.

1 Like

I have a feeling the answer is going to be "Use Rule Machine for that" but figured I'd ask anyway. I have my kids room setup in RL with a motion sensor so when they are playing in their room, the light and the fan come on. I want to limit the fan to not come on when the temperature is below a certain point, like maybe 72. However, the limit activation options seem to apply to the whole room.

Is there a way to do what I want in RL? If not, I'll just make a rule to run when the RL instance is triggered. On that note... how do you do that? I know that scenes used to be a trigger (I have a goodnight scene that turns off all the lights and a rule that triggers when it activates that does a few things like close the garage door that can't be done in the scene) but I don't see that as an option anymore in trigger events. So how can I make a rule that triggers when a RL instance becomes active?

Every RL instance has (or can have, if you elect to create it within the RL setup) an "Activator", which looks and functions a lot like a traditional switch. One of its features is to show "On" when the "scene" (we're moving away from calling them that...) is activated.

Thus an RM rule or other automation could easily trigger off of the RL Activator turning "on" or "off." Does that help?

BTW, I agree with your assessment that it's wise to break the Fan-related portion of this automation into its own RM rule, replete with "Required Conditions" you mentioned.

1 Like

I was going to just do exactly this but then couldn't figure out how to make it trigger, so I figured I'd go ahead and ask if it could be done in RL while I was at it.

Does that help?

It does... but I don't want to create a bunch of devices. I'm wanting to do similar things for other rooms. I don't see why that is needed when in the logs I can clearly see an event for the activation. Why can't that event be a trigger?

I hear you loud and clear; "excess" Devices, Rules and Hub Variables do make for a cluttered working environment, but they can also greatly simplify the design and troubleshooting of your automations. Your future self will thank you when it comes time to review the Fan Rule in RM, and sees a straightforward 'RL Kids Room Lights Activator':On trigger instead of a work-around (see below for one such 'trick').

Believe me, I felt the same way you do (about having to create more devices) and a year ago would routinely try building things (like dashboard tiles) using only hub variables, instead of Variable Connectors (devices) the way I was supposed to. Got me into lots of trouble, in every possible way. Lost a lot of Forum cred in the process...

...so, if your inclinations derive from "how we did it on my old hub", I offer this advice in the spirit of adapating to "how things are done here in Hubitat." :slight_smile:

1 Like

However, there is a sneaky way to get closer to your desired goal while keeping the UI as minimal as possible...

  1. Create a single Virtual Button device – let's call it "RL Events" – with as many buttons as needed (start with one button per RL – you can always add more);
  2. In each RL instance, include the VB; in the grid's far right column, declare which numbered button on "RL Events" should be addressed at "On" or "Off";
  3. Use those button Events as Triggers in RM.

That should get you well on your way. For "virtual" connections like this, I like to sprinkle a generous number of "Comment" actions into my RM rules, so that my future self knows what the heck is going on. :wink:

PRO TIP: I like to add a final Action in RM to "Push" "Button 0" of the VB, which visually "resets" it between events. Judgment call on whether this is necessary, but since it was sometimes mandatory on my old controller, I still follow this practice.

1 Like

I've never used another hub. Been using Hubitat since sometime in 2020 I think. I'm somewhere in-between a power user and a set it and forget it type of user.

My problem with creating more devices is what to name them so that in a year from now when I see this list of devices, I know what is actually what.

I already have a hard time naming the RL instances and rules so what when I look in the logs I know if the log entry belongs to the device, an associated rule, or some other app. I suppose I could create a device called "Joel's room fan but not really a fan just a device to let me know something else triggered." I'm being facetious on purpose but I hope I get my point across.

I really really dislike the approach of "just create a virtual switch device to represent on and off". How about you just let me check if something is on or off? Like, why do I need a virtual device to turn on so that I can create a rule that when the virtual device turns on, turn on a real device? When you say it like that, doesn't that just sound silly? Just turn on the real device.

EDIT: Or.... add a section to RL under "Means to Turn Off Lights" that says "Rules to run when activated" and another section that says "Rules to run when turned off". I feel like there should be ways to do this without creating devices that don't actually do anything.

EDIT2: Or give each RL instance an invisible virtual switch. Just like how each RM instance has a private boolean.

1 Like

"Use RM for that" is one possibility. Another way to look at it is that you have two distinct sets of devices which happen to have very similar triggers. You could use two RL instances, both triggered by the same thing (motion) but one with a restriction and one without.

3 Likes

Circling back to this part. I've set up some test RL instances, and it looks like a functional way to spell this is:

  • Individual scenes: Indicator for Scene Set
  • Parent scene: Indicator for Group Any On

The main drawback seems to be that the indicator gets set 4-5 seconds after the trigger happens, which means 8-10 seconds later for the parent. So any attempt to toggle the parent off within 10 seconds after turning a scene on will fail, either by activating a different scene or by "doing nothing" (activating the scene that's already on). That's consistent with @bravenel's comments above that the Indicator logic is overly heavy and to only use it if required.

I've concluded that the better way to approach this may be by using the Button Controller as a parent -- IF any scene activator is on THEN turn all off; ELSE Choose switches per mode END-IF. If the Button Controller acts on the Activator device rather than Rule Machine listening to button presses, the Activator reflects the new state immediately rather than 5 seconds later. The main thing that doesn't get me is transitions on mode changes, but that could be accomplished with a RM rule, probably. (On mode changes, if any on, same Choose switches per mode as above.)

1 Like