"Sun" attribute sensor shows as Unknown when it worked before

Configuration
1

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”).

2

Here is the code in my Config YAML that I haven’t changed or modified:

# Add Sunrise and Sunset as datapoints

   - platform: template
     sensors:
       nextsunrise:
         #entity_id: sun.sun
         friendly_name: 'Next Sunrise'
         icon_template: mdi:weather-sunset-up
         unit_of_measurement: ''
         value_template: >
           {{ as_timestamp(states.sun.sun.attributes.next_rising) | timestamp_custom('%H.%M.%S') }}
       nextsunset:
         #entity_id: sun.sun
         friendly_name: 'Next Sunset'
         icon_template: mdi:weather-sunset-down
         unit_of_measurement: ''
         value_template: >
           {{ as_timestamp(states.sun.sun.attributes.next_setting) | timestamp_custom('%H.%M.%S') }}

It used to show the timestamp on this card, but now shows as Unknown:

Screenshot 2023-05-05 at 11.54.59

3 
# Add Sunrise and Sunset as datapoints

   - platform: template
     sensors:
       nextsunrise:
         friendly_name: 'Next Sunrise'
         icon_template: mdi:weather-sunset-up
         unit_of_measurement: ''
         value_template: >
           {{ states('sensor.sun_next_rising') | as_timestamp | timestamp_custom('%H.%M.%S') }}
       nextsunset:
         friendly_name: 'Next Sunset'
         icon_template: mdi:weather-sunset-down
         unit_of_measurement: ''
         value_template: >
           {{ states('sensor.sun_next_setting') | as_timestamp | timestamp_custom('%H.%M.%S') }}

Screenshot of Template Editor confirming proper results:

Screenshot_20230505-075407~2
Screenshot_20230505-075407~21130×441 50.4 KB

For future reference, the Entities card will display relative time if the sensor’s device_class is timestamp.

Screenshot_20230505-075929~2
Screenshot_20230505-075929~21349×237 29.5 KB

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).

4

Remove both of those lines.

1 Like
5

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.

Screenshot 2023-05-05 at 13.29.30

6

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.

7

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.

8

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.

9

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.

2 Likes
10

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.