Photogad commented 2 years ago

The problem

You can see below what it reports in SmartLife vs. Home Assistant

Screenshot_20220218-230756_Home Assistant Screenshot_20220218-231142_Smart Life

What version of Home Assistant Core has the issue?

2022.2.9

What was the last working version of Home Assistant Core?

2022.2.7

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Tuya

Link to integration documentation on our website

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

Diagnostics information

tuya-6e1a4ae19b74756253472cd31dae3077-Garage Tower Heater-29e4efe2c63a7c77d1de1fb9d91f5c57.json.txt

Example YAML snippet

Not sure

Anything in the logs that might be useful for us?

Not sure

Additional information

Nope

Santanachia commented 2 years ago

@maxkrok if I understand correctly, the step × scale^1 calculation is done for all Tuya devices in base.py. Find that calculation.

frenck commented 2 years ago

@starkillerOG I'm not sure which category to use. I've never used their ticket system myself, I see screenshots from it regularly, but that's about it 🤷

Santanachia commented 2 years ago

@starkillerOG search for API at service.console.tuya.com

maxkrok commented 2 years ago

this is a diagnostic from my device

{
  "home_assistant": {
    "installation_type": "Home Assistant Supervised",
    "version": "2022.2.9",
    "dev": false,
    "hassio": true,
    "virtualenv": false,
    "python_version": "3.9.7",
    "docker": true,
    "arch": "armv7l",
    "timezone": "Europe/Moscow",
    "os_name": "Linux",
    "os_version": "5.10.63-v7l+",
    "supervisor": "2022.01.1",
    "host_os": "Raspbian GNU/Linux 10 (buster)",
    "docker_version": "20.10.12",
    "chassis": "",
    "run_as_root": true
  },
  "custom_components": {
    "sonoff": {
      "version": "v2.4.6",
      "requirements": [
        "pycryptodome>=3.6.6"
      ]
    },
    "hacs": {
      "version": "1.22.0",
      "requirements": [
        "aiogithubapi>=21.11.0"
      ]
    },
    "localtuya": {
      "version": "3.2.1",
      "requirements": []
    }
  },
  "integration_manifest": {
    "domain": "tuya",
    "name": "Tuya",
    "documentation": "https://www.home-assistant.io/integrations/tuya",
    "requirements": [
      "tuya-iot-py-sdk==0.6.6"
    ],
    "dependencies": [
      "ffmpeg"
    ],
    "codeowners": [
      "@Tuya",
      "@zlinoliver",
      "@METISU",
      "@frenck"
    ],
    "config_flow": true,
    "iot_class": "cloud_push",
    "dhcp": [
      {
        "macaddress": "105A17*"
      },
      {
        "macaddress": "10D561*"
      },
      {
        "macaddress": "1869D8*"
      },
      {
        "macaddress": "381F8D*"
      },
      {
        "macaddress": "508A06*"
      },
      {
        "macaddress": "68572D*"
      },
      {
        "macaddress": "708976*"
      },
      {
        "macaddress": "7CF666*"
      },
      {
        "macaddress": "84E342*"
      },
      {
        "macaddress": "D4A651*"
      },
      {
        "macaddress": "D81F12*"
      }
    ],
    "is_built_in": true
  },
  "data": {
    "endpoint": "https://openapi.tuyaeu.com",
    "auth_type": 0,
    "country_code": "7",
    "app_type": "tuyaSmart",
    "mqtt_connected": true,
    "disabled_by": null,
    "disabled_polling": false,
    "name": "\u041a\u0430\u0431\u0438\u043d\u0435\u0442",
    "model": "SEA80*-DF1",
    "category": "wk",
    "product_id": "foitasaq52xwyqmt",
    "product_name": "Thermostat(RF)",
    "online": true,
    "sub": true,
    "time_zone": "+08:00",
    "active_time": "2020-02-24T14:27:10+00:00",
    "create_time": "2020-02-24T14:27:10+00:00",
    "update_time": "2021-12-21T03:31:59+00:00",
    "function": {
      "switch": {
        "type": "Boolean",
        "value": {}
      },
      "temp_set": {
        "type": "Integer",
        "value": {
          "unit": "\u00b0C",
          "min": 50,
          "max": 950,
          "scale": 1,
          "step": 5
        }
      }
    },
    "status_range": {
      "switch": {
        "type": "Boolean",
        "value": {}
      },
      "temp_set": {
        "type": "Integer",
        "value": {
          "unit": "\u00b0C",
          "min": 50,
          "max": 950,
          "scale": 1,
          "step": 5
        }
      },
      "temp_current": {
        "type": "Integer",
        "value": {
          "unit": "\u00b0C",
          "min": 0,
          "max": 990,
          "scale": 1,
          "step": 1
        }
      },
      "temp_unit_convert": {
        "type": "Enum",
        "value": {
          "range": [
            "c",
            "f"
          ]
        }
      }
    },
    "status": {
      "switch": true,
      "temp_set": 300,
      "temp_current": 265,
      "temp_unit_convert": "c"
    },
    "home_assistant": {
      "name": "\u041a\u0430\u0431\u0438\u043d\u0435\u0442",
      "name_by_user": null,
      "disabled": false,
      "disabled_by": null,
      "entities": [
        {
          "disabled": false,
          "disabled_by": null,
          "entity_category": null,
          "device_class": null,
          "original_device_class": null,
          "icon": null,
          "original_icon": null,
          "unit_of_measurement": null,
          "state": {
            "entity_id": "climate.kabinet",
            "state": "heat_cool",
            "attributes": {
              "hvac_modes": [
                "off",
                "heat_cool"
              ],
              "min_temp": 25.0,
              "max_temp": 30,
              "target_temp_step": 0.5,
              "current_temperature": 26.5,
              "temperature": 150.0,
              "friendly_name": "\u041a\u0430\u0431\u0438\u043d\u0435\u0442",
              "supported_features": 1
            },
            "last_changed": "2022-02-20T21:35:56.778095+00:00",
            "last_updated": "2022-02-20T21:35:56.778095+00:00"
          }
        }
      ]
    }
  }
}

