core: Error in log for iPhones: iphone_battery_state has device class battery, state class None and unit None thus indicating it has a numeric value; however, it has the non-numeric value...
The problem
Seeing this entry in the logs:
2023-02-04 11:14:35.200 WARNING (MainThread) [homeassistant.components.sensor] Sensor sensor.<redacted>_iphone_battery_state has device class battery, state class None and unit None thus indicating it has a numeric value; however, it has the non-numeric value: Not Charging (<class 'str'>); 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
(note that a portion of the actual entity name has been <redacted> in the above)
What version of Home Assistant Core has the issue?
2023.2.0
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Supervised
Integration causing the issue
No response
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?
See above
Additional information
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 9
- Comments: 22 (2 by maintainers)
It will not get fixed. Since it kind of is, already. But the problem is that it was not fixed properly.
As per my observation there is already a fix applied. Fix, as in that the problem will not occur again. Thus devs don’t see the problem and it cannot really be replicated and no attention will be given to it. But the fix did not retroactively fix the problem for the people that already had the problem. So that you will have to do yourself.
The problem gets solved if you take note of the entity id’s that have these errors, and delete them. Some will then get re-created if they are still provided by the integration. And when re-created, they will have the correct options applied to them. Sad to see that it was “fixed” in such a sloppy way.
Still an issue as of 2023.9.2. This is polluting my logs. Any workarounds available in the short term?
bump - over a month now - this is out of our control - I’m willing to try to add the following customization to [attempt to] suppress the error, but this should be a quick fix for the developers