Unifi Temperature entities do not contain proper state_class

[Petro31]

The problem

NOTE: This does not appear to be an overarching issue, just 2 separate issues for Unifi and Derivative. There's already a separate derivative issue, so this is being repurposed into a Unifi only issue.

I have 3 entities that do not have a proper device_class or state class, yet the integration should be already providing it.

I think what's happening is, these entities existed prior to the integration having a state_class or device_class. Over time, the integration has been updated to provide this information but the entity_registry was never updated. And now, during the beta, we are getting repairs.

The listed integrations are Derivative and Unifi Network. The derivative integration's entity has a source sensor that is a % sensor. If I recall correctly, that means the ending UOM should be %, the state_class should be measurement, and the device_class should be none.

The other 2 entities are network switch temperature entities. Both are missing a device_class and state_class, however the integration provides this information. The entity_registry has the device_class as null and state_class is completely missing.

Here's one of the unifi sensors

      {"aliases":[],"area_id":null,"categories":{},"capabilities":null,"config_entry_id":"2600d55673de4f45aa72c80b4aa0031d","created_at":"1970-01-01T00:00:00+00:00","device_class":null,"device_id":"3419568b8da04da98a7e55b9cb5250ba","disabled_by":null,"entity_category":"diagnostic","entity_id":"sensor.bonus_room_switch_temperature","hidden_by":null,"icon":null,"id":"267196f14b2e70515fdfeb298be56494","has_entity_name":true,"labels":[],"modified_at":"1970-01-01T00:00:00+00:00","name":"Bonus Room Switch Temperature","options":{"conversation":{"should_expose":false},"sensor":{"display_precision":null}},"original_device_class":"temperature","original_icon":null,"original_name":"Temperature","platform":"unifi","supported_features":0,"translation_key":null,"unique_id":"device_temperature-b4:fb:e4:55:0c:42","previous_unique_id":null,"unit_of_measurement":"°F"},

derivative sensor

      {"aliases":[],"area_id":null,"categories":{},"capabilities":null,"config_entry_id":"f16a0f99e10c399583f08ce9a6940608","created_at":"1970-01-01T00:00:00+00:00","device_class":null,"device_id":null,"disabled_by":null,"entity_category":null,"entity_id":"sensor.master_bathroom_humidity_change","hidden_by":null,"icon":null,"id":"f9038f24987f802610c32443a8f2b5d3","has_entity_name":false,"labels":[],"modified_at":"1970-01-01T00:00:00+00:00","name":null,"options":{"conversation":{"should_expose":false}},"original_device_class":null,"original_icon":null,"original_name":"Master Bathroom Humidity Change","platform":"derivative","supported_features":0,"translation_key":"derivative","unique_id":"f16a0f99e10c399583f08ce9a6940608","previous_unique_id":null,"unit_of_measurement":null},

Both of these entity_registry items should contain a device_class and a state_class.

It should also be noted, at some point in my configuration history, these entities did have their friendly_name overridden by customize.yaml. I completely removed all customize.yaml settings when labels were introduced. State_class and device_class were not listed in customize.yaml. History for that file is here https://github.com/Petro31/home-assistant-config/commits/master/customize.yaml

What version of Home Assistant Core has the issue?

2024.10.0b0

What was the last working version of Home Assistant Core?

2024.9.3

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Unifi Network

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[hmmbob]

Possibly related: #117750

[Petro31]

Possibly related: #117750

Yes, I'm thinking that this is a very old issue that was brought to light with the repair changes this beta. I'll likely just alter my storage files, however it should be noted that this issue exists somewhere in the system.

My current configuration is roughly 6 years old without any wipe & restores or hardware changes

[emontnemery]

@Petro31 Can you share the state of the sensors which trigger have issues?

[Petro31]

@Petro31 Can you share the state of the sensors which trigger have issues?

[hmmbob]

For me it is all 4 HA Android app provided battery level sensors.

[Petro31]

I attempted to fix the entity_registry by adding {"state_class":"measurement"} to "capabilities", adding a proper "device_class" and ensuring the "unit_of_measurement" matched the device_class while HA was off. On startup, HA wiped out those settings. I.e. There is no fix the user can do.

[Petro31]

Some more info:

Both unifi entities stopped collecting long term stats April 6th 2024. They had been working for a long time before this date. This data was a Saturday for me, it's 3 days after the release. I'd start looking in 2024.4.0 or 2024.4.1 for any changes.

The derivative sensor has sporadic long timer statistics. I only have 3 data points total in LTS Feburary 24th 2023 @8pm, March 1st at 3pm and 4pm. So this entity has been broken for quite some time. That appears to coincide with the beta period for 2023.3.

Keep in mind, I wiped my database sometime around January 2023, so data prior to that point does not exist.

[saschaabraham]

Same here with the battery infos.

[PieterHattinghZA]

Also been getting it with mobile phone sensors

[home-assistant[bot]]

Hey there @kane610, mind taking a look at this issue as it has been labeled with an integration (unifi) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `unifi` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign unifi` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

unifi documentation unifi source _{^{(message by IssueLinks)}}

[Kane610]

@Petro31 Im not convinced that this is an issue from the integration, it would probably be more widespread if it was (old beta issue perhaps?). Also the temperature sensor implementation ever only had one definition and hasn't changed from its inception , meaning device class has always been specified, though it never had the state class defined

Looking at the provided entity registry entry there seems to have been a change in configuration of it "device_class":null "original_device_class":"temperature"

There seems to still be references to the other issue which doesn't help understanding what is what

[Petro31]

@Petro31 Im not convinced that this is an issue from the integration, it would probably be more widespread if it was (old beta issue perhaps?). Also the temperature sensor implementation ever only had one definition and hasn't changed from its inception , meaning device class has always been specified, though it never had the state class defined

Looking at the provided entity registry entry there seems to have been a change in configuration of it "device_class":null "original_device_class":"temperature"

There seems to still be references to the other issue which doesn't help understanding what is what

I attempted to fix the device_class and state_class in the entity_registry, however the integration wiped all that out on startup. So at this point, I'm not sure what's causing the problem, but it is a problem.

[Kane610]

I looked at one of my switches entity registry entries and it was more or less identical except for two things

your "name" was filled which I guess was from your customisation.yaml and "options" which was empty in my case but yours contains

"options": {
            "conversation": {"should_expose": false},
            "sensor": {"display_precision": null},
        }

What happens if you clear these?

Additionally I looked in the entity registry code

        device_class = self.device_class or self.original_device_class
        if device_class is not None:
            attrs[ATTR_DEVICE_CLASS] = device_class

                # Version 1.3 adds original_device_class
                for entity in data["entities"]:
                    # Move device_class to original_device_class
                    entity["original_device_class"] = entity["device_class"]
                    entity["device_class"] = None

                # Cleanup after frontend bug which incorrectly updated device_class
                # Fixed by frontend PR #13551
                for entity in data["entities"]:
                    domain = split_entity_id(entity["entity_id"])[0]
                    if domain in [Platform.BINARY_SENSOR, Platform.COVER]:
                        continue
                    entity["device_class"] = None

[Petro31]

I'm wondering if the issue is coming from customize.yaml being used in the past. I'll give these things a try, I wont have time to look into it until Friday

[Petro31]

@Kane610 when you said your options was empty, do you mean an empty dict or null? Also, looking at my entities in dev tools -> states page, I have a device class for both entities, just not a state_class.

[Kane610]

@Kane610 when you said your options was empty, do you mean an empty dict or null? Also, looking at my entities in dev tools -> states page, I have a device class for both entities, just not a state_class.

"options":{},