Sensor.time problem

Hi there,

I’ve got a problem with sensor.time. It was working for a while and automations based on time worked without any issues. Then I updated HA (docker) to newest version, and now sensor.time stucked at 15:54. It just doesn’t update time. Any ideas how to fix it?

Ok, found a way to fix it. I’ve commented out time_date integration, and all automations based on those sensors. Then restarted HA. After that restored integrations and automations and restarted HA again.
Everything seems fine now.
But the feeling that time and date is not stable stays with me …

I just had the same thing happen.

sensor.time stuck at 09:37.

I commented out time_date platform from my sensors, restarted and then put it back in, restarted again and my sensor.time is now working as per normal.

Very odd indeed.

Was it after HA update?

It was after upgrade from 0.112.x to 0.113.2. I upgraded on Wednesday morning. All my automations based on sensor.time continued to work for a period of time after the upgrade though - at least 30 hours.

Just got onto something I think!

I noticed that the time was stuck again at 10:21. I went back through my Home Assistant log and noticed the following:-

2020-08-03 10:21:01 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback HomeAssistant.async_run_job(<bound method... Time: 10:21>>, datetime.date... tzinfo=<UTC>))
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/src/homeassistant/homeassistant/core.py", line 381, in async_run_job
    target(*args)
  File "/usr/src/homeassistant/homeassistant/components/time_date/sensor.py", line 139, in point_in_time_listener
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 286, in async_write_ha_state
    raise NoEntitySpecifiedError(
homeassistant.exceptions.NoEntitySpecifiedError: No entity id specified for entity Time

A restart of Home Assistant seems to have fixed the issue, and time is ticking over again.

Still investigating, but wanted to let you know what I found.

I just looked and there doesn’t appear to be any issue open concerning this problem. Is there a reason nobody opened an issue?

Based on your traceback I just took a look at the code. There does appear to be a bug that might have been made more likely to manifest itself given all the work that was recently done to make startup faster. Specifically, it’s registering a call back to update itself before the entity has been completely initialized, which could explain why the entity_id attribute is None, leading to this exception. But I would think that would prevent sensor.time from working at all.

Is there anything in home-assistant.log preceding that error that might provide a clue as to why it’s happening when it does? Was sensor.time removed & re-added? Something reloaded?

I will log an issue in Github now. Nothing preceding the issue. I restarted and that is one of the first thing in the log.

Thanks!

So I got the impression from what you had written that sensor.time always works immediately after restart, but sometime later it freezes. Are you saying that when it doesn’t work, it’s always immediately after a restart, and if it works then it continues to work at least until the next restart? If so then please make sure to make that clear in the issue.

And that would match my expectation:

I guess that was unclear. :stuck_out_tongue_winking_eye: What I meant was, I would think that if that exception happens at startup that the sensor would not work at all until HA is restarted. So there’s a chance it works after some restarts but not after others. Anyway…

And if it is true, then I think I already know how to fix this.

The two times it has happened to me, it is immediately after a restart. I will make that clear when logging the issue.

1 Like

I see @pnbruckner you have already assigned it to yourself.

Thanks for your assistance.

… and fixed it:

:smiley:

That was quick! Hoping this makes it into 0.113.4.

Thanks again for your help. Awesome stuff, @pnbruckner