The problem with that setup, is that both warm and white can be on simultaneously (turning on one after the other) which doesn’t make a lot of sense for the user.
Hm, so I guess the issue then is that you call the service without an entity_id once the other light is already off.
I’ve come across something similar and just created a virtual template light that doesn’t do anything other than being an entity_id you can manipulate.
A cleaner approach would be to call a script for the turn_off service and pass the target as a parameter.
The script would contain a “Chooser” action that would turn off the actual light, depending on whether or not the other virtual light is turned on or not.
As someone on FB mentioned, sounds like you’re wanting to do something like an interlock. If you haven’t already, lots of search results here on this forum on that.
I have similar setup for net radios. To achieve it I’ve created two template switches. So you don’t turn off the other one - it just updates the state based on the state of the devices you are controlling (in my case the played radio station, in your case a state of your light.bedroom). Below is my example. You should replace the value_template with logic relevant to the warm/cool light for your device and the turn_on, turn_off - I think is already ok in your code.
If I understood you correctly, that’s how it’s working right now. For example:
I click “bedroom white light” —> The light goes on white) —> I click “bedroom warm light” —> The light turns to yellow. That’s correct, the state updates, the problem is that “bedroom white light” will still be on. and worse, if you click again “bedroom warm light”, the light will go off, but “bedroom white light” will still be on in the UI. That’s the problem.
Well not exactly. That is why you need the value_template in your template switches so it recognizes when the color of your light has changed and turns off accordingly.