Mobile App using invalid unit of measurement for Battery entity

[ismarslomic]

The problem

After upgrading HA to v2023.1.0 I startet to receive following log warnings:

Entity sensor.ismars_iphone_battery_state (<class 'homeassistant.components.mobile_app.sensor.MobileAppSensor'>) is using native unit of measurement 'None' which is not a valid unit for the device class ('battery') it is using; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+mobile_app%22

I have not manually configured this entity, so I guess this needs to be fixed in core.

What version of Home Assistant Core has the issue?

2023.1.1

What was the last working version of Home Assistant Core?

2022.12.6

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Mobile App

Link to integration documentation on our website

https://www.home-assistant.io/integrations/mobile_app/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Entity sensor.ismars_iphone_battery_state (<class 'homeassistant.components.mobile_app.sensor.MobileAppSensor'>) is using native unit of measurement 'None' which is not a valid unit for the device class ('battery') it is using; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+mobile_app%22

Additional information

No response

[home-assistant[bot]]

Hey there @home-assistant/core, mind taking a look at this issue as it has been labeled with an integration (mobile_app) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of mobile_app can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Change the title of the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign mobile_app Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

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

[frenck]

Hi @ismarslomic 👋

Is this entity provided by the official Home Assistant iOS app? Or is it Android or another app?

../Frenck

[ismarslomic]

Its provided by the official Home Assistant iOS app.

[frenck]

Alright! Thanks for the quick response 👍 I'll be moving this issue to the iOS issue tracker in that case, as these sensors are provided/injected into Home Assistant by the app itself. We can't fix it from the Core end.

../Frenck

[zacwest]

Unfortunately the device class cannot be removed after a sensor is created, and the battery state sensor is no longer created with the battery class. You could resole this by deleting the mobile_app integration and allowing the app to recreate it, I think.

[cdnninja]

Maybe this is something that could be covered as a migration check? Much like this? https://github.com/home-assistant/core/blob/cf3ca816a87e5eca0c55e4143cb62811da975594/homeassistant/components/mobile_app/sensor.py?rgh-link-date=2023-01-07T00%3A00%3A30Z#L86-L95

[Petro31]

@zacwest what's it being created with now? I'll just edit the config entry, but it seems odd that this is not handled automatically by HA core. I'd consider this a bug (in core) seeing that the user can't do anything about it without nuking their configuration.

[zacwest]

It has no device class set since https://github.com/home-assistant/iOS/pull/1372

[TheDK]

@zacwest what's it being created with now? I'll just edit the config entry, but it seems odd that this is not handled automatically by HA core. I'd consider this a bug (in core) seeing that the user can't do anything about it without nuking their configuration.

How can one edit the Config entry without doing the setup once again?

[ScottG489]

Not sure if it's related since I don't see "level" mentioned here anywhere, but I have a battery_level sensor which doesn't have a device_class attribute. Only icon and friendly_name. What's odd is that on the phone itself in the sensor settings I can see that it's showing it should have a device class of battery. Thoughts?

[ismarslomic]

I can confirm that deleting the Mobile App integration in HA and recreating it by opening the HA mobile app for iPhone recreated all entities and that this warning disappeared. However, I agree with @Petro31 that this is rather a bug then a feature, and this migration should potentially be handled in the background by the core.

[alcmaeo]

@zacwest what's it being created with now? I'll just edit the config entry, but it seems odd that this is not handled automatically by HA core. I'd consider this a bug (in core) seeing that the user can't do anything about it without nuking their configuration.

How can one edit the Config entry without doing the setup once again?

Hi, i edited the core.entity_registry file manually and set the line "original_device_class": "battery", to "original_device_class": null, on my both iPhone Devices Entries. Starting Homeassistant after that the log is clean again. So maybe you can also avoid the re-adding of the Mobile App.

[teskanoo]

I'll just edit the config entry, but it seems odd that this is not handled automatically by HA core. I'd consider this a bug (in core) seeing that the user can't do anything about it without nuking their configuration.

I have to concur - I'm kind of a "he who broke it fixes it"

Would it be possible to have config entries for device class be provided by core (for core's integrations) rather than requiring 1. an override in customization.yaml 2. edit the core.entity_registry 3. or worse requiring a user to "turn-it-off-and-turn-it-on-again"

[kernelpanic85]

I just hit this as well upgrading from 2023.4 to 2023.5 and was big as I have multiple automations trigger on the battery state. Removing the mobile_app integration for the phone and re-adding by launching the app on the phone also fixed it for me.

I do agree with the sentiment here that something should probably be done to fix this correctly. It's probably not reasonable to expect everyone that uses mobile_app to apply this workaround. 😉

[ScottG489]

Ok so I removed the integration and re-added it. Then opened the app on the iPhone and all the sensors came back, but the error is still there.

Looking at the entity, it has device_class: battery, but no unit_of_measurement. Looking in the config entry (core.entity_registry file) for the battery_level entity I can see the following:

• original_device_class is battery
• device_class is null
• unit_of_measurement is %

What confuses me about this is why the unit_of_measurement is reporting here as % but the error seems to indicate it's None.

Here's the error from my logs:

Entity sensor.iphone_battery_level (<class 'homeassistant.components.mobile_app.sensor.MobileAppSensor'>) is using native unit of measurement 'None' which is not a valid unit for the device class ('battery') it is using; expected one of ['%']; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+mobile_app%22

So what's going on here? Why does the entity registry have unit_of_measurement set to %, but that attribute isn't being set on the entity?

[depuits]

I'll just edit the config entry, but it seems odd that this is not handled automatically by HA core. I'd consider this a bug (in core) seeing that the user can't do anything about it without nuking their configuration.

I have to concur - I'm kind of a "he who broke it fixes it"

Would it be possible to have config entries for device class be provided by core (for core's integrations) rather than requiring 1. an override in customization.yaml 2. edit the core.entity_registry 3. or worse requiring a user to "turn-it-off-and-turn-it-on-again"

I was able to fix the issue by changing the original_device_class to null in the core.entity_registry as suggested and then restarting.