Two nasty surprises in Home Assistant's config

Join the discussion

• Hacker News
• Thanks for posting this. Seems I am not the only one who ran into this.
  by hexfish
• Wow, using the current timezone is not a planned feature.
  by wodenokoto
• The GitHub issue was "closed as not planned" due to stalebot auto-closing it, not because the maintainers actually said "we don't plan to do it".

  IMHO stalebots are an anti-feature in an issue tracker, and do more harm than good, but that's a different discussion.

  by rmunn
• I ve got the same automation but I had come to a problem that I always wake up when all shutters start to close automatically. So I stopped doing it automatically which kills a bit the idea
  by esel2k
• Why change the timezone using YAML instead of directly from the UI, if you used the UI for everything else? I'm not trying to victim-shame, it's still unacceptable that all the settings were lost.
  by laurentlbm
• I wanted to help so I took a look at the issue and the code. I was unable to reproduce the issue from your description.

  Firstly, issue #153175 refers to the "time of day" sensor, which is not what you're using - you're using the "time" trigger. The TOD code does a bunch of timezone acrobatics that can be fixed, but I don't think it'll affect your problem.

  Secondly, I built a tiny regression test on dev (on top of 333a3421) to reproduce your problem, and it didn't repro. I created a "trigger: time, at: 06:00:00, Europe/Paris", attached it before the DST transitions, and checked when it fires before, during, after the DST actual. The trigger fires perfectly on 06:00 walltime, and adjusts utc to match.

  Thirdly, the HASS UI has a small bug where it shows "Paris/+1" even if it's currently DST. It's a UI bug only, but it can lead to someone thinking that the entire HASS core doesn't respect DST.

  Silly tech support questions - are you on latest? Did you try playing around with {{now()}} in developer templates? Maybe open a new issue?

  by Backslasher