Home Assistant release with the issue:
0.68.1
Last working Home Assistant release (if known):
I've been using the NUT sensor for a few months now, and I've never seen it display correctly.
Operating environment (Hass.io/Docker/Windows/etc.):
Virtualenv with Python 3.6.3 on a Raspberry Pi 3
Component/platform:
NUT sensor
Description of problem:
The NUT sensor shows the raw status of a monitored UPS, rather than the human-readable status. E.g.: 'OL' instead of 'Online', 'OB' instead of 'On Battery', ...

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
- platform: nut
name: "Host UPS"
host: 127.0.0.1
port: 3493
username: ****
password: ****
resources:
- battery.charge
- battery.runtime
- battery.voltage
- input.voltage
- ups.load
- ups.status
- platform: nut
name: "NAS UPS"
host: 192.168.***.*
port: 3493
username: ****
password: ****
resources:
- battery.charge
- battery.runtime
- battery.voltage
- input.voltage
- ups.load
- ups.status
Traceback (if applicable):
Additional information:
It was because of PR #13787 that I noticed that the code has a list of every possible UPS status with its human-readable counterpart (lines 109-124 in nut.py):
STATE_TYPES = {
'OL': 'Online',
'OB': 'On Battery',
'LB': 'Low Battery',
'HB': 'High Battery',
'RB': 'Battery Needs Replaced',
'CHRG': 'Battery Charging',
'DISCHRG': 'Battery Discharging',
'BYPASS': 'Bypass Active',
'CAL': 'Runtime Calibration',
'OFF': 'Offline',
'OVER': 'Overloaded',
'TRIM': 'Trimming Voltage',
'BOOST': 'Boosting Voltage',
'FSD': 'Forced Shutdown',
}
It seems the code doesn't make (correct) use of this list. The fix is probably pretty simple, but I couldn't make sense of the code myself (lines 215-225 in nut.py) as I'm not a developer.
That mapping of state types is only used when generating the device attributes visible in the "more info" dialogue. The state shown on the card is the raw value coming from NUT.
Imho, having it the other way round would make more sense: see the human-readable state at a glance, and the raw data in the more-info dialog.
True, for this particular sensor type it would make more sense. However, all NUT sensors generated by this component show the state (human-readable) in their more info dialogue.
So, we would be turning around the behaviour of this one sensor type only.
Sounds alright to me 馃檪
How about a compromise: On the state card the sensor shows the human-readable form of the status, and in each more info dialogue we show the human-readable form and the raw value? This way all more info dialogues remain consistent.
State Card:

More Info:

Fix for this issue and some additional small enhancements here: https://github.com/home-assistant/home-assistant/compare/dev...exxamalte:nut-enhancements
There is one more aspect that we should consider: automations. I haven't set one up for my UPS, but you could for example set up an automation that sends a notification if the battery needs replacement.
trigger:
<on state change of status sensor to 'RB'>
action:
<send me an e-mail or pushover message to replace battery>
Maybe the solution is to have an additional sensor that shows the human-readable form of the status? That way you can use the raw value in automations, and the nice one in the UI.
I'm not sure what the best approach is here. I suspect one of the main devs will have to give their opinion on that.
And I currently don't have any automations set up for my UPS' either, but any change could potentially be a breaking change for someone who does.
OK, so now I introduced a new virtual sensor type for the display status in a human-readable. It's based on the status coming from NUT. This way there is no breaking change, each user can decide if they want to use the raw value for example in automations (hidden in the UI), and the human-readable value in the UI.

Most helpful comment
Imho, having it the other way round would make more sense: see the human-readable state at a glance, and the raw data in the more-info dialog.