could anybody point me what comes from tuya and what is already perverted by HASS

          "min_temp": 25.0,
          "max_temp": 30,

I have in customization as max_temp: 30 in HASS, but 25.0 is 5 multilpied on 5 from native device settings

  "temp_set": 300,
  "temp_current": 265,

those are multiplide by 10

          "current_temperature": 26.5, - this is correct
          "temperature": 150.0, - this is multiplied by 5

please help to make a correct patch

frenck commented 2 years ago

please help to make a correct patch

There is no correct patch at this point. I would like to ask you to explore this further in order places. Thanks 👍

maxkrok commented 2 years ago

There is no correct patch at this point. I would like to ask you to explore this further in order places. Thanks 👍

Dear @frenck the correct way to bring the situation at some compromise would be to give the OLD GOOD code when it was working correctly.. So people could decide themslves what to do. Now I'm totally confused, why the talks started from the core versions and came to tuya component sources??? Could you give please the link to the code that worked for all people here in 2022.2.7 version of the core or some version in tuya component... At least we would be able to solve the problem... My children cannot feel comfortable now because heating is not working in the house.. It is not a joke.. I need URGENT patch...

frenck commented 2 years ago

the correct way to bring the situation at some compromise would be to give the OLD GOOD code when it was working correctly.. So people could decide themslves what to do.

That is fine, but customizations to the core are not supported by the Home Assistant project. Its fine, but we do not want to endorse, support, or motivate to do so. Hence I ask you to not continue discussing your workaround effort in our issue tracker.

Thanks 👍

Santanachia commented 2 years ago

{
  "data": {
    "status_range": {
      "temp_current": {
        "type": "Integer",
        "value": {
          "unit": "°C",
          "min": 0,
          "max": 700,
          "scale": 1,
          "step": 5
        }
      }
    },
    "status": {
      "temp_current": 190,
    }
  }
}

@frenck, could you write how the current temperature of 19°C was converted to 190 and how 190 was converted to 95°C in HA?

frenck commented 2 years ago

@Santanachia (190 x 5) ÷ (1 × 10^1) = (950) ÷ (10) = 95

Santanachia commented 2 years ago

according to the documentation, transferred data is value × step × scale^1, so if we want to recover the correct value, we should divide by step × scale^1, not multiply by step and divide by scale^1?

frenck commented 2 years ago

so if we want to recover the correct value, we should divide b

That not correct. See documentation:

https://developer.tuya.com/en/docs/iot/datatypedescription?id=K9i5ql2jo7j1k#title-2-Integer%20type%20example

