pnbruckner / ha-sun2

Home Assistant Sun2 Sensor

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Period-of-time sensors improperly displayed starting w/ HA 2024.2

asjmcguire opened this issue · comments

Updated to 2024.2.0 (and 2024.2.1) and instead of showing a h:m:s time when you add the sensor to an entities card or even when you view it in the more info view, it's still showing the decimal time with " h" at the end. It did not do this prior to 2024.2.0

I checked other sensors I have that do still show decimal time as h:m:s and identified that the main difference between them and the sensor from the sun2 component is that they have a state_class: measurement attribute.

image

I'm not sure why you're seeing it this way. I've got a test system running 2024.2.1 and when I add a daylight sensor to an Entities card, it shows the expected H:M:S:

image

And so does the "more info" window:

image

And here's the state:

image

Even though I can't explain why you are experiencing this, I can still add the state_class. There was a bug before 2023.3.0 that wouldn't allow a state class to be assigned to sensors whose device class was duration, but that was fixed, and this integration no longer supports any HA versions before 2023.4.0 anyway.

I don't understand it either, here is the actual sensors from within the Sun2 component in the Devices and Services page:

image

According to HACS I am running v3.1.0 of the Sun2 component.

and this is the information from Home Assistant about page:

Core - 2024.2.1
Supervisor - 2024.01.1
Operating System - 11.5
Frontend - 20240207.1

Interestingly, it just started happening for me, too. Very strange!

I tried adding the state class in the developer tools just to test, but it didn't make any difference. I didn't try using the customize method in yaml though.

I added state_class to the code, and just like you found, it didn't help. It's still showing as a float instead of a time. Maybe it's a frontend bug in 2024.2???

I went back to 2024.1.6 and it shows correctly as a time. Definitely seems like something (again, probably in the frontend) changed in 2024.2.

I found this: home-assistant/frontend#19396

I don't know if that's the only piece of it, but it seems since I originally added a suggested display precision, that is now disabling the feature that displays sensors with a duration device_class as HH:MM:SS. Even using the default precision isn't enough. And just adding a measurement state_class doesn't help. (I don't actually think it has anything to do with this issue.) Even removing the suggested display precision from the code doesn't help, because that's already in the entity registry, and removing it from the code doesn't remove it from the registry. I think I have to add code to forcibly remove it from the registry for these entities.

I'll hopefully have a fix before long.

Looks like there is a bug in the sensor component.

I changed the sun2 integration so that it no longer provides a suggested_display_precision for these DURATION sensors (basically, daylight & night, and their variants.) That should cause the corresponding entry in the entity registry to be removed, which should cause the state to be displayed as HH:MM:SS again, but it's not.

The bug in the sensor component is preventing it from updating the entity registry accordingly. Here's where the bug is:

https://github.com/home-assistant/core/blob/3529eb6044678655912a07d58734d0e59b40b1f6/homeassistant/components/sensor/__init__.py#L796

That should be testing if "suggested_display_precision" is in self.registry_entry.options[DOMAIN], but it's not. So, it's returning instead of updating the entry. I'll have to create an issue and submit a bug fix. In the meantime, I'll change the sun2 integration to update the entry itself and not count on this buggy code.

Fixing the code in homeassistant/components/sensor/__init__.py solves the problem. I'll go ahead and submit the fix. But, like I said, in the meantime, I'll add code to the sun2 integration to make sure the entity registry is updated. Who knows if my fix will be accepted, and even if so, when it will hit a release.

Thank you. Fingers crossed that they do accept the fix.