core: tuya thermostat Temperature still wrong after latest update

I just made a PR to fix the scaling and make it in line with the current Tuya documentation: https://github.com/home-assistant/core/pull/69348

@frenck Tuya documentation still says step schould be removed since 23-02-2022. https://developer.tuya.com/en/docs/iot/datatypedescription?id=K9i5ql2jo7j1k#title-1-Example

Can I make a PR to remove the step from the calculation (how it used to be) untill you have time for a more permanent solution that works for everyone (probably a option per device I guess?) Or did you hear anything from the tuya devs?

Sounds like a plan. The example in the Tuya documentation doesn’t seem to include the step in the value calculation. The step only seems to be used as an indication of the increments in which the value can change.

@frenck Tuya documentation still says step schould be removed since 23-02-2022. https://developer.tuya.com/en/docs/iot/datatypedescription?id=K9i5ql2jo7j1k#title-1-Example

Can I make a PR to remove the step from the calculation (how it used to be) untill you have time for a more permanent solution that works for everyone (probably a option per device I guess?) Or did you hear anything from the tuya devs?

I think the point is that the step schould not be involved in the conversion factor.

Yeah, I think so too (guess). Until recently, the step has never been part of this. Nevertheless, they did adjust it and document it as well… (and while it broke stuff for some, it did fix it for a lot of others too…)

The documentation in the screenshot is still conflicting (it shows both step and scale being involved).

Whatever the right answer should be, based on diagnostic dumps I’ve collected: None of the suggested calculations or calculations I can come up with, will solve it for everybody.

This brings us back to the case: Manufacturers have customized their devices.

I’ve been fiddling a bit with our codebase yesterday, I think I might have a maintainable way to handle those cases, but that is definitely not for 2022.3.

Thanks @martin3000 for some reason I couldn’t get the custom component working but managed to update the installed extension.

Here’s the workaround I applied, as I see there’s quite a few people affected by this bug. This works for my Raspberry PI running HASSIO.

1. Install SSH & Web Terminal add-on
2. Disable “Protection mode” so you can access the host OS
3. Navigate to a home folder, in my case cd /home/hassio
4. Download the base.py from the docker container: docker cp homeassistant:/usr/src/homeassistant/homeassistant/components/tuya/base.py .
5. Edit the file using nano or vim, same as before the bug is on line 48 and you just need to delete: * self.step
6. Exit and save
7. Upload the file back into the container: ‘docker cp base.py homeassistant:/usr/src/homeassistant/homeassistant/components/tuya/base.py’
8. Restart HomeAssistant and the issue is fixed:

Note to the thread: Before you all rush to critizise the maintainers of the project, consider that the workaround depends on a plugin developed by the same guys you’re trolling, same as 99% of the code you use.

An additional note / ask to the maintainers: @frenck @zlinoliver @METISU

Personally I can’t thank you all enough for your work and passion you put into this, and I acknowledge that there’s been a fair bit of trolling and bad attitude / communication in this thread. I think we should all be more appreciative of the time and willingness to make HA happen, instead of glossing on an honest mistake caused by bad or non-existent documentation.

That being said I think it we’d all appreciate if we can just let this go and merge this into the project, as at this point I think it’s quite clear that this is a bugfix that is working for a lot of us, and the odds something else will break because of this are quite low now.

Thanks again for making HomeAssistant the awesome piece of software it is.

2022.3.8 - the problem is still relevant. So far, only editing the base.py file helps, but when updating, you have to edit it again. For noobs, like me: If you find def scale_value(self, value: float | int) -> float: in the components/tuya/base.py file change the line return value * self.step / (10**self.scale) to return value / (10 **self.scale) and restarting the kernel fixes it. base.py file is in components/tuya (not custom_components). You need to connect via SSH using WinSCP app and find the components folder, something like this: /var/lib/docker/overlay2/74cedd62125e06b9a4a2687706533768eb39d2eb457aa8f343676e36768ae327/merged/usr/src/homeassistant/homeassistant/components/tuya/base.py

I will not write, just watch . I will answer only if i will be asked for… bye

Guys, what and where should I write so that the temperature is simply divided by 5 until the bug is fixed? I’m already shaking from a temperature of 115 degrees.

@Santanachia Please don’t just ping for that stuff. If I had something to say I would say something. I don’t need to be polled. Thanks 👍

