core: RFLink does not support device class, thus since an update to core HA reporting temperture sensors in C instead of F

The problem

PLEASE bear with me, this is my first git-hub post!

I’m using RFLink with a bunch of 433 temperature sensors, my GUI is set to F. For over a year everything has been reporting in F. Suddenly when updating core past 2022.4.7 everything goes to C.

From what I have been able to cobble together knowledge wise, HA used to automatically convert C to F in the user settings.

But that changed in a recent version of HA core.

People have had luck with MQTT sensors because they support “device class” whereas RFLink does not appear to support this.

Is there a way to get whoever works on RFLink to add device class to the integration?

What version of Home Assistant Core has the issue?

past 2022.4.7 maybe 2022.4.8?

What was the last working version of Home Assistant Core?

2022.4.7

What type of installation are you running?

Home Assistant OS

Integration causing the issue

RFLink

Link to integration documentation on our website

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

Diagnostics information

No response

Example YAML snippet

rflink:
port: /dev/ttyACM0

light:

    platform: rflink
    automatic_add: true

sensor:

    platform: rflink
    automatic_add: true
    devices:
    cresta_3101_bat:
    sensor_type: battery
    name: north house sensor battery
    cresta_3101_hum:
    sensor_type: humidity
    name: north house humidity
    cresta_3101_temp:
    sensor_type: temperature
    name: north house temperature

Anything in the logs that might be useful for us?

Additional information

Issue is discussed here in HA discussions

https://community.home-assistant.io/t/sensors-now-displaying-in-c-instead-of-f-after-update/420831/13

https://github.com/home-assistant/core/issues/71770

Similar issue with another integration needing device class added

https://github.com/home-assistant/core/issues/64570

Another git post with the same issue

https://github.com/home-assistant/core/issues/72625#issuecomment-1141776540

No response

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 80 (28 by maintainers)

Most upvoted comments

It will probably be included in beta 2022.12 on 11/30

javicalle on Nov 20, 2022

You can check in the HA tags page if the PR is included:

https://github.com/home-assistant/core/tags

javicalle on Nov 2, 2022

I hope that not will be needed. #79436 is moving forward.

javicalle on Oct 27, 2022

Maybe RFLink would need a couple of tweaks, but the principal issue is with the HA RFLink integration.

The ‘problem’ is that the RFLink integration doesn’t have a real maintainer. I contribute what I can, but small adjustments and little else. Also, most of the RFLink code I have customized in my installation so sometimes I don’t detect some of the issues until they are reported by users.

I can’t tell you if anyone is going to tackle the task any time soon, but in my experience this integration hasn’t had much support, so it’s hard for me to think that anyone would want to take on that task.

javicalle on Aug 22, 2022

What have you found?

It is not easy to me to track all the code logic, but I think that this is the code that ‘prints’ the UOM select:

https://github.com/home-assistant/frontend/blob/dev/src/panels/config/entities/entity-registry-settings.ts#L394-L418

If I’m reading it correctly, the entity must match:

domain=sensor ✔️
must have a device class ❓ (it can be configured in customize but not sure if is enought)
must have the unit_of_measurement attribute ✔️ (RflinkSensor extends SensorEntity that have the unit_of_measurement attribute)

My next try would be to implement all the SensorEntityDescription (similar to rfxtrx) but I believe that the unique_id would be also needed.

In the end, RFLink needs a full refactor from scratch because all the code is far behind the current HA architecture.

javicalle on Aug 22, 2022

Yes, I’ve confirmed that I have the version with native_unit_of_measurement and native_value. I add my edit to __init__.py after taking each update to the latest HA. I’m not maintaining a separate fork or anything.

kceventus on Aug 15, 2022

Interesting. Do we need to delete our components and let the new(er) rflink code re-discover?

No, there’s no need for that. But if you have a local RFLink custom_component, the update in HA will not catch the changes because your local version has been made over a older version and this will take precedence over the code of the new version.

The latest versions of this year have introduced multiple changes on the sensors and value conversions. The component may need some tweaking (I’m going to check out the reported UI to set the UOM), but as far as I can read the code, I’d say UOM conversions are already implemented.

javicalle on Aug 15, 2022

The problem as I see it is we don’t get the option in the UI to set the UOM, like other temperature sensors have:

kceventus on Aug 14, 2022

So you want me to take the code out of customize.yaml and put it into the configuation.yaml?

Or leave it in both?

homeassistant:
  customize:
    sensor.cresta_3101_temp:
      device_class: temperature

Is this what you want in configuation.yaml?

Please note, I am not very good at this. I’m a super user at best, I do NOT write much code. I get most of what is going on, but most of the finer points are lost on me. I’m not a dev, just a user with a problem who occasionally figures shit out.

I get around in linux, but mostly from copying other peoples code. I’m sorry I don’t get everything you are saying.

bluesdataventure on Jun 24, 2022