4 ms·

Two nasty surprises in Home Assistant's config

42 points by edward 3mo ago

wodenokoto 3mo ago
Wow, using the current timezone is not a planned feature.
- rmunn 3mo ago
  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.
  - subscribed 3mo ago
    After 3 months. Maintainers ignored the issue for 3 months until their own automation closed it. It wasn't a rogue github bot.
    - rmunn 3mo ago
      I've seen issues ignored for a lot longer than 3 months because maintainers didn't have time, then when they did have time they addressed the issue. Heck, Svelte recently did a PR fixing a bug report from about 4 years back. I'll see if I can dig it up. 3 months is not enough time, in my experience, to decide that the maintainers of an open-source project aren't interested in fixing an issue. EDIT: I'm not finding the issue that I'm thinking of very quickly. But it was a bug report from 2022 which they looked at at the time, said "yeah, this is an issue we'd like to fix but we don't have a good fix right now", and then the issue was silent. Later on, Svelte went through a major internal rewrite between Svelte 4 and Svelte 5. With Svelte 5's new internals, they were able to fix that 2022 issue. I noticed it because I had just recently read the Svelte changelog, idly clicked on some of the PRs, and noticed an issue with a very low number that was marked as fixed. But I'm not finding it now.
    - watwut 3mo ago
      Which is exactly issue with stalebot. 3 months of no movement on an issue is not and should not be a reason to close it. The issue is real and this ensures it wont get fixed. Issues waiting for far longer then 3 months before they are fixed is super normal of important but not a blocker category of bugs.
      - no-name-here 3mo ago
        Claude Code has an even shorter policy. https://github.com/anthropics/claude-code/issues/16497 https://github.com/anthropics/claude-code/issues/16497
hexfish 3mo ago
Thanks for posting this. Seems I am not the only one who ran into this.
esel2k 3mo ago
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
Backslasher 3mo ago
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?
laurentlbm 3mo ago
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.

42 points by edward 3mo ago

wodenokoto 3mo ago

Wow, using the current timezone is not a planned feature.

rmunn 3mo ago
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.
- subscribed 3mo ago
  After 3 months. Maintainers ignored the issue for 3 months until their own automation closed it. It wasn't a rogue github bot.
  - rmunn 3mo ago
    I've seen issues ignored for a lot longer than 3 months because maintainers didn't have time, then when they did have time they addressed the issue. Heck, Svelte recently did a PR fixing a bug report from about 4 years back. I'll see if I can dig it up. 3 months is not enough time, in my experience, to decide that the maintainers of an open-source project aren't interested in fixing an issue. EDIT: I'm not finding the issue that I'm thinking of very quickly. But it was a bug report from 2022 which they looked at at the time, said "yeah, this is an issue we'd like to fix but we don't have a good fix right now", and then the issue was silent. Later on, Svelte went through a major internal rewrite between Svelte 4 and Svelte 5. With Svelte 5's new internals, they were able to fix that 2022 issue. I noticed it because I had just recently read the Svelte changelog, idly clicked on some of the PRs, and noticed an issue with a very low number that was marked as fixed. But I'm not finding it now.
  - watwut 3mo ago
    Which is exactly issue with stalebot. 3 months of no movement on an issue is not and should not be a reason to close it. The issue is real and this ensures it wont get fixed. Issues waiting for far longer then 3 months before they are fixed is super normal of important but not a blocker category of bugs.
    - no-name-here 3mo ago
      Claude Code has an even shorter policy. https://github.com/anthropics/claude-code/issues/16497 https://github.com/anthropics/claude-code/issues/16497

hexfish 3mo ago

Thanks for posting this. Seems I am not the only one who ran into this.

esel2k 3mo ago

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

Backslasher 3mo ago

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?

laurentlbm 3mo ago

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.