TOD incorrect after midnight restart #67039
Comments
|
tod documentation |
|
I am having the exact same problem, also with a daily reset at 2 am. Once the system comes back online TOD changes the sensor to Off using the Night sensor example found in the documentation. binary_sensor:
- platform: tod
name: Night
after: sunset
before: sunriseAs you can see in the sensor history, it turns off just after 2 am which is when HA restarts.
I am currently on Home Assistant OS 7.5 with core-2022.3.7 and supervisor-2022.03.5 |
|
Hi, I also have the same problem. The HA restart was caused by a power outage at around 1h42. Normally, the tod sensor should have stayed on till around 4h48. |
|
All tod sensors going to off after core restart.
|
|
I had similar issues last night/today after some restarts beyond midnight. |
|
I hit this again last night. After a restart of HA at around midnight, my sensor returned to It's fairly impactful, as I have a good few of my lights automations working off TOD conditions, and seemingly have no way to manually fix the values on these sensors, since they're defined in yaml. I can see older, closed, but related issues at #50315 and #24577 |
|
Does anyone have a workaround or alternative integration that follows the sun? |
|
|
I had an unexpected restart at 00:38 AM in the morning. All my tod sensors lost their state. Here's a picture of a tod sensor controlling my blinds. |
|
@DmytroKorniienko thanks for sharing! What I tried: Side note, is this a complex bug for HA to solve properly, or is it just low priority/forgotten? Maybe someone knows who to reach out to for a fix? |
|
The problem is still present with version 2022.12.8. My home assistant instance suffers from regular unplanned restarts during the night, the cause of which I haven't found yet. This would not really be an issue if it weren't for all my time of day sensors having a wrong state after the restart. Is there really no fix for this? |
after_offset requires more complex logic and I'm not implemented it for my automations, but can share one more example: |
|
Issue is still present on Home Assistant 2023.1.2. I had an unforeseen restart in the middle of the night and all my sunbased tod-sensors simply turned off. I included a pic of the tod-sensor handling my covers. All my covers stayed closed this morning instead of reacting to sunrise.
|
|
@frenck sorry for the direct |
@ahaverty There is no code owner for this integration, so that is correct.
Home Assistant is an open source project and relies on contributions. Feel free to jump in an contribute a fix. ../Frenck |
|
Thanks @frenck 👍 For anyone else trying to fix this: As far as I understood, my test case here should fail after the HA restart, based on what I've experienced with my actual HA instance restarting just after midnight: ahaverty@ecb5353 I did see there was a recent cleanup of TOD in #79412, so I tested against an older version of HA (an Oct 2022 release) just in case that PR has already fixed this issue and we haven't noticed since, but I still couldn't get my test to fail on an older Oct release. My theory on when the issue occurs (and what I was trying to fail in unit tests):
My theories on why I can't get the test to fail:
EDIT: No, I have an obvious issue with a couple of things with my test case above. It looks like the suite is setup for sunsets happening before midnight for some reason. EDIT 2: yes, there's something odd going on with this test suite if I'm reading this correctly. The timezone is set to the US, but the lat/lng is in Poland. So the sunrise/sunsets aren't going to be realistic at all 🤔 EDIT 3: I'm still unable to reproduce this in unit tests unfortunately. As far as I can tell, I'm calling the correct restart methods. I've also fixed the suite's lat/lng to match the US Pacific timezone, so that sunrise/sunset happen on different days (as typically expected for most of the world). EDIT 4: Nope, I've gone back to an Oct '22 release again with my latest test fixes, and can't reproduce the issue in unit tests.
I'm stumped.. My TOD config for reference: config = {
"binary_sensor": [
{
"platform": "tod",
"name": "Night",
"after": "sunset",
"before": "sunrise",
},
{
"platform": "tod",
"name": "Day",
"after": "sunrise",
"before": "sunset",
},
{
"platform": "tod",
"name": "Evening",
"after": "sunset",
"after_offset": "-00:30",
"before": "00:30",
},
{
"platform": "tod",
"name": "Outdoor Evening",
"after": "sunset",
"before": "23:30",
},
{
"platform": "tod",
"name": "Day",
"after": "sunrise",
"before": "sunset",
},
{
"platform": "tod",
"name": "Early Morning",
"after": "sunrise",
"before": "sunrise",
"before_offset": "02:00"
}
]
} |
|
Hi @ahaverty, Thank you for going through so much trouble to help get this fixed. It is odd that the problem doesn't occur during unit tests. I have currently three sun-based tod-sensors, which fail reliably after a midnight restart (last one was at 00:38). Maybe you could try with that config? Time Zone: Elevation: Country: Coordinates: |
|
Thanks @DarkWarden85, we practically have the same tod sensor there, which I've covered already in testing. I'm also having the restart issue myself in production consistently, so I don't think it's my config that's the problem for this test 🤔 Thanks though! |
|
Although @DarkWarden85 just re-reading back through people's comments here. I'm assuming based on languages a bit, but the majority of us seem to be located around Europe. I have found it odd that this issue isn't more popular/fixed, maybe it is something unusual like:
Maybe if anyone here is based in the US, and also has this post-midnight issue, they could comment to let us know👍 |
|
Looking at your unit-tests everything seems to be in-line with the other unit-tests. Maybe there is something odd with the force stop and restart where it initializes itself with a different time when restarting. Maybe you should set the time again after the restart. This is just a wild guess and I'm not that great at programming in the first place
Edit: Stupid suggestion from me with setting the time again after a restart. This should have no effect because the init during restart is what causes the problem. But still... is it using the correct testing time after the restart?
|
|
@ahaverty FWIW I experience this issue in Australia too - reliably reproducible with an after-midnight HA reboot. Another data point towards it potentially being something to do with non-US timezones - or perhaps non-US locales/languages? Random thought, but possible it's got something to do with the environment HA is running in too? I'm using Home Assistant Operating System running as an ESXi virtual machine (think I downloaded an OVF from somewhere and used that, but so long ago I don't remember properly). |
|
@wafliron to add to this, I'm running Home Assistant OS on a raspberry pi 4 while also experiencing the issue. |
|
I may as well add to the list too in case anyone else beats me to fixing:
|
|
I tried the unit tests with my timezone and lat/lng in Ireland, but unfortunately couldn't get the restart to fail the test. |
|
Hmm, I have a (possibly messy) workaround idea that might be worth spitballing with ye (while we wait for a saviour to fix the issue). Since this seems to only affect sun-based TOD's that end one day later than the start (right?) I wonder if I split them into two parts, for a night TOD for example: And then created a group for these two called "Night" via a group UI in helper settings. Edit: Hmm, it'll probably cause havoc for that 1 second gap around midnight, for anyone with automations listening to state changes for light automations etc. |
|
I have more information listed in the 3rd comment on this but I will include my config again here. I'm US-based with a US timezone currently running on a raspberry pi 4 and do indeed have this issue, so I don't think being non-US is a cause. I had this issue on a pi 3 as well. binary_sensor:
- platform: tod
name: Night
after: sunset
before: sunrise |
|
I just wanted to confirm that the bug is still present in the newest version 2023.2.0, so no need for @ahaverty to downgrade your testing version. Here's the result from a scheduled restart at 00h30 AM on the prior version 2023.1.7:
The same happens with a scheduled restart at 00h30 AM on version 2023.2.0 :
In both instances, the sensor was only turned on until 00h30 AM in the morning and it turned off after the restart |
As this integration has been “broken” for over a year, and apparently with no code owner to remedy, why does it even remain part of the core? Seems like the integration should either function, or progress to functioning, or just not exist at all… |
|
Very untested, but I think I've come up with a decent workaround for the likes of a "night" sensor that relies on sunrise and sunset: binary_sensor:
- platform: tod
name: left_night
after: sunset
before: "23:59"
- platform: tod
name: right_night
after: "00:00"
before: sunrise
before_offset: "-00:02"
template:
- binary_sensor:
- name: "Night"
unique_id: night
delay_off:
minutes: 2
state: >
{{ (is_state('binary_sensor.left_night', 'on') or is_state('binary_sensor.right_night', 'on')) }}i.e: The left_night and right_night I don't intend to use anywhere other than in the template's state for binary_sensor.night above. I've tested restarting just after midnight, and see And the Edit July 2024: I've been using this without any issues since 2023 in case anyone is wondering if they should use it 👍 |
|
@zzachattack2 I agree that the non-functioning part of tod should be removed, but how to do that with no code maintainer for it? Also, there is the problem that tod might break completely in the future if there are any changes to core functionality it relies on. @ahaverty |
|
@ahaverty I tried your workaround this night. It also works on my HA instance :D. I made a restart at 00:30 in the morning. You can see that the workaround sensor stays on after the restart and the original one doesn't. However I did a slight modification to your approach. I did not specify a delay_off of 2 minutes in the template sensor. Instead I have the right tod sensor trigger at 00:00 with an offset of -00:02:00. I think that makes it a bit easier. Here's my config: PS: I named my sensors wrong and confounded left with right, but it still works, lol. |
|
I have the same situation with several night sensors created with TOD. I am based in Spain. HA version 2023.3.6 running on Yellow. My workaround has been to create a complementary day sensor in my binary_sensor section and calculate the corresponding night sensor as a template binary_sensor |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
This issue still persists. Please do not autoclose. |
|
Hi, This is my binary_sensor code: |
|
I conducted some tests, and confirm the issue arises when the binary sensor's state was set to 'on' the previous day. Performing a restart on the same day does not alter the state, but doing so the following day resets it to its default state, 'off'. My solution was to define a Day sensor instead Night sensor: |
|
@amzaldua I can confirm that defining a tod sensor whose ON-state doesn't span from one day to the next doesn't have any issues. Thanks for finding this workaround. |
|
Upon restart the tod platform has no memory of when the previous update (should have) happened, it only looks forward. As a workaround I have written this template which resolves true when time is between sunset and sunrise. The idea is to use it as an automation condition when home assistant starts, then update the sensor programmatically: sensor - platform: tod
name: Sunset-to-sunrise
after: sunset
after_offset: "00:00:00" #starting time for "On" state
before: sunrise
before_offset: "00:00:00" #finish time for "On" state
template {# check if time right now is between sunset and sunrise #}
{% set timenow=now() %}
{% set sensor_name = 'binary_sensor.sunset_to_sunrise' %}
{% set nextupdate = state_attr(sensor_name, 'next_update') %}
{% set before_ = state_attr(sensor_name, 'before') %}
{% set after_ = state_attr(sensor_name, 'after') %}
{{ nextupdate==before_ and timenow.timestamp()<as_timestamp(nextupdate) }} |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
This bug is still present, so there is no reason to close it. |
|
Same issue for me |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
The bug is still there. |
Short answer: I am located in Canada (Pacific Standard Time) and I just discovered this issue so yes, it's a problem in North America also! I recently returned to using TOD instead on my battery powered Zigbee luminance sensors for outside light levels as they would not re-report their luminosity of 0 after they had reported it at dusk to a dead system. This discovery occurred when a power failure before sunset restored their last known value of >1000 when it restarted. It remained at the last know value until after sunrise when the sensors started reporting changes in luminosity. Since HA did not know any better, the nighttime sensor based on luminosity remained off so HA opened my blinds at night time. I then switched to the TOD sensor (nighttime) but then discovered this issue since I often work late on my HA system developing (well past midnight) and decided to investigate why my blinds were opening after restart in the wee hours of the night. The TOD sensor for 'nighttime' showed off, and now I know why! |
|
I've changed to this template for |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
issue-triage-workflows
bot
closed this as not planned
The problem
binary sensor TOD set to off when should be on after 2am restart
What version of Home Assistant Core has the issue?
2022.2.0
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Supervised
Integration causing the issue
TOD
Link to integration documentation on our website
here
Diagnostics information
No response
Example YAML snippet
Anything in the logs that might be useful for us?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: