Try using Delayed Off, Cancellable instead of Delayed Off.
1 Like
I had the same issue recently and was wondering how I could remove a rule without starting over. Thanks!
Am I remembering incorrectly, but wasn’t “power allowance” an option in rule machine?
I want a rule where if the door opens, the lights come on. When the door closes, the lights go off after 3 minutes, but if the door stays open then the lights will shut off after 5 minutes.
Power allowance would allow this to occur in one rule. I’m using two rules to make it work right now, and it works great.
One rule: condition door open; true action: light on, light off after 5; false action: light off after 3
2 Likes
Yep, I knew it was user error! Thanks!
you can delete rules in IDE
Thank you so much! This is awesome! I dont totally understand all the options yet, but I was able to do something that I have wanted to do for a while. That thing is turn on a light for 5 minutes when a presence sensor or mobile presence arrives home. Works perfect!
@bravenel I obtained this information from http://www.developers.meethue.com/documentation/getting-started and then did some testing.
This relates to HUE I have no idea if this is the same for other bulb types.
Using the Hue CLIP API Debugger I was able to determine the following:
Hue recognizes TRUE (ON) and FALSE (OFF).
The ‘bri’ setting (brightnes) can have a range from 0 - 255.
0 is displayed as 0, 255 is displayed as 254.
‘bri’ level 0 is the minimum brightness the bulb can have. (bri 0 and bri 1 appear to be the same level)
bri 0 is not interpreted as FALSE (OFF)
You can set a new bulb color when turning the bulb off without specifying a bri value. The next time the light comes on it will display the newly assigned color.
From the limited testing I have done I don’t see any harm in translating bri 0 to FALSE (OFF) or not passing that value at all.
Below is a grab of one of my bulbs settings
State: ON
Brightness: 0 (Bulb is still illuminated)
{“state”: {“on”:true,“bri”:0,“hue”:10000,“sat”:1,“effect”:“none”,“xy”:[0.3811,0.3769],“ct”:251,“alert”:“none”,“colormode”:“hs”,“reachable”:true}, “type”: “Extended color light”, “name”: “Cabinet Light Hue”, “modelid”: “LCT003”, “manufacturername”: “Philips”,“uniqueid”:“00:17:88:01:00:e8:6f:8d-0b”, “swversion”: “66013105”, “pointsymbol”: { “1”:“none”, “2”:“none”, “3”:“none”, “4”:“none”, “5”:“none”, “6”:“none”, “7”:“none”, “8”:“none” }}
Excerpt from http://www.developers.meethue.com/things-you-need-know
Transition time
When you set the light state, and update color, brightness etc., the light will not respond immediately because by default
there is a transition time to the new state of 400 milliseconds. If you
want the light to respond quickly to a state change, set the transition
time in the light state to zero milliseconds. Read more
Number of commands you can send per second
You can send commands to the lights too fast. If you stay roughly around 10 commands per second to the /lights resource as maximum you should be fine. For /groups commands you should keep to a maximum of 1 per second.
Conflicting parameters
If you try and control multiple conflicting parameters at once e.g. {“ct”:250,“xy”:[0.5,0.5]} the lights can only physically do one, for this the following simple rule applies: xy beats ct beats hue, sat.
I’m not sure if this is useful to you. Just thought I would post what I found. If there are any specific tests you would like me to do let me know.
Just a note, I’m running 1.2.1 now and still can’t enter a decimal place. Thoughts?
Is that for temperature as a condition, or to set a thermostat? I did decimal for the former, not the latter. Do you need to the latter?
I just made a very small change to the published app for you to check out. Two small changes: it allows lightlevel for a color bulb to range 0…255 instead of 0…100; if lightlevel is 0, it does setColor() and then turns the bulb off. That may not be right either, if the bulb does something weird with lightlevel = 0 from the call to setColor(). If that’s the case, I could catch the lightlevel = 0 sooner so that it never gets sent to the bulb at all.
Please test this modified version for me! V 1.2.1a. Please test lightlevel > 100 and lightlevel = 0. Thanks!
Yes it was for the latter so I could set the furnace to 17.5
1 Like
Would it be possible to add “pending dim”? So same thing as pending off/on but set the dim level. I want to increase the brightness of some lights depending on how long there’s been activity in the room.
Let me know if I’m overlooking another way to do this.
What about a second rule that conditions on motion, but delays its effect? You can delay a rule taking action.
I just put that in, check out 1.2.1b on Github. I tested it on my Zen, and it seems to work! Nice catch.
So now you have both, temp as condition and thermostat setting.
That works. When changing to FALSE the bulb changes to the new color for a few milliseconds at 100% and then shuts off. When the bulb is turned back on, from a different routine, it is set to the new color at 100%. I will continue to test different scenarios.
Values between 0 - 255 work as expected. values above 255 generate a validation error.
0 = OFF
255 = brightest setting
This is very much appreciated. Many thanks.
So I was hoping to set something like this up:
Rule1: If sustained motion for 5 min then set brightness to 50%
Rule2: If sustained motion for 15 min then set brightness to 100%
If I use the “delay the effect of this rule…” option won’t it just set the lights to 50% 5 min after the initial motion then 100% after 15 min regardless of the current state of motion? I’m trying to avoid raising the brightness if the room has become unoccupied at any point.
Actually, I’m pretty sure that it will do what you want. An intervening rule state change cancels the delay timer. So delay rule acts like pending off in that regard.
That doesn’t sound like what you want. I think I can get rid of that 100% flash.
[quote=“bravenel, post:611, topic:28730”]
That doesn’t sound like what you want. I think I can get rid of that 100% flash.
[/quote].
I’m okay with the flash. If you have an idea to get rid of it that would be nice. I kind of liked the fact that I could tell what color the light was going to be on next use. The brightness jump to 100% when if changes color before going off may be bothersome to some people