Santanachia commented 2 years ago

there is no multiplication anywhere here.

Santanachia commented 2 years ago

frenck commented 2 years ago

@Santanachia Yes, because in that example step and scale are both 1, thus 1 x 1 = 1

Santanachia commented 2 years ago

can you point to any example of an operation where the values are other than 1? 2230*1 / (10^1) will give the same result as 2230 / 1*(10^1) so these examples from the documentation are not very clear

frenck commented 2 years ago

Sure, there have been particular many issue reported with Moes thermostats that do use a step 0 or 1 with a scale of 5. Multiple of those threads have conversations attached by Tuya employees.

Additionally, the documentation clearly states: step x scale. Moving of division or multiplication has no effect, in this case, they are mathematically the same.

(1000 / 5) / (10^1) = (200) / (10) = 20 (<-- how Home Assistant Calculates it)
1000 / (5 * 10^1) = 1000 / (50) = 20 (<-- how it is documented).

Santanachia commented 2 years ago

https://github.com/home-assistant/core/issues/66853#issuecomment-1046908402

(1000 / 5) / (10^1) = (200) / (10) = 20 (<-- how Home Assistant Calculates it)

https://github.com/home-assistant/core/issues/66853#issuecomment-1046888893

(190 x 5) ÷ (1 × 10^1) = (950) ÷ (10) = 95

you just admitted that HA counts incorrectly because: in documentation -> 1000 / (5 * 10^1) != (1000 * 5) / (10^1) <- in HA

frenck commented 2 years ago

Let's talk code, that clearer to me, as I'm starting to get dizzy now too 😵

Because my comment (you highlight here):

That comment is indeed wrong and not how HA calculates it.

So, code!

Our existing code:

    def scale_value_current(self, value: float | int) -> float:
        """Scale a value (current code)."""
        return value * self.step / (10 ** self.scale)

I think this would be what you are suggesting and could be read from the docs as well:

    def scale_value_suggested(self, value: float | int) -> float:
        """Scale a value (as per documentation)."""
        return value / (self.step * (10 ** self.scale))

Agreed, those are not the same and have different results.

scale_value_current -> 190 * 5 / (10 ** 1) = 95.0 scale_value_suggested -> 190 / (5 * (10 ** 1)) = 3.8

That wouldn't solve your case here: https://github.com/home-assistant/core/issues/66853#issuecomment-1046872222

Santanachia commented 2 years ago

from the very beginning you write that you caused an error in our devices, because that's how it is according to the documentation. So now I have a suggestion. Either do as it is in the documentation, or back out of the changes.

right now you have fixed it for one and broken it for the other. Why are they better? Before and after is not as it should be according to the documentation.

frenck commented 2 years ago

So now I have a suggestion. Either do as it is in the documentation, or back out of the changes.

Back out seems incorrect as well, as we know the previous situation was wrong to begin with. That sounds even weirder and would not agree with doing such a thing either.

right now you have fixed it for one and broken it for the other.

That will always be the case with Tuya devices (due to the amount of customization they allow), and not a factor IMHO.

Why are they better?

Because that was how it was provided by Tuya as how it should have been done.

I'll reach out (again), but guaranteed, whatever the end implementation will become, it will break stuff.

In the end, if we interpreted the documentation as in the above scale_value_suggested example, it would be even more drama (including for everyone in this thread).

Santanachia commented 2 years ago

Could you contact Tuya and ask them to complete the documentation so that it is readable, that is, with an example that cannot be misinterpreted? For example:

{
  "data": {
    "status_range": {
      "temp_current": {
        "type": "Integer",
        "value": {
          "scale": 2, // not 1
          "step": 5 // not 1
        }
      }
    },
    "status": {
      "temp_current": 190
    }
  }
}

this way there will be no doubt as to what is where.

In the end, if we interpreted the documentation as in the above scale_value_suggested example, it would be even more drama (including for everyone in this thread).

then you can refer to the documentation and write us to contact Tuya. ;) Now we can't, because it's not only Tuya, it's also HA miscounting

nelsonamen commented 2 years ago

Its possible to make a template that show the correct number in UI ?

erjanmx commented 2 years ago

Hey there, for now I found a solution just by rolling back the HA version to 2022.2.7, my temperatures are correct now.

All I did is ha core update --version=2022.2.7 in ssh terminal of HA

Hope it can help someone until a real fix is out

