[Bug]: Multiple issues with AC

[Andrei-Iosifescu123]

LocalTuya Version

3.3

Home Assistant Version

2024.3.3

Environment

• [ ] Does the device work using the Home Assistant Tuya Cloud component?
• [ ] Is this device connected to another local integration, including Home Assistant and any other tools?
• [X] The devices are within the same HA subnet, and they get discovered automatically when I add them

What happened?

1. Sometimes there are temperature spikes of the current temperature, it goes to 60 degrees C then back to normal.
2. Sometimes when trying to control the target temperature it shows negative numbers.
3. It goes unavailable and then returns online within a few seconds, doing this many times a day. It might have to do with the high packet loss and high ping, but the Wi-Fi signal is good and I don't see what could be causing it.

Steps to reproduce.

1. Wait some time, you will see temperature spikes on the graph
2. Try controlling the temperature, it will go from 0 degrees backwards as you decrease the temperature
3. Check the device logs

Relevant log output

Logger: custom_components.localtuya.coordinator
Source: custom_components/localtuya/core/pytuya/__init__.py:300
integration: Local Tuya (documentation, issues)
First occurred: 12 iulie 2024 la 18:40:29 (88 occurrences)
Last logged: 08:47:21

[bf6...ctg - HomeWhiz Smart AC] Handshake with 192.168.0.247 failed: Command 10 timed out waiting for sequence number 1
[bf6...ctg - HomeWhiz Smart AC] Connection failed: [Errno 113] Host is unreachable ('192.168.0.247', '6668')

Diagnostics information.

localtuya-580c1451b8388cced57e61b0e87a7960-HomeWhiz Smart AC-a6c2e3d665717bf38586e7e6222a9bb9.json

[xZetsubou]

Does these spikes always happen before/after disconnects?

[Andrei-Iosifescu123]

Does these spikes always happen before/after disconnects?

They happen regardless of disconnects. And also I figured out the disconnects were a network issue, so had nothing to do with this integration. However the temperature spikes continue happening at random times.

[xZetsubou]

I know that. However, the reason that I asked is that because there is a check for target temperature that if it's in Fahrenheit to force Celsius which is why you get that spikes not sure what triggers it for so I assumed that the sensor being unavailable may have something to do with I'll double check it.

can you enable the debug for both Integration and Device, and when spikes happen, copy all the logs and pase it here.

[Andrei-Iosifescu123]

I know that. However, the reason that I asked is that because there is a check for target temperature that if it's in Fahrenheit to force Celsius which is why you get that spikes not sure what triggers it for so I assumed that the sensor being unavailable may have something to do with I'll double check it.

can you enable the debug for both Integration and Device, and when spikes happen, copy all the logs and pase it here.

Thanks, I will do it. Also, the disconnects seem to happen even when it does not actually go offline (Tuya device logs don't report offline but HA does). Maybe increase the timeout for marking the device as unavailable (something like if the device can't be pinged for 10 seconds make it unavailable)

[xZetsubou]

What actually happen that when the HA disconnects from the device, it will try to reconnect if the reconnect hasn't been success within 3 seconds it will tell that the device disconnected otherwise will not, if there is something occurs within reconnect process it may reports "failed to connect" instead of "disconnected". however without logs we can't be sure the warning should reports in HA if you searched for "tuya" in logs but the data info happen between localtuya/device will be logged in debug level.

[Lurker00]

Pardon for jumping in!

@Andrei-Iosifescu123 FYI, from my experience, every smart device that shall send data to Tuya cloud, misbehave if it can't do it. The more data the device has to send, the more often such problems arise.

There are different reasons of inability to send data to the cloud: weak WiFi signal, ISP problem, cloud itself problem etc.

The misbehavior includes disconnects from Local Tuya and reject of new connects, inability to perform an action, reboot of its CPU, send invalid data or even damaged payloads. Tuya cloud does not report such a device as offline because it does not try to connect to it, nor it expects any data every short period of time. Tuya cloud just happy with whatever the device finally sends.

the Wi-Fi signal is good

How do you measure it? Most of WiFi devices report the signal level to the cloud and can be found in your Tuya developer account, in device log, e.g.:

signal intensity:-60||Remaining memory:39680||UTC:1721127245||DST:1721127245

