Should rpm be a unit of speed?

Configuration
1

I have several MQTT fan sensors which are configured with the following discovery topic.

{
  "name": "Element 0 Actual speed",
  "unique_id": "md1200_mqtt_element_0_actual_speed",
  "state_topic": "isilentllc/sensor/md1200_mqtt_element_0/state",
  "unit_of_measurement": "rpm",
  "device_class": "speed",
  "value_template": "{{ value_json.speed }}"
}

This results in a warning in the logbook that rpm is not a valid unit for device class speed.

Should rpm be a unit of speed or should this sensor have another class?

I lean towards adding rpm to the allowed speed units, but thought maybe there was a reason that it was excluded and that there was another preferred option for the device class.

2

According to the manual Sensor - Home Assistant there is no device class for it.
You could make a feature request for adding rotation_speed as a new device class

1 Like
3

by definition “speed” is displacement of position over time (miles per hour, meters per second, etc). RPM doesn’t measure that parameter so using speed as a device class wouldn’t make any sense. RPM is a measure of angular displacement over time or angular velocity.

people colloquially use speed for rpm but that’s not technically correct.

1 Like
4

While this is technically correct, the best kind of correct for certain, I’m not convinced that adding a new device class with angular velocity units makes sense. I’ve yet to see a fan controller labeled with anything other than speed. And as much as I’m a fan, pun intended, of being correct, I have to admit, I’d label it in the ui as speed also.

5

People colloquially use velocity for speed but that’s not technically correct either.

People colloquially use mass for weight but that’s not technically correct either.

Physicists are such pedants.

4 Likes
6

Well, this topic starts to get some rpm’s :smiley:

7

Can we please have radians/sec.

4 Likes
8

Out of curiosity, what device type do you have in mind that would use radians/sec?

9

An SI fan :slight_smile:

3 Likes
10

Hah, I wondered if that was the case. Makes sense, just hadn’t seen a fan with those units.

11

Why not? we have device classes being requested for other “strange” measurements. There’s an entire FR thread devoted to them.

those would be the units.

the device class would still be angular velocity.

:wink: :laughing:

12

Yeah I know :slight_smile:

2 Likes
13

haha, I found this thread again… always looking for RPM solution. I just realized that this message (along with other rpm-related messages) keep showing up in my logs:

Entity sensor.deckard_fan_2_speed (<class 'homeassistant.components.mqtt.sensor.MqttSensor'>) is using native unit of measurement 'RPM' which is not a valid unit for the device class ('speed') it is using; expected one of ['in/h', 'm/s', 'Beaufort', 'mm/h', 'mm/d', 'km/h', 'ft/s', 'kn', 'mph', 'in/d']; 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+mqtt%22

Did you guys notice that we have support for Beaufort scale?? I’ve never heard of that so I had to look it up: Beaufort scale - Wikipedia apparently for wind speed and its relationship to land or sea based on empirical data! That’s more important than reporting accurate scales for nickrout’s SI fan?!

I think if we can support a Beaufort scale as a speed, we can support RPM as a speed! Who’s with me??

1 Like
14

There’s not really any big benefit for using a specific device class other than being able to convert between units in the UI and you also get a default icon. Adding RPM to the speed device class would break the unit conversion feature and you’d be left with the sole benefit of getting a different default icon…. yay :man_shrugging:

The main issue in this thread seems to be the error messages resulting from using RPM with the speed device class. And this is easily solved by not specifying a device_class, or specifying None.

To summarize: An RPM sensor should have unit_of_measurement: RPM and also state_class: measurement and you’ll get zero errors and it will function and appear as you’d expect.

If there’s going to be a change to add the RPM unit, it would need to go into a new device class or else use the existing device class frequency. It’s not an option to lump it into a device class like speed due to the unit selection/conversion functionality.

15

This makes sense to me. Thanks Rick!