Add generic Smart Temperature Switch Power Monitor with Thermostat Pr… by OA6DXV · Pull Request #4689 · make-all/tuya-local

OA6DXV · 2026-03-13T18:42:20Z

…obe Sensor

This PR adds a device profile for a Tuya WiFi temperature controller relay. (Tuya Wifi 10A Smart Temperature Switch Power Monitor with Thermostat Probe Sensor for Fish Tank)

Datapoints (DP) mapping identified using tinytuya and verified with Tuya Cloud debugging tools:

DP 2 – switch_1
Type: Boolean
Main relay switch.

DP 4 – countdown_1
Type: Integer
Countdown timer before relay deactivation. The value is expressed in seconds.

DP 7 – cycle_time
Type: String
This value is a proprietary encoded string and is not interpreted by the LocalTuya profile.

DP 8 – work_mode
Type: Enum
Operating mode of the controller. Supported values: colding / hot

DP 9 – customize_mode_switch
Type: Boolean
Enables the automatic control mode using the configured temperature target.

DP 20 – temp_unit_convert
Type: Enum
Temperature unit selection. Values: c / f

DP 21 – temp_set_f
Type: Integer
Target temperature when the unit is set to Fahrenheit. Scaling: value ÷ 10

DP 22 – temp_set
Type: Integer
Target temperature when the unit is set to Celsius. Scaling: value ÷ 10

DP 27 – temp_current
Type: Integer
Current measured temperature in Celsius. Scaling: value ÷ 10

DP 28 – temp_current_f
Type: Integer
Current measured temperature in Fahrenheit. Scaling: value ÷ 10

DP 29 – vibration_value
Type: Integer
Temperature hysteresis or margin used for relay switching. Scaling: value ÷ 10

DP 30 – temp_correction
Type: Integer
Temperature sensor calibration offset. Scaling: value ÷ 2 Example: 3 = 1.5 degress

DP 55 – cold_delay
Type: Integer
Delay time before relay activation expressed in minutes.

DP 56 – cold_delay_switch
Type: Boolean
Enables or disables the relay delay feature.

Additional notes

The device stores separate target temperatures for Celsius and Fahrenheit. Changing the unit using DP20 does not automatically convert the stored values between DP21 and DP22.

The cycle_time datapoint (DP7) contains an encoded schedule string used internally by the device firmware and is not interpreted by this profile.

Tested on hardware with Home Assistant and tuya-local. All DPs verified via tinytuya and Tuya App.

…obe Sensor This PR adds a device profile for a Tuya WiFi temperature controller relay. (Tuya Wifi 10A Smart Temperature Switch Power Monitor with Thermostat Probe Sensor for Fish Tank) Datapoints (DP) mapping identified using tinytuya and verified with Tuya Cloud debugging tools: DP 2 – switch_1 Type: Boolean Main relay switch. DP 4 – countdown_1 Type: Integer Countdown timer before relay deactivation. The value is expressed in seconds. DP 7 – cycle_time Type: String This value is a proprietary encoded string and is not interpreted by the LocalTuya profile. DP 8 – work_mode Type: Enum Operating mode of the controller. Supported values: colding / hot DP 9 – customize_mode_switch Type: Boolean Enables the automatic control mode using the configured temperature target. DP 20 – temp_unit_convert Type: Enum Temperature unit selection. Values: c / f DP 21 – temp_set_f Type: Integer Target temperature when the unit is set to Fahrenheit. Scaling: value ÷ 10 DP 22 – temp_set Type: Integer Target temperature when the unit is set to Celsius. Scaling: value ÷ 10 DP 27 – temp_current Type: Integer Current measured temperature in Celsius. Scaling: value ÷ 10 DP 28 – temp_current_f Type: Integer Current measured temperature in Fahrenheit. Scaling: value ÷ 10 DP 29 – vibration_value Type: Integer Temperature hysteresis or margin used for relay switching. Scaling: value ÷ 10 DP 30 – temp_correction Type: Integer Temperature sensor calibration offset. Scaling: value ÷ 2 Example: 3 = 1.5 degress DP 55 – cold_delay Type: Integer Delay time before relay activation expressed in minutes. DP 56 – cold_delay_switch Type: Boolean Enables or disables the relay delay feature. Additional notes The device stores separate target temperatures for Celsius and Fahrenheit. Changing the unit using DP20 does not automatically convert the stored values between DP21 and DP22. The cycle_time datapoint (DP7) contains an encoded schedule string used internally by the device firmware and is not interpreted by this profile. Tested on hardware with Home Assistant and tuya-local. All DPs verified via tinytuya and Tuya App.

make-all · 2026-03-13T22:42:17Z

+          - scale: 60
+
+  - entity: select
+    name: Mode


Actually it would be better to combine most of these entities into a climate entity

That didn’t occur to me initially, but it actually makes a lot of sense. The device does behave more like a thermostat controller than just a relay with sensors.

