Weather station sensors don't automatically convert units in Home Assistant, due to missing device_class

[electroflame]

What happened?

After updating to 2.12.0 (although I believe it started in 2.9.2) weather station (specifically Shelly WS90) temperature sensors no longer convert from Celsius to Fahrenheit automatically in Home Assistant.

What did you expect to happen?

The Celsius readings to automatically convert in Home Assistant, as they were before.

How to reproduce it (minimal and precise)

Set the regional units in Home Assistant to Fahrenheit, and see the sensor readings not convert.

Zigbee2MQTT version

2.12.0

Adapter firmware version

20201026

Adapter

Electrolama zzh!

Setup

Raspberry Pi 4, Docker

Device database.db entry

No response

Debug log

No response

Notes

I believe this is due to pull request #31234, which removed the device_class from most of the temperature sensors.

It seems like Home Assistant requires device_class being set to temperature for the automatic conversion to take place.

It's possible to override this via the devices: block in the configuration.yaml (which I've done) and now everything works as it did before. This isn't super obvious, however, so it's probably better to just revert the change, as I imagine I'm not the only weather station owner that uses Imperial units.

[danielbrunt57]

I'm seeing a similar issue with soil fertility sensors. Specifically, the Arteco ZS-SF00 is missing device_class and state_class for the conductivity sensor and I had to add overrides in devices.yaml so they'd be visible in the Plant Monitor integration. I don't know if a recent change introduced the current behavior or if they've been missing all along as I just acquired them.

'0xa4c138b46e1ffa5b':
  friendly_name: Flamingo Lily Sensor
  illuminance_calibration: 0
  homeassistant:
    soil_fertility:
      device_class: conductivity
      state_class: measurement

Reference: Olen / homeassistant-plant issue: Arteco ZS-SF00 (#457)

[Koenkk]

@danielpetrovic could you check this?

[danielpetrovic]

@electroflame
This change only affected the five sensors mentioned in the PR:

• dew_point (was temperature)
• wind_chill (was temperature)
• humidex (was temperature)
• apparent_temperature (was temperature)
• gust_speed (was wind_speed)

The change was intentional and the reasoning was mentioned inside the PR. I prefer this way, but yes you lose the automatic conversion functionality of Home Assistant when a sensor has no device_class, If you want that change reverted it is possible, but the bug that was present with the WS90 will be back, so users would need to manually change the names of the different sensors that overlap in name.

@Koenkk
Is there a preferred implementation for this?

I'm seeing a similar issue with soil fertility sensors. Specifically, the Arteco ZS-SF00 is missing device_class and state_class for the conductivity sensor and I had to add overrides in devices.yaml so they'd be visible in the Plant Monitor integration. I don't know if a recent change introduced the current behavior or if they've been missing all along as I just acquired them.

'0xa4c138b46e1ffa5b':
  friendly_name: Flamingo Lily Sensor
  illuminance_calibration: 0
  homeassistant:
    soil_fertility:
      device_class: conductivity
      state_class: measurement

Reference: Olen / homeassistant-plant issue: Arteco ZS-SF00 (#457)

soil_fertility not working has nothing to do with the other change, it simply does not exist yet in /lib/extension/homeassistant.ts so for that to work automatically, someone needs to add it inside it. The person that created your device didn't do that.

If my changes for the WS90 need to be undone, I can include it in my PR.

[electroflame]

@danielpetrovic
Yeah, those five are the issue (they're the only temperature-based ones, I think).

It's my opinion that the current behavior is actually a worse bug than the confusing naming, mainly because the naming can be easily rectified over in Home Assistant by just renaming the sensors (and those names stick). It's easier to identify since the naming is fundamentally a Home Assistant issue, so it makes sense to fix it over in Home Assistant (where it's fairly simple and intuitive to do so based on the actual sensor naming).

The way it works now is kind of ambiguous and confusing, namely figuring out A.) what the issue is and what part of the stack is at fault (Z2M, Home Assistant, the sensor itself?), B.) why it's working the way it is now (if you were using an older version like I was) and C.) how to fix it.

Can friendly_name get passed over to Home Assistant correctly, and not get dropped like name does? If so a better solution might be to set Friendly Name to a default, more descriptive name if it isn't set by the user (and there's more than one sensor with the same name/device_class), and maintain the device_class mapping.

[danielpetrovic]

@danielpetrovic Yeah, those five are the issue (they're the only temperature-based ones, I think).

It's my opinion that the current behavior is actually a worse bug than the confusing naming, mainly because the naming can be easily rectified over in Home Assistant by just renaming the sensors (and those names stick). It's easier to identify since the naming is fundamentally a Home Assistant issue, so it makes sense to fix it over in Home Assistant (where it's fairly simple and intuitive to do so based on the actual sensor naming).

The way it works now is kind of ambiguous and confusing, namely figuring out A.) what the issue is and what part of the stack is at fault (Z2M, Home Assistant, the sensor itself?), B.) why it's working the way it is now (if you were using an older version like I was) and C.) how to fix it.

Can friendly_name get passed over to Home Assistant correctly, and not get dropped like name does? If so a better solution might be to set Friendly Name to a default, more descriptive name if it isn't set by the user (and there's more than one sensor with the same name/device_class), and maintain the device_class mapping.

Once you set the device_class for a sensor, Friendly Name is ignored by HA. So it will just show 4 sensors with the name Temperature, if you don't manually alter them. Yes, after changing the names, they will be kept inside HA.

I'm fine with either, but I don't know what is the preferred way to do this. This was changed 3 months ago, and it's the first question about the change. @Koenkk is there a preferred way to handle these type of sensors?

[danielbrunt57]

@danielpetrovic, @Koenkk

soil_fertility not working has nothing to do with the other change, it simply does not exist yet in /lib/extension/homeassistant.ts so for that to work automatically, someone needs to add it inside it. The person that created your device didn't do that.

Now that I have a clue what's missing, and where, I will create a PR to add it.

[danielpetrovic]

@electroflame I've opened a PR that fixes both problems without choosing one over the other: #32392

What it does: Restores device_class on the 5 derived sensors (apparent_temperature, dew_point, humidex, wind_chill, gust_speed) and introduces a preserve_name: true flag in the lookup table. The name-deletion logic at the HA discovery layer is updated to skip deletion for entries with this flag set — so both device_class (enabling °C→°F conversion) and the explicit sensor name coexist in the discovery payload.

All existing sensors with device_class are unaffected.

[electroflame]

@danielpetrovic Sounds good to me -- thanks!