Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Multiple issues with AC #306

Closed
1 of 3 tasks
Andrei-Iosifescu123 opened this issue Jul 13, 2024 · 14 comments
Closed
1 of 3 tasks

[Bug]: Multiple issues with AC #306

Andrei-Iosifescu123 opened this issue Jul 13, 2024 · 14 comments
Labels
bug Something isn't working stale

Comments

@Andrei-Iosifescu123
Copy link

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?
  • 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.
    Screenshot_20240713_093857_io homeassistant companion android
  2. Sometimes when trying to control the target temperature it shows negative numbers.
    Screenshot_20240713_093924_io homeassistant companion android
  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.
    Screenshot_20240713_095126_com termux
    Screenshot_20240713_095215_io homeassistant companion android

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

@Andrei-Iosifescu123 Andrei-Iosifescu123 added the bug Something isn't working label Jul 13, 2024
@xZetsubou
Copy link
Owner

xZetsubou commented Jul 15, 2024

Does these spikes always happen before/after disconnects?

@Andrei-Iosifescu123
Copy link
Author

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link
Owner

xZetsubou commented Jul 24, 2024

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)

@Andrei-Iosifescu123
Copy link
Author

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.

Copy link

github-actions bot commented Aug 8, 2024

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.

@github-actions github-actions bot added the stale label Aug 8, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working stale
Projects
None yet
Development

No branches or pull requests

3 participants