tuya thermostat Temperature still wrong after latest update

[Photogad]

The problem

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

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

[probot-home-assistant]

tuya documentation
tuya source
_{^{(message by IssueLinks)}}

[probot-home-assistant]

Hey there @tuya, @zlinoliver, @METISU, @frenck, mind taking a look at this issue as it has been labeled with an integration (tuya) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[nelsonamen]

[Photogad]

I suppose here is problem? Also it should be heat only, not heat_cool.

"entity_id": "climate.garage_tower_heater", "state": "off", "attributes": { "hvac_modes": [ "off", "heat_cool" ], "min_temp": 140, "max_temp": 187, "target_temp_step": 1.0, "swing_modes": [ "off", "on" ], "current_temperature": 115, "temperature": 140,

[Neowonder-cell]

The same problem here. The target temperature multiplied by 5 after upgrading to 2022.2.9 (It was multiplied by 10 after upgrading to 2022.2.8)

[RaJeronimo]

Still multiplied by 5 for target temp in update 2022.2.9
Magnum floor thermostat

Device Information
Product Name
ET_8A
Device ID
...
Product Category
wk

debugging screen in tuya iot says 150 ( 15 ℃)

Strange thing is the status section in HA integration diagnostics is correct:

        },
        "status": {
          "mode": "hot",
          "temp_set": 150,
          "temp_current": 170,
          "c_f": "C"

[maxkrok]

Yes.. i confirm the same.. but it is not "temperature" it is "target temperature" problem

[frenck]

@maxkrok so it is not the same?

[maxkrok]

@maxkrok so it is not the same?

Not the same comparing to the title of issue. But the same with people are reporting on their screenshots

[Photogad]

@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

[Photogad]

Please note that this don't affect all Tuya based heater. I have two of them (one is a HeatStorm brand, the other Atomi brand). The HeatStorm brand one reports correctly in HASS.

[nelsonamen]

tuya-fa17395f972aa0ee64ede486a79f3c48-Termostato Garza-ee2253b3cdee89dc8ed1239296740616.json.txt
18 C is 90 C....

[maxkrok]

I don't know where people are getting 5x multiplication from

I have 5x multiplication..
My thermo valve target temp is 20 С and in HASS it is shown as 100 C... 100/20=5
This is happening after 2.8 core update and on 2.9 is still broken...

23,5 is current temperature

[heinoldenhuis]

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.

[maxkrok]

Previously seemed it worked ok.

Definitely it was ok on 2.7 core version..

[heinoldenhuis]

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.

[iqueban]

Hi! I just upgraded from 2021.12.10 to 2.9 and I have the same problem

[johnvanderster]

Here the same. 2.7 okay, 2.8 and 2.9 not anymore. I had to upgrade because of SamsungTV token update

[starkillerOG]

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

[Santanachia]

@frenck, you wrote:

Reason for this change complying with Tuya's official documented sources.

2022.2.7 worked (and still works) correctly
2022.2.9 works wrong

So it is not a change on Tuya's side that causes the error.

[frenck]

I wrote a bit more, did you read it?

Tuya updated the documentation, which I linked as part of the comment you are only partially quoting; Our previous implementation was incorrect. We now comply.

Do you think our implementation is incorrect? Could you point out the part of the logic that isn't correct in that case?

Please note, Tuya sells chips and software products, manufacturers can customize those. We do not (and cannot at this time) support that. If your product doesn't work as specified by Tuya (and thus is customized by the manufacturer), there is not much we can do.

[maxkrok]

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

[Santanachia]

I read the rest of what you wrote and looked at the documentation. Unfortunately this documentation does not match the reality. You can see it well at iot.tuya.com

temp_current = 190 (19°C)
temp_set = 170 (17°C)

[frenck]

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

Sorry, that doesn't sound reasonable and oddly demanding in many ways. Do you suggest breaking others to fix your use case specifically?

I think it makes way more sense Home Assistant to follow the standard, so most things just work as expected.

Anyways, I'm happy to see a contribution that fixes it for all cases.

[frenck]

I read the rest of what you wrote and looked at the documentation. Unfortunately this documentation does not match the reality. You can see it well at iot.tuya.com

That would in that case be a manufacturer-specific implementation. If you provide the diagnostics file, I'm happy to show you the calculation and why your device is probably not working according to standards set by Tuya (not Home Assistant).

[Santanachia]

@frenck I have attached the file in the issue you closed.

I am perfectly aware of where the values presented come from, I can apply the formula you indicated, but I emphasize: 2022.2.7 worked correctly, 2022.2.9 works incorrectly. The only place where there has been a change is in the HA code.

[frenck]

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.

[starkillerOG]

I just made a PR to fix the scaling and make it in line with the current Tuya documentation: #69348

[Santanachia]

@starkillerOG hopefully @frenck will accept it for version 2022.4

[maxkrok]

@starkillerOG hopefully @frenck will accept it for version 2022.4

let us pray to Holy Tuya and His prophet comrade @frenck

[martin3000]

@frenck

feel free to check the documentation here on how the calculation works: https://developer.tuya.com/en/docs/iot/datatypedescription?id=K9i5ql2jo7j1k#title-1-Example

I checked this example and it is easy to understand and it is logically.
Given these properties: {“unit”:“V”, “min”:0, “max”:5000, “scale”:2, “step”:5}
the value {"cur_voltage": 2230} becomes 2230/(10^2)= 22.3V

[maxkrok]

@frenck checkmate...

[Santanachia]

@maxkrok He knows this, but is unable to accept the fact that he made a mistake (through no fault of his own, because the earlier description was very inaccurate).
There is a fix ready from @starkillerOG but @frenck is blocking it :(

[maxkrok]

@Santanachia then we have to vote to disqualify this person..

[Santanachia]

@maxkrok No. He created a lot of great code. This is the only place someone besides him should be concerned. But who do we report it to? How?

[martin3000]

You can copy the tuya component into a custom component, fix the code and use it as a custom component.

[maxkrok]

@maxkrok No. He created a lot of great code. This is the only place someone besides him should be concerned. But who do we report it to? How?
Ok . He did a great work.. but now why the whole world should depend on his droit de veto ?

[Santanachia]

@martin3000 Why are you suggesting that we should accept the fact that there is a bug when there is a fix ready for it?
You can fix this for many people with just one click.

[martin3000]

I fixed it already for my HA instance....I do not wait.

[MrEcosse]

I have exactly the same issue on various Tuya stats from different manufacturers. The issue is quite obvious any stat that has a resolution (step) of 0.5C reports incorrectly as 5 times the actual value. This is because of the faulty logic in the way the value is being calculated by home assistant. I have some stats where only the room temperature is reported to 0.5C so in this case the set point is correct but the room temperature is wrong. On others both set point and room temperature are wrong.

As no one is reporting a problem before this logic was introduced it beggars belief that it hasn't been resolved.

[nachobazz]

@martin3000 while we wait for this patch to be merged can you share instructions on how to replace the buggy production integration with a custom one?

So far I have:

• Downloaded the Source code from here: https://github.com/home-assistant/core
• Isolated the /homeassistant/components/tuya/
• Modified base.py line Number 48 from this: return value * self.step / (10**self.scale) to this return value / (10**self.scale)
• Enabled samba addon
• Uploaded /tuya/ folder into /config/custom_components
• Disabled and removed tuya integration
• Rebooted HA

After reboot the integration is not listed in HACS and adding and configuring the regular integration via the "integrations" frontend still shows the bug. Can you provide directions on how to enable the custom integration?

[martin3000]

@nachobazz what you have done looks good, I don't know what it is missing. You could try to rename the folder from "tuya" to "tuya3" and also change the name in "manifest.json" to tuya3.

[Santanachia]

@nachobazz I think you are missing one step - in manifest.json you should change the version

[nachobazz]

I renamed the folder to tuya3 and my manifest looks like this:

{ "domain": "tuya", "name": "Tuya3", "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*" } ], "loggers": ["tuya_iot"] }

