Tick off sensor creation from todo list.

Expand coverage of sensor tests.

README.md

@@ -348,13 +348,12 @@ You can find these keys the same way as you would for any Tuya local integration
 
 ## Next steps
 
-1. A generic sensor entity is needed to surface some of the sensors that are currently attributes in a way that works with HA's analytics and energy features.
-2. Remove the need for custom classes for gpph heater and goldair dehumidifier.
+1. Remove the need for custom classes for gpph heater and goldair dehumidifier.
 These devices from upstream have some complex logic that currently cannot be represented in the config files.  Find a way to configure this logic so the last of the legacy code can be removed.
-3. This component is mosty unit-tested thanks to the upstream project, but there are a few more to complete. Feel free to use existing specs as inspiration and the Sonar Cloud analysis to see where the gaps are.
-4. Once unit tests are complete, the next task is to complete the Home Assistant quality checklist before considering submission to the HA team for inclusion in standard installations.
-5. Discovery seems possible with the new tinytuya library, though the steps to get a local key will most likely remain manual.  Discovery also returns a productKey, which might help make the device detection more reliable where different devices use the same dps mapping but different names for the presets for example.
-6. number and select entities would help to surface more of the settings that do not fit into the standard types.
+2. This component is mosty unit-tested thanks to the upstream project, but there are a few more to complete. Feel free to use existing specs as inspiration and the Sonar Cloud analysis to see where the gaps are.
+3. Once unit tests are complete, the next task is to complete the Home Assistant quality checklist before considering submission to the HA team for inclusion in standard installations.
+4. Discovery seems possible with the new tinytuya library, though the steps to get a local key will most likely remain manual.  Discovery also returns a productKey, which might help make the device detection more reliable where different devices use the same dps mapping but different names for the presets for example.
+5. number and select entities would help to surface more of the settings that do not fit into the standard types.
 
 Please report any issues and feel free to raise pull requests.
 [Many others](https://github.com/make-all/tuya-local/blob/main/ACKNOWLEDGEMENTS.md) have contributed their help already.

tests/devices/test_goldair_dehumidifier.py

@@ -12,7 +12,12 @@ from homeassistant.components.climate.const import (
 )
 from homeassistant.components.light import COLOR_MODE_ONOFF
 from homeassistant.components.lock import STATE_LOCKED, STATE_UNLOCKED
-from homeassistant.const import STATE_UNAVAILABLE, TEMP_CELSIUS
+from homeassistant.const import (
+    DEVICE_CLASS_HUMIDITY,
+    DEVICE_CLASS_TEMPERATURE,
+    STATE_UNAVAILABLE,
+    TEMP_CELSIUS,
+)
 
 from ..const import DEHUMIDIFIER_PAYLOAD
 from ..helpers import assert_device_properties_set
@@ -686,3 +691,11 @@ class TestGoldairDehumidifier(TuyaDeviceTestCase):
             self.switch._device, {AIRCLEAN_DPS: False}
         ):
             await self.switch.async_toggle()
+
+    def test_sensor_state_class(self):
+        self.assertEqual(self.temperature.state_class, "measurement")
+        self.assertEqual(self.humidity.state_class, "measurement")
+
+    def test_sensor_device_class(self):
+        self.assertEqual(self.temperature.device_class, DEVICE_CLASS_TEMPERATURE)
+        self.assertEqual(self.humidity.device_class, DEVICE_CLASS_HUMIDITY)