Maybe it is just me, but I can’t understand what Frenck is arguing about. I have two different brands of TRV’s installed in my house, and another brand at the office. They all were reporting the temperatures fine before 2.8. The devs then change it after tuya docs. After that, all my TRV’s are reporting 5x temperatures. And also, everybody here has the same problem. But I couldn’t find nobody reporting wrong tuya temperatures before 2.8. Frenck says that if he changes it back, everybody else will have problems but us. But wouldn’t logic dictate that everybody else would have to complain before 2.8 about wrong reported temperatures? Is anyone who has tuya TRV’s that report the correct temperature after 2.7?

IMHO you and @frenck pay too much attention to some abstract algorithms an too little - for how to fix the situation…

@maxkrok IMHO you are focussed on just resolving your own situation and honestly, I have absolutely zero interest in your case. Why? Because you have been pushing hard on just your use case.

Please note, Home Assistant is used by many, not just you. Sorry, we don’t jump into reverts, hacks, or other patchwork to fix your thermostat today.

Please have patience. If it is critical for your system, please roll back to a previous version until this has been resolved.

So, we are looking for a better solution overall, not just for you.

Thanks.

…/Frenck

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

They will do. There is no other desicion…

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.

Previously seemed it worked ok.

Definitely it was ok on 2.7 core version…

Guys, what and where should I write so that the temperature is simply divided by 5 until the bug is fixed? I’m already shaking from a temperature of 115 degrees.

I think the answer is in some religious field…

@iqueban

But I couldn’t find nobody reporting wrong tuya temperatures before 2.8.

I know about at least #57184 and #61876. I think I saw 10 or more issues related to the topic somewhere around the end of the last year.

Franck and the team do work with what they have and doing things according to the publicly available documentation is their best shot.

P.S. And yeah, 2022.2.8 has fixed my thermostat 😄

Well, I really am glad for you. How will you feel if the next update according to some revised tuya docs will break it again?

Both the issues you posted were about a broken functionality after update, but did not have anything to do with the specific problem that is being discussed. My thermostats for example, never reported the correct heating state and did not update automatically, but the temperature values were right when I triggered manual update. 2022.2.8 did fix the update problem and heating state reporting (which I was really happy to discover) but broke the temperature values. I really disapprove the way some complains were formulated here, but as someone pointed out earlier this discussion is not a philosopher’s lounge. People should be focused on getting some creative solution, because there are a lot of pretty inaccessible manufacturers which might not respect the tuya docs and contacting them for a fix would take until the end of time. It will take extra work and some time to do this and arguing about it doesn’t help. peace!

@starkillerOG I’m in direct contact with Tuya and will report back if I have clarity from their team and product manager(s). (The people that build the cloud API and originally build the initial integration).

@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.

I noticed that the values in the Tuya app are displayed correctly while in HomeAssistant since 2022.02.08 the values are 5x to high due to a apperently incorrect “step” value reported by the device (apperntly a firmware bug). Why are the values displayed correctly in the Tuya app?

The overlay displayed in the Tuya App can be customized by the manufacturer.

This also is visible with e.g., 2 bulb from different manufacturers being displayed differently.

could you possibly discuss the differnce between the API and the Tuya app with Tuya since you have contacts there?

Already answered that above.

Do you suggest breaking others to fix your use case specifically?

I do not think that someone has correct way of work of this topic. Even if someone does we do not have evidence of that or even if we have, then what is the ratio between who has working and who has broken functionality? If broken is for more people - then it is broken. Here I do not see anyone with working way…

Did anybody complaine on this topic before broken core 2.8 ??? Links? Proofs?

Why to break a working functionality and then gives big lectures about high matters? Please repair the broken logic, which we reported.

Thanks for confirming! Closing this issue from this end in that case 👍

My PR to fix the issue has been merged, so it will probably be resolved in 2022.05.

However note this it may cause issues for other users like the once using Moes thermostats. So some kind of per device configuration for this will probably still be nessesary.

I still feel there’s too much negativity in this post. If you put yourself in the maintaner’s position it’s not nice to work “for free” for people who don’t appreciate it and are jumping on the opportunity to single out your every mistake or bad judgment call.

Just saying, I I where in charge of this bug it would definitely be far down in my priority list, just to avoid dealing with the “attitude” in the thread.

Blocking the issue “out of spite” is not cool, but I kind of get it.

ATTENTION: An additonal note to other users that are about to do the same patch as me. I just run a pending update to Apr 20 version and the supervisor never rebooted. The website responds “CONNECTION REFUSED” and HA is completely offline for me. Careful with updates :octocat:

Probably something related to permissions when running the update, who knows.