Screenshot attached for additional context below.

After rebooting I don't see another custom integration available in hacs, and the integrations list offers the regular "tuya". I tried setting that one up in the event it's been over-ridden, but the enabled integration is still the cloud one with the bug.

Any ideas?

[martin3000]

There is no relation between the HA community store HACS and the custom_components folder. You don't have any custom components?

[nachobazz]

@martin3000 OK, definitely a gap in my understanding of custom components, my bad.

This is what my custom_components folder looks like.

All the ones except for the tuya one where generated by HACS, so I assumed a manually installed component would be managed by HACS as well.

Am I missing any steps to configure the custom_component after restart? Maybe I need to put a configuration key in configuration.yaml?

Thanks for your invaluable help.

[martin3000]

maybe you have to configure tuya3 in the configuration.yaml:

tuya3:
  username: !secret tuya_user
  password: !secret tuya_pass
  country_code: de
  platform: smart_life

if you have access to your HA machine, you could modify the original base.py which is in ????/python3.9/site-packages/homeassistant/components/tuya/base.py
Of course this only works until the next update.

[nachobazz]

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.

[Santanachia]

@nachobazz I mostly agree. But this isn't about trolling, or the bug in the code itself, it's about the persistence in blocking the possibility of fixing the code.

[nachobazz]

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

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

[starkillerOG]

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.

[Santanachia]

2022.5.0b1 have it fixed

[nelsonamen]

Beta channel Works!!! 😁👍

[frenck]

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