(still not got chance to use this yet buttttt…)
If this is changing colour temp as well as brightness the way you are doing it would be better than a huge transition number.
My Ikea Tradfri bulbs never used to support this sort of change previously, and I used to have to break it up into several smaller transitions, which yours is doing (from what I can work out). 
I would also love to know if it is possible to add more than one lamp
I added a paragraph to the original post about using multiple lights.
Thanks for trying them out and finding that one of them would work. Because I honestly wasn’t sure. So, TIL. 
In my experience, transition: whatever works really well… when it works. There are lots of cases where it doesn’t though. For instance, the last I checked, Tasmota based Wifi Bulbs didn’t support this at all/well/out-of-the-box. I also had some ZWave dimmers that didn’t support this (for which I wrote a script very similar to yours to handle). So, I think being able to do both is nice.
The beautiful thing about Blueprints (and shared code in general) is that, over time, this blueprint will get better and better and more and more feature-ful. Just about anyone can manage to do the “hello world” of home automation: motion detected so turn on light. And just about everyone will quickly realize that, in most cases, this isn’t enough.
Blueprints like this, hopefully, will evolve to handle most of the gotcha type stuff that people actually want when they think “motion detected so turn on light” (but not when I’m away from home or when it’s light out. Also turn the light back off for me, but not right away. Also, if I turn the light on manually, then don’t turn it off for me. Also if I turn off this switch to disable all automations in my home, then don’t do anything to it. And also don’t turn them on when I’m sleeping.).
In this case of this “sunrise light” scenario, one improvement I can think of involves “transition”. With a very short sunrise time, you can visibly SEE the light change when broken in 5 second chunks. One simple solution is to use “transition: 5” so that, IF the light supports transition, a smoother effect is achieved. While still keeping the chunks short.
You could also do some math at the beginning to figure out how big the chunk of time needs to be to increase brightness by 1, then, use that as your repeat time so that, even without transition, the ramp up is as smooth as possible.
You could also give a boolean option for “transition” so that users can decide if they want to turn that feature on or not (the default should be to use it since, even bulbs that don’t support it, generally tolerate it being there anyway).
You could also allow the blueprint user to specify the time interval (defaulting to 5 seconds) since they may know better what their lights can tolerate.
I also think (though I’m not 100% sure, that using “brightness” (instead of brightness_pct) will allow you more granularity and more directly match how most lamps actually work, thus making the ramp up in each cycle a bit smoother.
1 Like
Yeah I’m fully with you and I think I will add the dynamic tick time with transition since it shouldn’t hurt. In principle it should just be delays between steps in seconds = sunrise duration in minutes * 0.6. At least I will try it locally with my alarm tomorrow morning and if it works well I will add it later to the blueprint. At this stage I would rather avoid adding too many new input variables since it is not possible to even define defaults right now so it is a bid tidious for the user. On brightness vs brightness_pct yeah I guess it depends on the granularity of the light how much that would change but I guess with transitions in between it should not be very necessary.
Agreed. With transitions in between, it won’t matter much at all. For lights that don’t support a transition, then you get 2.5x more “steps” out of it that way and, MOST lights use two bits (FF) to define brightness anyway so you’d be more closely aligned with that.
I’m surprised that blueprints don’t support “defaults”. I’m going to play with them a bit and see if I can find a nice way to handle it. Because, that’s just silly.
default values are configurable. Like so:
blueprint:
name: Test
description: Test
domain: automation
input:
test_input:
name: Test Input
description: Test Input
default: 120 # DEFINE A DEFAULT
selector:
number:
min: 0
max: 3600
unit_of_measurement: seconds
1 Like
its not, Shellies and Tasmota lights for example don’t support it
Shit I somehow missed the default thing in the documentation. Maybe it wasn’t there in the RC documentation. Thanks for pointer I will add reasonable defaults with the next update.
1 Like
The new algorithm seems to work quite well.
New version now has:
- Dynamic calculation of the loop interval based on how long one percent brightness step should be depending on the sunrise duration.
- Transitions set to said interval (where supported).
- Some preset defaults now for sunrise duration / maximum brightness.
Hi,
this is quite amazin, but sadly not working at all for me. Tried it this night for two hours, but its not gonna work for me.
I’ve followed strictly your configuration steps. I’ve tried it at first with the timer and was wondering where to set the time and date when it should enable the lights. Afterwards I used the companion app. Needed to enable that sensor on my phone first.
In fact I can see the timer in HA. I set the time to 5 minutes before the timer takes affect.
I can also see that it has been started. But the lights are not turned on.
I used this with a zha group including two Philipps Hue Iris lamps. Also I tried it with just one of the lamps. Either way it’s not working at all for me. I guess its somehow the Philipps lights, but not sure how to check that.
Some help would be much apppreciated.
Kind Regards
fastboot
Hmm that sounds weird indeed, I have noticed something with the next_alarm sensor at least on my Android. If I set an alarm to e.g. 7.00 the next_alarm sensor in HA shows actually 6.55 so exactly 5 minutes earlier. Which means that if I set a light alarm with 5 minute duration it runs from 6.50 to 6.55 instead of from 6.55 to 7.00. I’m not sure why it is the case with the next_alarm sensor and if that happens only to me. That aside do you see any errors in the logs e.g. related to templates?
Tested this myself this morning.
In one case, my light doesn’t support color_temp at all. In order to test, I just commented out the “color_temp” portions. However, to properly support lights without color temp, you’re going to need a few more choose statements, I think.
Also, for pre_sunrise_actions if you add default: [] it’ll make it so people don’t HAVE to choose a thing.
Also, as you learned, !input is not available in the template and, therefore, can’t be included in a template trigger. HOWEVER, variables are. So adding…
variables:
timestamp_sensor: !input timestamp_sensor
…to your blueprint will make “{{ timestamp_sensor }}” work in a template.
Sadly that doesn’t seem to work for templates in the trigger section (which was what I tried with in the first place actually). Result is an error in the log like:
homeassistant.exceptions.TemplateError: UndefinedError: 'timestamp_sensor' is undefined
I just remembered I have a non-color-temperature light in my attic. Used that to write down the necessary choose-blocks. Code has been updated. I also took the advice with the default: [] for the action-block. Seems to do just fine, thanks!
Well damn. I was SO sure that part of it (variables defined in a trigger template) that I didn’t even test it before suggesting it. Testing it now, it fails exactly as you’ve indicated. It’s likely an oversight and would be fixed with a bug report. But, I’m not sure.
I am getting this in my log, hopefully it will help track down the error @f4stb00t is seeing. I’m using it with a Tasmota RBGW LED strip:
Error while processing template: Template("{{ 0 < as_timestamp(states(timestamp_sensor)) - as_timestamp(states('sensor.date_time_iso')) < 60 * float(sunrise_duration) }}")
Error while processing template: {{ 0 < as_timestamp(states(timestamp_sensor)) - as_timestamp(states('sensor.date_time_iso')) < 60 * float(sunrise_duration) }}
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 353, in async_render
render_result = compiled.render(kwargs)
File "/usr/local/lib/python3.8/site-packages/jinja2/environment.py", line 1090, in render
self.environment.handle_exception()
File "/usr/local/lib/python3.8/site-packages/jinja2/environment.py", line 832, in handle_exception
reraise(*rewrite_traceback_stack(source=source))
File "/usr/local/lib/python3.8/site-packages/jinja2/_compat.py", line 28, in reraise
raise value.with_traceback(tb)
File "<template>", line 1, in top-level template code
TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 462, in async_render_to_info
render_info._result = self.async_render(variables, **kwargs)
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 355, in async_render
raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: unsupported operand type(s) for -: 'float' and 'NoneType'
Does the blueprint get automatically updated? Or do I need to do it manually?