Photogad commented 2 years ago

@frenck is it possible Tuya has made an incorrect calculation in their documentation, in 2022.2.7 all my Tuya devices work properly and now after the "correct" calculation from the documentation I have multiple Tuya devices working wrong. Logically, that doesn't make sense to be correct.

You can pass this issue off as need to contact device manufacturer, however as the device works correctly, Tuya app works correctly, and Home Assistant works wrong, clearly problem need to be fixed by Home Assistant. Home Assistant is the point causing the issue due to your implementation, not the other two.

heinoldenhuis commented 2 years ago

@frenck @Santanachia I read the documentation and the example is very brief for the calculation.

As I understand the calculation would be as follows: (value * step) / (step * 10^scale) which for the example would be (2230 * 1) / (1 * 10^1) = 2230 / 10 = 223.0 volts

For my device this would be '(195 5) / (5 10^1) = 975 / 50 = 19,5'

The fact is that they have shorted the example too much my just putting 2230 / 10 in there.

Also the fix with scale=0 (https://github.com/home-assistant/core/pull/66664#issuecomment-1042332226) is resolved with this, So (58.1 * 1) / (1 * 10^0) = 58.1

Are there other devices with different step and scale parameters?

Photogad commented 2 years ago

@frenck

the correct way to bring the situation at some compromise would be to give the OLD GOOD code when it was working correctly.. So people could decide themslves what to do.

That is fine, but customizations to the core are not supported by the Home Assistant project. Its fine, but we do not want to endorse, support, or motivate to do so. Hence I ask you to not continue discussing your workaround effort in our issue tracker.

Thanks 👍

Why not add setting to HASS allow user to customize temperature scale (or any sensor scale, such as humidity %) of device they choose in HASSUI? This will solve any conversion issue now, and in the future with other devices (even not TUYA). 🤷

maxkrok commented 2 years ago

Why not add setting to HASS allow user to customize temperature scale

They will do. There is no other desicion..

frenck commented 2 years ago

Its possible to make a template that show the correct number in UI ?

@nelsonamen I'm sorry, haven't you read this issue before you made that comment? This is what this issue about 🤷

it possible Tuya has made an incorrect calculation in their documentation

@Photogad Sure 🤷

You can pass this issue off as need to contact device manufacturer, however as the device works correctly

@Photogad Please read the rest of this conversation in this issue before starting something completely derailed. Thanks 👍

Why not add setting to HASS allow user to customize temperature scale

@Photogad This has been answered multiple times in this discussion. If you want to join a discussion please read it. Saves everybody energy and prevents we get stuck in repeat. Thanks 👍

They will do. There is no other decision.

@maxkrok We will not, thus your comments set false expectations. Please read up and learn above why we can't provide such a thing.

Santanachia commented 2 years ago

heinoldenhuis

As I understand the calculation would be as follows: (value * step) / (step * 10^scale) which for the example would be (2230 * 1) / (1 * 10^1) = 2230 / 10 = 223.0 volts

This is not correct

(value * step)        step * value         value
------------------ = --------------    =  ----------
(step * 10^scale)    step * 10^scale      10^scale

moreover, nowhere in the documentation is there a complete description of how to convert value to the correct temperature, only how to convert temperature to value value = temperature `step scale ^1- here is the first bug in documentation, because it should be 10^scale formulavalue = temperature step 10^scalecan be converted totemperature = value / step * 10^scale` unfortunately HA does something completely different.

Photogad commented 2 years ago

Since devs here do not want to fix issue, is this more correct repo to report bug? https://github.com/tuya/tuya-home-assistant

I don't know about that one and how it's related, but it says it's maintained by both Tuya and HASS community

Photogad commented 2 years ago

@frenck @Santanachia Today I log into iot.tuya and compare two heater devices, one that is working wrong in HASS, the other that is working correctly in HASS.

First, I notice the "bad" heater reports as just "Heater", and the "Good" heater reports as the actual model number and manufacturer.

Next, I notice the "bad" heater reports only F (Fahrenheit) to Tuya, and the "Good" heater reports both F and C (celsius).

"Bad Heater"

"Good Heater"

Next, looking at device debug logs for status, I notice as well that the "bad heater" and "good heater" both have scale of 0 and step of 1.

Could issue be with HASS trying to interpret Fahrenheit as celsius and applying wrong conversion or such? What other details can be gleamed from the referenced data?

maxkrok commented 2 years ago

Since devs here do not want to fix issue, is this more correct repo to report bug?

I have repaired my hass.. i took old code from base.py from 14.02.2022... but as i was told, here is not the right place to show the bug fixes.. here is some place for philosophy, as i understood.. i'm new to the local politics and if somebody will create an appropriate thread i will post the code there.. but next core update will break the code again..

Photogad commented 2 years ago

Since devs here do not want to fix issue, is this more correct repo to report bug?

I have repaired my hass.. i took old code from base.py from 14.02.2022... but as i was told, here is not the right place to show the bug fixes.. here is some place for philosophy, as i understood.. i'm new to the local politics and if somebody will create an appropriate thread i will post the code there.. but next core update will break the code again..

Can you message me with how you fixed it? I much would like to get HASS fixed to work correctly even if we have to go unofficial route to "hack" it

Photogad commented 2 years ago

@frenck

Is it possible this is a C/F issue?

I did a little investigation, and I noticed my heater that is not reporting correctly in HASS is an American "Fahrenheit Only" heater ... it has no way to set it to celsius, not on the unit itself, it's always Fahrenheit. Is it possible the scale/step included in the Tuya API documentation is for Celsius only; or possibly some other issue related to that??

Edit: Interestingly, if I set the Tuya app to report in celsius for this heater, the HASS implementation still reports in Fahrenheit (incorrect Fahrenheit temperature)

maxkrok commented 2 years ago

Can you message me with how you fixed it? I much would like to get HASS fixed to work correctly even if we have to go unofficial route to "hack" it

I took old version from here.. https://github.com/home-assistant/core/commit/dbc445c2fa1feb2abaa7bd40c13196665ce468eb?diff=split#diff-6bad04944244b72aa265cf8b1164a0a9ded1e8c74d8757e417a2868a344b5825

Just exchange new lines 44,48,52 and 85 with old ones...

Santanachia commented 2 years ago

@Photogad C to F ratio is different than 5

Photogad commented 2 years ago

@Santanachia

@Photogad C to F ratio is different than 5

Sorry I am new to this type of coding.

From my diagnostic file in HASS (log pruned to remove irrelevant data):

`       "function": {
  "temp_unit_convert": {
    "type": "Enum",
    "value": {
      "range": [
        "f"
      ]
    }
  },

  "temp_set": {
    "type": "Integer",
    "value": {
      "unit": "\u2109",
      "min": 60,
      "max": 86,
      "scale": 0,
      "step": 1

"status_range": {
  "temp_unit_convert": {
    "type": "Enum",
    "value": {
      "range": [
        "f"
      ]
    }
  },
  "switch": {
    "type": "Boolean",
    "value": {}
  },
  "temp_set": {
    "type": "Integer",
    "value": {
      "unit": "\u2109",
      "min": 60,
      "max": 86,
      "scale": 0,
      "step": 1
    }
  },
  "temp_current": {
    "type": "Integer",
    "value": {
      "unit": "\u2109",
      "min": 32,
      "max": 122,
      "scale": 0,
      "step": 1
    }

"status": {
  "switch": true,
  "temp_set": 71,
  "temp_current": 32,
  "mode": "auto",
  "shake": true,
  "light": true,
  "countdown_left": 9,
  "temp_unit_convert": "f"

          ],
          "min_temp": 140,
          "max_temp": 187,
          "target_temp_step": 1.0,
          "swing_modes": [
            "off",
            "on"
          ],
          "current_temperature": 90,
          "temperature": 160,
          "swing_mode": "on",
          "icon": "mdi:patio-heater",
          "friendly_name": "Garage Tower Heater",
          "supported_features": 33`

It seems HASS is trying to convert F to F using the C to F conversion? Am I understand this correctly or no?

I looked at the commit in the core that @frenck applied in 2022.2.9:

` if self._current_temperature.scale == 0 and self._current_temperature.step != 1:

The current temperature can have a scale of 0 or 1 and is used for

         # rounding, Home Assistant doesn't need to round but we will always
         # need to divide the value by 10^1 in case of 0 as scale.
         # https://developer.tuya.com/en/docs/iot/shift-temperature-scale-follow-the-setting-of-app-account-center?id=Ka9qo7so58efq#title-7-Round%20values
         temperature = temperature / 10`

Then I looked at the referenced docs, and it says:

If the scale is set to 0, the current temperature 11℃ is displayed as 51℉ and the current temperature 12℃ is displayed as 53℉ on the panel.

So I am assume that the scale/step is for converting C to F and vice versa? However, my heater is not capable of C, only F, so therefore no conversion or stepping should be necessary on the HASS side?

even in the own commit, this code:

if self._current_temperature.scale == 0 and self._current_temperature.step != 1:

If scale is 0 and step DOES NOT EQUAL 1, it does the multiplication, however based on my logs, my device is coming through with a step of 1, so it should not be doing the conversion.

heinoldenhuis commented 2 years ago

heinoldenhuis

As I understand the calculation would be as follows: (value * step) / (step * 10^scale) which for the example would be (2230 * 1) / (1 * 10^1) = 2230 / 10 = 223.0 volts

This is not correct
(value * step)        step * value         value
------------------ = --------------    =  ----------
(step * 10^scale)    step * 10^scale      10^scale
moreover, nowhere in the documentation is there a complete description of how to convert value to the correct temperature, only how to convert temperature to value value = temperature `step scale ^1- here is the first bug in documentation, because it should be 10^scale formulavalue = temperature step 10^scalecan be converted totemperature = value / step * 10^scale` unfortunately HA does something completely different.

You are right, the documentation is inclear. And indeed in my example step can be removed.

But where is declared that step should be used in the value calculation?

I have found some FAQ with an explanation (https://support.tuya.com/en/help/_detail/Kadi66s463e2q)

A device reports {"unit": "W","min":0,"max":50000,"scale":1,"step":1}. What do scale and step mean?

scale: indicates that the data value is converted to an exponent of 10 for transmission. For example, 1 indicates 10 to the first power, that is, divide the actual value by 10.

step: indicates increment between neighboring data values, which is also known as step size. For example, 1.

Then value = temperature * 10^scale and temperature = value / 10^scale. Example 205 will be 20,5. And the step used is for the value, but step_temperature = step / 10^scale. Example 205 will be lowered/increased by 5. And 20,5 will be lowered/increased by 0,5.

Also in the FAQ a link is given to the documentation which we earlier revert to.

Photogad commented 2 years ago

@heinoldenhuis

It's better to discuss this custom_component question somewhere else. This is not solving the actual problem.

I don't understand what custom_component is, I am new to the HASS ecosystem and the coding of it. I open this issue because my device was reporting wrong temperature in HASS and I was told to post device log, so that's what I did, post device log.

I have attached the tuya sources from HA version 2022.2.7, which can be extracted to your HA config folder tuya.zip

Thanks, you are a god. :))

