I use the Attributes of the “sun.sun” sensor to get the actual time in HH:MM:SS for Sunrise and Sunset. They were displaying fine on my dashboard before the 2023.5.0 and 2023.5.1 update. Now they display as “unknown” on the dashboard.
However, when I use the Developer Tools area and look at Sun.Sun, the Attributes still show the correct data that previously used to display. It’s just now, they show as Unknown.
Any idea why? I don’t see any breaking changes in the changeling for 2023.5.0 regarding attributes.
I do not want to use the “sensor.sun_next_rising”, as that returns a duration in hours until the next event, and not the actual event specified as a timestamp. (ie “in 18 hours” rather than “20:27:34”).
If you use the Entity card (instead of Entities) it will display the actual (not relative) time. If you must use the Entities card then you need to do what you are already doing (creating a Template Sensor that doesn’t have device_class defined).
Thank you for both options, from @Troon and @123 . The easiest option was to remove the “unit_of_measurement” lines from the YAML. Dates are now showing again.
I may be wrong but I get the impression that unit_of_meaurement is now handled more strictly than in previous versions. It used to be that it would just tack on whatever you wanted to the received value (whether it made sense or not) but now it’s more selective about should/shouldn’t be used.
In this particular case it seems a bit too picky because an empty string seems rather harmless. Anyway, good to know.
Yes, I’ve fielded a few of these recently. I can’t see anything obvious in the release notes and cba to search too deeply into git commits, but it seems like you’re right.
I believe you are correct on that, I saw the commits yesterday when I noticed devices reporting different, strange or now unknown values and all of them made some mention of Unit of Measurement.
Add this one to the list of “Silent But Deadly” changes (pun intended).
They’re the little changes that are described in the PRs that implement them (often as part of some greater purpose) but aren’t explicitly mentioned in the Release Notes as notable changes.
Two recent ones that I am aware of:
expand no longer reports a sorted list; the reported list is now a reversed version of the original.
The value of an attribute now has a size limit of 16K.
Both were part of important work to improve performance (i.e. the “greater purpose” I had mentioned) but, because they’re ‘stealthy’ changes, leave users scratching their heads wondering why their templates (employing expand) are behaving differently, etc.
And now we have unit_of_measurement as another SBD.
They really should list stuff like this under breaking changes as a “possible breaking change”, because it’s pretty frustrating seeing device sensors suddenly go away and become unavailable after just one update, particularly when those sensors were used in automations and dashboards.