I am not sure what the "Autowork" switch does. If it is switching between Thermostat operation and a manual switch, then I think you need to keep the Relay switch alongside the climate entity (use available to disable based on the dp 9 value).

The "Autowork" option enables the automatic temperature control mode.

When enabled, the device uses the configured target temperature and hysteresis to control the relay automatically.

In cooling mode for example:

When the measured temperature rises above the configured threshold, the relay turns on.

The relay stays on until the temperature drops back to the target temperature.

Once the target temperature is reached, the relay turns off again.

So effectively this enables the thermostat-style behavior where the relay is controlled based on the measured temperature and the configured trigger temperature.

I would make this a "Mode" select entity, mapped to options "Thermostat" and "Switch".

- entity: select translation_key: mode category: config dps: - id: 9 type: boolean name: option mapping: - dps_val: true value: thermostat - dps_val: false value: switch

I think it is clearer than the "Autowork" name the manufacturer has chosen.

make-all · 2026-03-13T22:44:16Z

+
+  - entity: number
+    name: Margin
+    class: temperature


temperature_delta

make-all · 2026-03-13T22:44:31Z

+
+  - entity: number
+    name: Calibration
+    class: temperature


temperature_delta

make-all · 2026-03-13T22:45:03Z

+    name: Margin
+    class: temperature
+    category: config
+    mode: box


Generally don't override HA for the mode

I forced the box mode to keep the interface closer to what the Tuya app shows. With sliders it becomes a bit annoying to see the exact value and adjust it precisely.

That said, I understand the preference to let HA decide the UI mode.

make-all · 2026-03-13T22:45:41Z

+            step: 5
+
+  - entity: number
+    name: Calibration


translation_key: temperature_calibration instead of name

make-all · 2026-03-13T22:51:36Z

+        name: switch
+
+  - entity: select
+    name: Unit


use translation_key: temperature_unit instead of the name, and use lowercase celsius and fahrenheit to match translation keys.

Sorry there was a mistake in what I wrote originally, the correct key is "temperature_unit"

make-all · 2026-03-13T22:52:59Z

+          - scale: 10
+
+  - entity: number
+    name: Margin


Standard naming is "Temperature hysteresis"

Totally agree, it is better to use the exact standard term.

make-all · 2026-03-13T22:56:06Z

+          max: 1940
+        mapping:
+          - scale: 10
+            step: 5


Double check this, normally F will be step 10, only C has half degree steps because it is lower resolution than F to start with.

I didn't run specific tests in Fahrenheit yet, but I can do so if you would like me to confirm whether the step should be 10 instead.

I meant to check against the info from Tuya.

With regards to whether it works or not, you may not be able to tell, the device might ignore the input but it appears to stay at the value to set.

Just from experience, because 0.5C steps are equal to 0.9F, most devices that have 0.5C steps just use 1F steps.

Just to clarify how this device handles units.

The device does not convert values between Celsius and Fahrenheit internally. Instead, it exposes separate datapoints for each unit:

DP21 = target temperature in Fahrenheit
DP22 = target temperature in Celsius

Which datapoint is actually used depends on the selected unit in DP20.

When DP20 is set to "c", the device uses DP22 and ignores DP21.
When DP20 is set to "f", the device uses DP21 and ignores DP22.

Changing the Celsius target temperature does not modify the Fahrenheit datapoint, and vice versa. They are stored independently.

So the device is not converting 0.5°C steps into Fahrenheit internally. It simply switches which datapoint it reads depending on the selected unit.

I understood that, it is common for devices to use separate dp for C and F. But they still have some design concept that uses 0.5 C steps only to get similar granularity as the F steps. The Query Things Data Model result is the best reference to see what the actual device implementation is.

I ran additional tests with the device configured to use Fahrenheit units.

Here is what I observed:

Temperature calibration (DP30)

In Celsius mode the calibration changes in 0.5°C increments.

In Fahrenheit mode the calibration changes in 1°F increments.

Temperature range / hysteresis (DP29)

The value increments by 0.5 in both Celsius and Fahrenheit modes.

The minimum allowed value is 1.0.

Target temperature (DP21 / DP22)

When Autowork is enabled, the target temperature changes in 0.5 increments in both units.

make-all · 2026-03-13T22:58:51Z

@@ -0,0 +1,168 @@
+name: Temperature Switch


HA naming convention is to only capitalise the first word of device and entity names.

github-project-automation bot added this to Tuya Local Mar 13, 2026

github-project-automation bot moved this to 👀 In review in Tuya Local Mar 13, 2026

make-all reviewed Mar 13, 2026

View reviewed changes

make-all moved this from 👀 In review to 🏗 Stalled in Tuya Local Mar 13, 2026

Conversation

OA6DXV commented Mar 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

make-all Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

make-all Mar 13, 2026 •

edited

Loading