rospogrigio / localtuya

local handling for Tuya devices
GNU General Public License v3.0
2.94k stars 562 forks source link

Not able to set `state_class` attribute for sensors #531

Open marcins opened 3 years ago

marcins commented 3 years ago

Sensors support a state_class attribute which can be set to measurement to tell HA that this sensor provides a point in time measurement that can be aggregated (https://developers.home-assistant.io/docs/core/entity/sensor#long-term-statistics).

I have a temp/humdity sensor connected with LocalTuya, and then a bunch of temp/humidity sensors connected via Zigbee (zigbee2mqtt). The Zigbee sensors set this attribute, and so HA can overlay the data from those sensors onto a single history chart card. The localtuya added sensor does not get overlaid, but gets it's own chart - even though all other settings like unit of measurement are the same. I suspect the missing state_class is what makes the difference.

I tried to hack it in myself to test, but wasn't able to work out exactly where it would go to be sent with entity updates (I'm new to HA integrations). I will keep playing though and if I work it out I will update this issue.

licheng5625 commented 3 years ago

here is one workaround https://github.com/rospogrigio/localtuya/issues/536

another way is in the sensor.py add following

from homeassistant.components.sensor import DEVICE_CLASSES, DOMAIN, STATE_CLASS_MEASUREMENT, SensorEntity

class LocaltuyaSensor(LocalTuyaEntity, SensorEntity):

**@property
def state_class(self):
    return STATE_CLASS_MEASUREMENT**
CloCkWeRX commented 2 years ago

This is fixed by #721 - added test results

zolakt commented 1 year ago

Is there any proper fix or workaround for this?

The suggestion with editing sensor.py is not great, in my opinion. If I'm not mistaken it is hardcoding all sensors to have the "measurement" state class. That is not really correct in a lot of use cases. Not all sensors are measurements. Even some sensors for the energy dashboard aren't "measurement", but should instead be "total_increasing". e.g. if you have a dp that measures kWh, and sends the data in irregular intervals. Also, if you set the state class to "measurement" you must also provide "last_reset", which you can't hardcode like that. Not sure, but I think without "last_reset" the measurement can't be displayed in the energy dashboard.

I see this approach advertised on pretty much every related github issue, but in my opinion this is really not the way. We need an dropdown in the UI where this could be selected, similar to the device_class.

The only workaround I managed to come up with right now is to use a template sensor. Something like this:

template:
  - sensor:
    - name: 'Refrigerator energy'
      unique_id: 'refrigerator_kwh'
      unit_of_measurement: 'kWh'
      device_class: energy
      state_class: total_increasing
      state: '{{ state_attr("switch.refrigerator", "current_consumption") | float(0)}}'

I'm not a huge fan of template sensors, since I can't assign them to devices. And they are a pain to clean up manually once you change or delete them.

Any better suggestion that would let me choose if I want a "measurement" or "total_increasing" state_class?

Also, I didn't really get how is this fixed with #721. It hasn't been merged. And it's the same hardcoded approach I mentioned above

qrockz commented 4 months ago

Still not fixed after HOW MANY YEARS?

DominicWindisch commented 1 month ago

Still not possible via the UI, but there's workaround (mentioned here). You can modify the sensor properties in the configuration.yaml as so (note that overwriting device_class is not necessary since it can be setup via UI):


homeassistant:
  customize:
    sensor.my_tuya_power_sensor:
      state_class: measurement
      device_class: power
    sensor.different_powersensor:
      state_class: measurement
      device_class: power
    sensor.my_energy_sensor:
      state_class: total_increasing
      device_class: energy