I’m also having issue with a multiplier of 5, running 2022.3.1 check https://github.com/home-assistant/core/issues/67642

remove * self.scale from scale_value function.

I am sorry, where exactly I can find scale_value function? I would like to see correct temperature values (my wife complains) before it will be fixed officially… Thank you a lot…

not “* self_scale”, but “* self_step”

I’m sorry for interference… But where at files in HA is this file base.py which hase to be edited." Thank’s!

@iqueban

But I couldn’t find nobody reporting wrong tuya temperatures before 2.8.

I know about at least #57184 and #61876. I think I saw 10 or more issues related to the topic somewhere around the end of the last year.

Franck and the team do work with what they have and doing things according to the publicly available documentation is their best shot.

P.S. And yeah, 2022.2.8 has fixed my thermostat 😄

@frenck I agree that the above part about transferred data is still weird, did not notice that. I think the point is that the step schould not be involved in the conversion factor. step schould only be used to determine the minimum step size/increment the device can make. (in my case the thermostat can make 0.5 degrees steps when setting the temperature).

But it is all very unclear and confusing.

Let’s indeed just wait untill you get a response from people heigher up than the tuya engineers that actualy know what is going on.

@starkillerOG The revised documentation is making it worse actually:

@starkillerOG I’m not keen on changing anything until I have clarity from the development team and product manager(s) at this point. As I think we should avoid having this discussion ever again.

Let’s hold a bit.

(There is no patch release planned before 2022.3 drops, and this can be added/changed during beta, so there is no need to rush at this point either).

@starkillerOG

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.

But that’s what you’ve done in version 2022.2.8 - you’ve fixed it for some to break it for others. You don’t have statistics on how many people have the bug now and how many had it before, so you don’t know how many you fixed and how many you broke. Maybe it is as you say that you have broken a few, or maybe you have just broken thousands.

@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.

@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 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.

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 formula value = temperature * step * 10^scale can be converted to temperature = 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.

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.

@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). 🤷

@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.

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

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

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

Please, if your device is not functioning according to specification, contact Tuya.

it doesn’t work like that. From my experience so far I can say that Tuya will reply “API is only transmitting data from the device, contact the manufacturer” and the manufacturer will reply “it’s the device’s fault, please complain to the seller”. 😦

You are a representative of a large group. Could you please contact Tuya on behalf of all of us?

2022.2.7 worked correctly, 2022.2.9 works incorrectly.

That might be true, the other way around will be the case for many others. The calculation was incorrect, and we fixed that.

If your device worked because of a bug, that is unfortunate, but that is not something we do anything about 🤷

If your device is not working correctly, I recommend contacting Tuya (you can submit a support ticket when logged in into your Tuya IoT account). We cannot change your device.

Same problem here: 5x multiplication due to the “step”: 5 reported. status info in debug is correct (10x as specified by “scale”:1): from diagnostics:

    "status": {
      "switch": true,
      "temp_set": 100,
      "temp_current": 295,
      "mode_eco": true,
      "lock": false
    },

from diagnostics:

      "temp_current": {
        "type": "Integer",
        "value": {
          "unit": "\u00b0C",
          "min": 0,
          "max": 500,
          "scale": 1,
          "step": 5
        }
      },

while the status is 5x to high (from diagnostics):

         "state": {
            "entity_id": "climate.xxxxxxxx",
            "state": "heat",
            "attributes": {
              "hvac_modes": [
                "off",
                "heat"
              ],
              "min_temp": 25.0,
              "max_temp": 175.0,
              "target_temp_step": 0.5,
              "current_temperature": 147.5,
              "temperature": 50.0,
              "icon": "mdi:xxxxxxx",
              "friendly_name": "xxxxxxxxx",
              "supported_features": 1
            },

No update available for the device. Was working in HomeAssistant 2022.02.07, not working in 2022.02.08 and 2022.02.09

Previously seemed it worked ok.

Definitely it was ok on 2.7 core version…

You are correct, I have updated my comment. Tested both versions (2022.2.7 and 2022.2.8) as a custom component.

Hi all,

Seems I have also the same problem. Previously seemed it worked ok in version 2022.2.7. In 2022.2.8 and 2022.2.9 the Target temperature and Current temperature are 5 times higher then expected.

Please let me know if I could help.

@frenck in my OP screenshot you can see actual target temp is 65, but HASS reports 140. I don’t know where people are getting 5x multiplication from, this is 2.15x multiplication on my end unless I am misunderstanding.

Also, “actual temp” (reported by thermostat) is multiplying by 2.62x or something