Also note, that high humidity may lead to high RF signal loss. E.g. some of my WiFi and Zigbee devices work stable under 40%, and very unstable over 60%.

[Andrei-Iosifescu123]

Pardon for jumping in!

@Andrei-Iosifescu123 FYI, from my experience, every smart device that shall send data to Tuya cloud, misbehave if it can't do it. The more data the device has to send, the more often such problems arise.

There are different reasons of inability to send data to the cloud: weak WiFi signal, ISP problem, cloud itself problem etc.

The misbehavior includes disconnects from Local Tuya and reject of new connects, inability to perform an action, reboot of its CPU, send invalid data or even damaged payloads. Tuya cloud does not report such a device as offline because it does not try to connect to it, nor it expects any data every short period of time. Tuya cloud just happy with whatever the device finally sends.

the Wi-Fi signal is good

How do you measure it? Most of WiFi devices report the signal level to the cloud and can be found in your Tuya developer account, in device log, e.g.:

signal intensity:-60||Remaining memory:39680||UTC:1721127245||DST:1721127245

Also note, that high humidity may lead to high RF signal loss. E.g. some of my WiFi and Zigbee devices work stable under 40%, and very unstable over 60%.

The RSSI is around -60. I'm also seeing these temperature spikes on the tuya device logs (cloud) so I'm not sure it's a local tuya problem. I will try getting the AC fixed as it's still in warranty period.

[Lurker00]

The RSSI is around -60

Exactly as in my example above, taken from that WiFi plug, which disconnects or even reboots due to inability to send its data to the cloud. It is weak connection for such devices. They have low power CPU with very small amount of RAM (note 39680 of remaining memory in my log record!) to implement full featured TCP stack. For them, good is -50 and above.

It is not LocalTuya problem.

[Andrei-Iosifescu123]

The RSSI is around -60

Exactly as in my example above, taken from that WiFi plug, which disconnects or even reboots due to inability to send its data to the cloud. It is weak connection for such devices. They have low power CPU with very small amount of RAM (note 39680 of remaining memory in my log record!) to implement full featured TCP stack. For them, good is -50 and above.

It is not LocalTuya problem.

Right now the RSSI is -56, it even goes to -51, I doubt it's a signal problem. Maybe for the disconnects, but what about the temperature spikes? These can't be caused by a poor connection.

[Lurker00]

what about the temperature spikes?

If you see them in Tuya logs as well, why do you ask here? 😉

LocalTuya shows whatever data devices send. If you can show the difference between data sent by the device and shown by LocalTuya, that would be the question. If you enable debug logs, you'll see JSON payloads from the device.

[Andrei-Iosifescu123]

what about the temperature spikes?

If you see them in Tuya logs as well, why do you ask here? 😉

LocalTuya shows whatever data devices send. If you can show the difference between data sent by the device and shown by LocalTuya, that would be the question. If you enable debug logs, you'll see JSON payloads from the device.

Yeah, maybe it is a hardware problem after all. The only thing that does not appear in tuya logs but appears in local tuya is the negative temperatures when trying to set the target temp. Reloading the integration fixes it.

[xZetsubou]

It's not device issue it's most likely localtuya issue.

The reason that I asked you to provide the logs when it goes negative it's because localtuya converted the "target temperature" to Celsius, This happen if localtuya detects that target temperature is reported as Fahrenheit and current temperature reported as Celsius.

And I wanted to know why it converted the value for you. it should converted if the difference between current temperature and target temperature more then 160%.

So if the current temperature reported as 24 and then it should only convert target temperature to Celsius if target reports that it's higher then 60.

So can you post the logs for the status that device reports when it spikes. https://github.com/xZetsubou/hass-localtuya/issues/306#issuecomment-2229996293

[Andrei-Iosifescu123]

It's not device issue it's most likely localtuya issue.

The reason that I asked you to provide the logs when it goes negative it's because localtuya converted the "target temperature" to Celsius, This happen if localtuya detects that target temperature is reported as Fahrenheit and current temperature reported as Celsius.

And I wanted to know why it converted the value for you. it should converted if the difference between current temperature and target temperature more then 160%.

So if the current temperature reported as 24 and then it should only convert target temperature to Celsius if target reports that it's higher then 60.

So can you post the logs for the status that device reports when it spikes. #306 (comment)

It hasn't happened for some days, I'll see if it happens again.

[github-actions[bot]]

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days.