Convert celsius to fahrenheit using scale?

[backcountrymountains]

I have the Pioneer WYT mini-split that has been a bit of trouble.
The set point temperature is in Fahrenheit but the current temperature is in Celsius.

id 2 is the set point and id 3 is the current temperature.
I'd like to do math on id 3 to convert it to Fahrenheit:

    - id: 2
      type: integer
      name: temperature
      range:
        min: 610
        max: 880
      mapping:
        - scale: 10
          step: 10
      unit: F
    - id: 3
      name: current_temperature
      type: integer
      mapping:
        - scale: 9/5 * x + 32
      unit: F

I don't think this will work because scale seems to only multiply by a factor.

After glancing at how scale works in the code, what if there was just a math: mapping that was separate from scale and step and precision that just did arithmetic on a DPiD? This would probably only work for read-only DPiDs because trying to figure out how to invert the function to set a DPiD would be complicated.

Probably not a good idea:
Would it be possible to change the logic for the scale so that it could do arbitrary arithmetic? Like interpret scale: 9/5 * x + 32 as set x to DPiD 3, evaluate scale and return the result?

Maybe useful:
Alternatively, would it be possible to add an offset mapping so that people could do

- scale: 9/5
- offset: 32

and it would do the scale the DPiD and then add the value of offset?

Somebody besides me might like this:
Alternatively, alternatively, would it be possible to add a mapping c-to-f: that is just hard-coded to convert the DPiD from Celsius to Fahrenheit? This would be useful because it's easy to invert.

I think there's at least one workable idea out of all of these options. For the time being I'm mapping for every Celsius value between 15 and 32 to a Fahrenheit value.

Thanks

Boo:

    - id: 3
      name: current_temperature
      type: integer
      mapping:
        - dps_val: 15
          value: 59 
        - dps_val: 16
          value: 61 
        - dps_val: 17
          value: 63 
        - dps_val: 18
          value: 64 
        - dps_val: 19
          value: 66 
        - dps_val: 20
          value: 68 
        - dps_val: 21
          value: 70 
        - dps_val: 22
          value: 72 
        - dps_val: 23
          value: 73 
        - dps_val: 24
          value: 75 
        - dps_val: 25
          value: 77 
        - dps_val: 26
          value: 79 
        - dps_val: 27
          value: 81 
        - dps_val: 28
          value: 82 
        - dps_val: 29
          value: 84 
        - dps_val: 30
          value: 86 
        - dps_val: 31
          value: 88
        - dps_val: 32
          value: 90
      unit: F

[make-all]

There is no mechanism to shift the values, which is required in addition to a scale to convert between Fahrenheit and Celsius. On another device with this flaw, the solution was to not include current temperature in the climate entity, but make it a separate sensor instead. That way the units can be independent of the temperature unit for the set temperature control of the climate entity.

For the UI, you need to either put up with the separate temperature display, or use a template entity to combine them back into one climate entity after conversion.

[make-all]

There is also one thermostat device using a huge mapping like your workaround, but I think that case was determined not to be a unit mixup but just values that didn't match (seems like due to a faulty unit conversion factor in the device).

I'm not really in favour of introducing new features just to deal with buggy devices like this, as the features tend to be complex and take disproportionate support effort for the value they add.

[make-all]

daizuki_heatpump is the other device with this same mixed up units bug. You may want to check if that config is matching your device before writing a new one from scratch, as the same bug possibly means these are just rebranded versions of the same device.

[backcountrymountains]

I totally understand not adding more features, it can get out of hand with all the requests for specific use cases. Since the unit only sends integer values for current_temperature, it really isn't a big deal to just map the values.
I've tried the daizuki_heatpump but it wasn't as good for my device.

It really seems like manufacturers that use Tuya for device control are just hacking stuff together without any real effort at standardization.

Anyway, tuya-local provides excellent control of my device, so thank you for that!