Timestamp_Custom Options - Sunrise Alarm Clock

All,

So I successfully implemented a sunrise alarm using a Hue color bulb and some datetime input. I had a question though on this line of code that works. I see in some of the examples I have seen a False and a True as a field. I believe this custom timestamp is needed because sensor.time attribute timestamp shows seconds as well and this prunes the seconds off for a comparison to my input selection.

timestamp_custom('%H:%M', False)
timestamp_custom('%H:%M', True)

I just want to make sure I understand what parameters I am passing.

Full line of code I have that works

value_template: "{{ states('sensor.time') == (states.input_datetime.USER2_wakeup_time.attributes.timestamp | int | timestamp_custom('%H:%M', False)) }}"

Automation YAML - https://github.com/mcaminiti/homeassistant/blob/ed65e8c789b08cc8061dbb4e36642333e61aeff9/automation/wakeup.yaml

False is the only one that works for me here. Using true puts me an hour out. Supposedly true means to use local time and false uses universal (or something similar) but given that I’m in the UK false and true should both be the same.

There is a discussion on it somewhere, but the basic answer is that it should be true and nobody knows why false works better for a significant number of people.

Well False works for me as well. I guess I’ll see what happens once I hit daylight savings time removal if it changes anything but the number I am using is just an input datetime so it’s static set and not moving with a time zone.

Thanks for giving more background. The example on HA site didn’t work and I found a few forum posts with this alternative style and the False. I was going to do a PR to fix the site but since I didn’t know why it was that way I figured I’d ask.

I actually did the original example in the docs and it was false in that, but somebody recently changed it.

Ha! Maybe I’ll submit a PR to put it back. :wink:

1 Like