frenck commented 2 years ago

Since devs here do not want to fix issue

Sorry, but that is just wrong an incorrect. Nobody ever said that.

The issue if finding the right solution. And honestly comments like those really don't motivate any dev ever.

I'm unsubscribing from this issue for now. I will send out a message to Tuya (as I mentioned before) and will pick up later again.

frenck commented 2 years ago

@heinoldenhuis please delete that comment and file. That is not a practice we want to promote as our project does not support that.

Thanks in advance.

heinoldenhuis commented 2 years ago

@heinoldenhuis please delete that comment and file. That is not a practice we want to promote as our project does not support that.

Thanks in advance.

@frenck I have deleted the comment and link. It was not my intention to promote this, only to temporarily run a previous working version.

For now I think enough is indeed said and thanks that you will contact Tuya. Hopefully the link I mentioned earlier in the FAQ on their site will help. Hope they will clarify how it should work.

starkillerOG commented 2 years ago

@frenck Tuya just updated there documentation after an engineer replayed to my question to clerify the example: See: https://developer.tuya.com/en/docs/iot/datatypedescription?id=K9i5ql2jo7j1k afbeelding

So in this new example it is very clear that the current HomeAssistant implementation is not in agreement with the documentation. Although I think the new documentation is even more stupid, since I think this will still leave it broken for everyone in this issue and will also brake it for most othe people....

