I’m trying to implement a couple of virtual switches: Bright and Dim. I want the switches to just set the level of bulbs (for example to 100 or 30) so the next time they’re turned on they will be at the set level.
The problem is that setting the bulb level also turns the bulb on.
Question: Is there a way to separate these actions?
My understanding is that this is a limitation of the actual devices, so the short answer is probably not. At least I have not identified an elegant solution.
In automations, you can set the level just before turning off the light. Honestly, I have had mixed results with that. Commands sent close together did not always execute in sequence at the device.
@Hatallica is right. It’s more the device implementation limitation. Thought about using variable to store the desired the level, and have rule to adjust the light to the desired level when turned on. But it will be turn on 100% first for a second and then dim to the desired level, so it is still far from ideal.
@James - you may have inadvertently described a workable solution to what I am trying to do
Whereas my automations typically have lights at dim levels, my wife expects full brightness when she taps the switch. Rather than solving it when the light turns off, maybe it is better for me to do it when the light turns on. I would just need to use a variable to track how the switch came to be activated.
Something like:
Trigger = light changes to on. If variable “setByRule” is false, then set level to 100.
Back to @Stan_Silverman’s use case (sorry for my detour). How do you want the light to be turned on? If it is by rules, then a variable might be the ticket (fade from zero to level over a short time).
In addition to insight, the two of you have given me several ideas to work on this rainy day! Hatallica’s idea about setting the level at turn off – maybe with a delay between commands? And James’s idea about using a variable?
I ended up using a variable as James suggested. I wasn’t bothered by the bulb(s) coming on bright and then dimming when the Bright/Dim switch was preset to Dim. The Bright/Dim switch controls any or all of four bulbs.
Hungry for rain? Come on up to the Pacific Northwest. Don’t rush; you won’t miss it. We’re headed into the rainy season so one day is as good as the next!
If the light turns on when you set the level, then why set it to turn on and adjust the level afterward? Why not just set the level and have that turn on the light?
Side note: I finally tried the variable scheme last night, with success.
Triggered automations (flows) are bookended by setting the variable true and false.
In a separate rule, when the switch is turned on and the variable is false, it knows that it was manually operated and sets the desired level for a manual switch press.
I have several automation rules that dim the lights before turning them off. This allows me to override the last setting and also add other actions. Manually turning on my patio light will now also activate several other lights - presuming that if you wanted to see outside, then you wanted to see it ALL.
The biggest obstacle for me, is taking a minute to recalibrate my brain. I thought that it would be tougher to convert logic over from webCoRE to SharpTools, but it really wasn’t.
In retrospect, I may need to create a unique variable for each location. There is a small risk (but real) risk in using one variable universally. So maybe something like:
$isAutomationPatio
$isAutomationKitchen
$isAutomationGarage
@James - I considered doing that earlier, but my seemingly simple patio example controls 7 devices and is spread across 5 rules:
Manual ON
Manual OFF
Motion detected or Door opens
No motion for 3 minutes
No motion for 5 minutes
I will try to convert some other (simpler) automations this weekend. Is there a best practice for capturing screenshots, so as to get the entire rule on one image?
It really depends, some screenshot software allows you to “scrolling capture” and take the whole rule in one screenshot, and it works well if the rule is not too long. Otherwise, you may just describe the rule in the following format.
Got it. Here is a description version of the first use case. I purposely used an example with a fade action, because I am still playing around to see if this can create an issue. My gut feel is that there is a race condition.
In device history, my fade looks like: level = 4, switch = on, level = 16, level = 20, etc.
I thought that I saw the light flash this morning, making me wonder if the variable was set to False before the switch was set to On. It may be good to add a 1 second delay after a fade action just to be safe.
Manual Trigger:
Dimmer switch changes to on
Manual Flow:
If $isAutomation is False
Then Dimmer setLevel to 99
Automation Trigger:
Motion changes to active
Automation Flow:
Set variable $isAutomation value to True
If (time is between 5:00AM and 6:15AM) AND (illuminance is less than 500)
Second use case is a bit more involved. I prefer that my outdoor lights dim after a period of inactivity and then turn off a bit later. This means that the variable has to be tracked and managed.
Motion Trigger:
(Motion changes to active) OR (Door contact changes to open)
Motion Flow:
If illuminance is less than or equal to $darkOut
Then
set variable $isAutomation to True
dimmer setLevel to 99
3 Minutes No Motion Trigger:
Motion stays inactive for 3 minutes
3 Minutes No Motion Flow:
If ($isAutomation is True) AND (Door contact is closed)
Then dimmer setLevel to 15
5 Minutes No Motion Trigger:
Motion stays inactive for 5 minutes
5 Minutes No Motion Flow:
Set variable $isAutomation to False
dimmer to execute command Off
Manual Patio ON Trigger:
dimmer switch changes to On
Manual Patio ON Flow:
If $isAutomation has stayed False for 2 seconds // one scheme that I tried to deal with the race condition described previously
Do you mean the race condition that another active motion triggers the 2nd rule within the 15 seconds fading period? You may want to add another IF condition to make sure there is only one rule instance running at a time. For example:
Automation Flow:
If (time is between 5:00AM and 6:15AM) AND (illuminance is less than 500) AND ($isAutomation is False)
Not exactly. Setting the switch to ON is an inherent part of Fade or setLevel. However, I am not certain of the timing or sequence. So, yes, I wonder if it can trip the second rule.
Does the rule stay on the fade action for the entire duration before executing the next step? In other words, does Fade execute like a delay for the remaining flow? Or, in my case, would the $isAutomation variable be set while the fade is executing?
Yes, the fade action needs to be completed before moving on to the next action. So in this case, the variable won’t be updated until the fade duration is over.