CT or RGB mode as a condition

Is it possible to add things like the colour mode state as a condition?

The use case for me is I have motion lighting app turning on the lights to different kelvin or colour depending on the mode. But i also have switches so at night when everyone is asleep when you walk around the lights come on red and a low value so not to wake people up but still be able to see. But in a emergency i need to be able to turn the lights on to a white and brighter so in my switch rule in the mode I have a kelvin colour and a brighter level. The issue is due to the rule if the light is ON it will send a OFF and if it's OFF it will turn ON to the correct value. So as the lights ON it then needs to turn OFF to turn ON again so i came up with this.


I would like to have a trigger rule that sets a global variable BOOL that if the lights in RGB mode go true.
Or just have the condition that the lamp mode is in RGB.
This way when you flick the switch it will go straight to white as it should in true then you flick it again and it will go OFF false.

You could have a WATO read the attribute and determine the color mode and turn on or off a virtual switch. Then you wouldn't need the variable. But I don't know any way to read that from RM. What exactly are you trying to use this information for?

1 Like

I actually found this after and got it working but it would be nicer/ neater if its in RM .

as another state variable basically. I can't just use ON as then I won't be able to turn the light OFF.

So i have contacts that are the light switch but these need to trigger the rule if they open or close so they work in two way and also due to the nature of the system it would get out of sync if you only did ON on open or something.
Open or close trigger
IF
Lamp is OFF OR (Lamp is ON AND IN NIGHT SLEEP mode AND Colour mode is in RGB)
THEN
Turn ON to Kelvin X and level Y depending on mode
ELSE
Turn OFF

The extra bit is the OR and the AND's in the bracket. Without them when the motion sensors at night turn the lights ON to the "motion colour/level" (RGB mode) and you use the switch the lights turn OFF (because the only monitored state is ON). If you then use the switch again it will set to the correct "switch colour/level". With this extra state monitor it can tell that I don't want the lights to turn OFF I want them to go to a brighter level and white. It works great :grin:

When you set the lamp to color mode, you could also turn on a virtual switch to "know" that or set a variable in RM. That might be the easier way to do it.

That's the problem there is no way to monitor the colour mode change in RM. Unless you mean to move from motion lighting to RM for motion events as well? That wouldn't work aswell though as there is still no colour per mode in RM only in motion lighting. The inconsistency of their apps is abit mad :roll_eyes:

Ah...i didn't realize that the original automation wasn't in RM. I don't use many other apps for that specific reason.

I have 2 one is motion lighting for the sensor then I use RM for the switch due to the complex nature of it.

That rule in Motion Lighting could turn on a virtual switch though. And that could take the place of the boolean variable.

Yeah that would work :thinking:, motion lighting does do switch per mode so I could have that tun on and off only in the specific mode. The would need to turn off the switch again though in the RM rule and depending on the position of the evaluation it would or wouldn't work (would be nice to organise what happened when). This is because currently once the rule runs it makes the colour mode part go to false so it's always in sync. But if l it went false before you wanted, it would mess up the rule.

I'll take a look see what's possible using the built in apps again.

Your motion lighting app doesn't turn the lights off too? If so, you could just turn the switch off then.

Yes it does but obviously it won't turn it off until the detector times out so if your still in the room and used the switch, then it will be out of sync untill it turns that off. So the rule will also have to turn it off as soon as it has done it thing.

Then you should turn the virtual switch off whenever the lights are turned off too. You're really making this a lot more complicated than it has to be. If you want to do this funky stuff with 215 modes and CT vs RGB lights, it's going to be difficult to recover from. You sound like you're surprised by this.

Yes and no. It needs to also become off when the lights are still ON. It's complex because it's not standard I know that, it could be easier if RM exposed the devices capability's as conditions. WC made everything easy by exposing all capabilities to be commands or conditions. When you have that much options you tend to dream big :grin:. I'm not surprised by having to go around the house's to get what I want, I'm just trying to find the best way to do it without using WC. My house did so much more when on ST but it was in-consistent due to outages. I took a trade off when coming to HE, I'm not saying that's bad btw, everything now works as expected when I want it to! Now it's just a case of making things do stuff people expect it to do when they need it to. That's the fun of having a automated home! Switches/PIRs turning on and off lights when needed is basic and doesn't do much to improve your home I do that for my day job and it's been around since the 80s.

This is the 21 century so having lights come on the same colour as what the sun is producing outside during the day (circadian rhythm) and lighting your way at night without rousing everyone; then knowing that when you do something during that time means it should do something else it's true home automation to me.

I agree. But in this definition, it shouldn't matter what state the lights were in when you change them because they shouldn't go back the way they were, the should be set based on the current time.

And I have to disagree about circadian rhythm. I cannot stand daylight white bulbs inside. It makes me feel like I'm under sharp florescent lights. Growing up we always had soft white bulbs so that's what my body is used to. I had a hotel room a while back that had all daylight bulbs and my own body rhythms were way off. So, it's all what your body is used to.

You also have to admit, with all of your modes you are really asking more of the system than even most of the power users using HE. It seems to me, things would work a lot better if you made them even one notch simpler. Yes, everything would be easier if this or if that. But you have to work with what you have. The reason that rule machine has restrictions is to make it work in the local infrastructure of HE. If we had all the cloud computing power of ST then we could have something like webCoRE. But you can't have one without the other (as evidenced by the folks who've tried...me included). So, everything is a trade off...unless you want to build your own system from the ground up...hardware and software included. And i dunno about you but I don't have the time or the brain power for all that!

1 Like

My statement was slightly wrong I should have said if you do something "different" during this time. Otherwise I would agree. I want them to revert back to how they were on the next "cycle" IE next time the motion rule turns them on. Normal for me would be to use the motion to turn on and off the lights to the correct mode level/ colour. But if I use the switch at night it's because something has changed and I need the light to come on in a odd/ emergency situation (baby has just projectile vomited everywhere :nauseated_face:) and the keeping baby and us relaxed during the night has gone out the window! We need to be able to see everywhere and well! Obviously this has happened, image of me grabbing my phone scrambling around logging onto the hub page and trying to set the lights while baby is screaming and wife is shouting get the lights on its everywhere and all over me and I don't know when to put her down!

That's the whole point of circadian rhythm you shouldn't have daylight in the bedroom it's stops everyone sleeping. It should be yellowy in the morning, more red in evening then daylight only in the middle of the day. This helps you natural body clock to be active during the day and sleep well at night. That's why so much development is in this area in my industry. Putting daylight lights in a office makes people work more efficiently in the day, but it's like putting everyone on a caffeine drip, eventually people crash. Because all there natural rythem is messed up and they don't sleep when they should, so it's actually better to have them just more efficient in the middle of the day and have the lights change to the light colour that is out side. It's been proven to reduce sick days in staff, migraines and reduce people's risk from mental illness in stressful environments. It's also helps kids with ADHD and loads of other conditions.

Agree but if you don't push the boundaries things can't improve :wink:

Again agree hence why I'm happy to break things down when I have to to work within the system. But no harm is seeing what can be done and I think HE can do a lot more than people think, you just have to think about it abit more to do it.

Definitely agree :joy: I love HE but how the guys got to it, is a awesome undertaking. I could only dream of having that brain power :crazy_face:

Even during the middle of the day...daylight color indoors is just "not right" to my brain. I've lived on this earth for 38 years with soft white light indoors. My brain just can't handle a drastic change like that. I think it's because the colors look "wrong" because of what I'm used to. If I moved into a new house and had daylight white from the beginning, it would probably not be such a shock to my system.

1 Like