frenck commented 2 years ago

@starkillerOG considering the original calculation in this integration was written by Tuya engineers (as in, the actual Python code), I feel like something is really off.

I will keep poking too, to find a more common ground in their own org.

starkillerOG commented 2 years ago

@frenck the 5^1 also makes just no sence at all, raising to the power of 1 does not do anything, never, and in the example the power 1 is hardcoded and not a variable, so this is cleary just wrong :)

heinoldenhuis commented 2 years ago

@frenck @starkillerOG Yesterday I also created a issue at the following screen.

I have mentioned here for a more usefull example, so with values like scale 2 and step 5. It's funny they used this exact values. Don't know if someone of you also mentioned these values...

It is good they have responded, but how they have changed the example makes no sense. Previously they used value 2230, step 1 and scale 1 = 223V and now 2230, step 2 and scale 5 is also 223V. Seems the current formule here is wrong, so this could not be correct.

I left my email for the issue, but did not receive any notification. Do you guys have direct contact with developers? Better to follow up there then reapply another document issue I think?

starkillerOG commented 2 years ago

@heinoldenhuis yes I have made a issue on the API, and I am in a conversation with a tuya engineer, but they are not beeing very carefull in there answers like

step, together with scale to determine the amount of data transmitted, step=1, scale=1, it means that the transmitted data is stepscale ^ 1=1(10 ^ 1)=10

Which is cleary not correct (they swiched around the scale^1 and 10^scale). But at least they respond fast, so that is good.

I think the conversion of the data and the minimum_step_value are beeing mixed up in the documentation. I think the correct conversion schould probably be: conversion=10^scale minimum_step_value=step/conversion=step/(10^scale) user_readable_value = value/conversion = value/(10^scale) However this is not what is currently beeing stated in the documentation. Hopefully I or @frenck get a clear answer from a tuya engineer that actually took the time and looked into what is actully the correct conversion instead of just refering to documentation that is at least not clear and possibly even wrong.

maxkrok commented 2 years ago

Hopefully I or @frenck get a clear answer from a tuya engineer that actually took the time and looked into what is actully the correct conversion

But if you understand the problem, why not to make a bug fix? What if tuya will not answer? Why we have to suffer, even having a solution?

starkillerOG commented 2 years ago

@maxkrok please understand that there are currently 16362 users of the Tuya integration. We can not be fixing your individual issue or my individual issue as that will break it for the other thousands of users. We need to find a way to fix it for everyone and not just an individual.

The first step is identifying what the correct way of converting these values is. Normally the "correct" way would simply be following the Tuya documentation, but in this particular case I am afraid the Tuya documentation is quite unclear and possibly even wrong. But in any way we first need to find out what the intended way for the conversion is. That will probably work for most of the users. For the users where this does not work, we need to look for a diffrent solution, logically the device is then not complying with the Tuya standards and a firmware upgrade of that device would be needed. If that proves to be impossible due to too much of these devices not complying, we could be looking for a diffrent solution like a configurable conversion, however as many have pointed out this is not possible in the current architecture of HomeAssistant. Only integration options are posible right now, we would need device specific options for this which is currently not possible in HomeAssistant. To realize that a architecture issue would need to be made, with a debate about what the proper way of designing such a thing would be. Then the core of HomeAssistant would need to be adjusted by someone and then the frontend schould also be updated to support this. That would be a very big effort that could take a lot of time and people willing to programm all of that in there free time (unpaid) would need to be found.

So to conclude, trust me, the easiest way to fix your issue @maxkrok will be to first figure out what the correct way of converting the values actually is.

maxkrok commented 2 years ago

Dear @starkillerOG

So to conclude, trust me, the easiest way to fix your issue @maxkrok will be to first figure out what the correct way of converting the values actually is.

I'm sorry, but i cannot agree with this. This may take a lot of time, as you told yourself. I have file "customize.yaml" and inside i have custom settings of my tuya climate devices as: climate.aaa1: max_temp: 30 climate.aaa2: max_temp: 30

I would never believe that there is no facility to include in this customization practice other parameters of tuya devices and apply some method to use dividers or multipliers for them... In this case any of 16362 users will be able to tune their HASS despite of endless misunderstanding with "tuya" stuff, which may not be finished for years... IMHO you and @frenck pay too much attention to some abstract algorithms an too little - for how to fix the situation... thank you

home-assistant / core

tuya thermostat Temperature still wrong after latest update #66853

The problem

What version of Home Assistant Core has the issue?

What was the last working version of Home Assistant Core?

What type of installation are you running?

Integration causing the issue

Link to integration documentation on our website

Diagnostics information

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

The current temperature can have a scale of 0 or 1 and is used for