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]: Can't add Wi-Fi T&H sensor (but could before) #191

Closed
2 of 3 tasks
Lurker00 opened this issue Apr 3, 2024 · 18 comments
Closed
2 of 3 tasks

[Bug]: Can't add Wi-Fi T&H sensor (but could before) #191

Lurker00 opened this issue Apr 3, 2024 · 18 comments
Labels
bug Something isn't working

Comments

@Lurker00
Copy link

Lurker00 commented Apr 3, 2024

LocalTuya Version

3.2.5.1

Home Assistant Version

2024.03.1

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?

I have a Wi-Fi T&H sensor. It is low power device, but, unlike written in FAQ, it reports its status whenever it wants (temperature, or humidity, or battery level, changed) and never does it periodically. It can be several times per minute, or after some hours. The rest of the time it sleeps.

In 3.2.5, I was able to add it with manual DPS's list. Then I changed "Device sleep time" to 21600 seconds (6 hours), to prevent periodical "Unknown" states and holes in the graphs.

Today I've deleted it and tried to add again with DPS=0, as you suggested for BLE bulbs in issue #190 (and I succeeded for bulbs!). The attempt with the sensor failed with a message "An unknown error occurred. [Errno 113] Connect call failed ('192.168.0.37', 6668)." But now the same message appears if I want to add it as before, with the real list of DPS's.

So, it seems a change in 3.2.5.1 broke this feature for Wi-Fi low power devices! As I understand, with a list of DPS's, or with 0 as the list, the integration should not even try to connect to the device being added. It still works this way for BLE bulbs.

I tried to roll back to 3.2.5, but HACS does not allow me to choose an older version: when I choose it from the list, it reverts the selection back to the currently installed version. So, I can't strictly confirm that I succeeded in 3.2.5 not by a lucky chance.

Steps to reproduce.

Try to add a Wi-Fi T&H sensor like mine.

Relevant log output

There is nothing in the system log related to this problem.

Diagnostics information.

The diagnostics file was taken right before I've deleted the sensor.
localtuya-944c1616039a1d1ec6b9745179bff74e-ГС_ T&H Сенсор-db4dcba3127fbe2f04514f763aa33397.json

@Lurker00 Lurker00 added the bug Something isn't working label Apr 3, 2024
@xZetsubou
Copy link
Owner

xZetsubou commented Apr 3, 2024

It was bugged before it ignored the whole connection process, but now it doesn't connect to the non online devices.

"0" skips the handshake, not the whole connection process. The handshake is the device is supposed to be reachable, but it doesn't have to wait for return status.

The reason I fixed this it was that users were putting anything in manual dps, not only 0, and would let them succeed to add the device even tho device isn't connected. This caused many non-sense issues

However, I'll make an exception for low-power devices to ignore the connection process.

@Lurker00
Copy link
Author

Lurker00 commented Apr 3, 2024

Thanks for confirmation! I hope it will work again soon.

But please also consider to do something to not even try to connect to such a device, and keep the last known values of its properties without a need to fool the integration with big device sleep time values. But I can live even with as it was day before yesterday 😄

@xZetsubou
Copy link
Owner

But please also consider to do something to not even try to connect to such a device

What do you mean I may misunderstand :)

The last values will be cached for the amount of time sets in device sleep time.

xZetsubou added a commit that referenced this issue Apr 4, 2024
* Fix error if brightness is not defiend
* Allow low-power device to connect while it sleep.
* Restore old states if 0 in manual dps.
* Diagnostics Obfuscate private data.
@xZetsubou xZetsubou added the master/next-release Fixed in master branch, Will be ready in the next release label Apr 4, 2024
@Lurker00
Copy link
Author

Lurker00 commented Apr 5, 2024

I just installed 3.2.5.1b1 to test the fix, but the T&H Sensor and the other WiFi low power device (scene switch) disappeared from the "Choose device to configure" list! Another not added device ("Wired Zigbee gateway") is still in the list.

If I download diagnostics from LocalTuya screen, I see both devices in the "cloud_devices" list.

It is expected behavior and, unlike before, I shall "Add Device Manualy"?

OK, I tried to add the T&H Sensor manually, set 0 for "Manual DPS's", 21600 for "Device sleep time", and it works. But is it how it is supposed to be now?

@Lurker00
Copy link
Author

Lurker00 commented Apr 5, 2024

I think I realized that LocalTuya had no IP addresses of the devices right after the restart, and that's the reason why it didn't list low power WiFi devices. It should list them after an event with their ID come through.

Am I right?

Edit: Yes, it works this way! But I'd prefer such devices to be listed to Add and then fill in IP address only, rather than fill Name/ID/key etc.

@Lurker00
Copy link
Author

Lurker00 commented Apr 5, 2024

Not that good as before with T&H Sensor: "Discover device entities automatically" works, but

  1. It sets scales for temperature and humidity to 0.01, while they shall be 0.1 and 1 correspondingly.
  2. It does not show humidity and battery level anymore. Temperature is OK.

@xZetsubou
Copy link
Owner

xZetsubou commented Apr 5, 2024

The reason your devices doesn't shows up is that localtuya scan the local network and the devices is self reports there present!. an example or device reporting it persent

Discovered device: {'ip': '192.168.1.101', 'gwId': 'bfa2f86e3068440a449dhd', 'active': 2, 'ablilty': 0, 'encrypt': True, 'productKey': 'jzmy5ut0vishwscm', 'version': '3.3'}

The reason they doesn't shows up instantly it's because they are sleep so you will need to wait for them to wake up at least once to show up. there's a tip as well that even if device isn't showing as long you insert the ID correct it will shows an error but then it will fix the other field for you.

an example :)

fields auto-correction

It sets scales for temperature and humidity to 0.01, while they shall be 0.1 and 1 correspondingly

This bug caused probably weeks ago I just noticed it. The scale value isn't pulling from cloud. I fixed it on master.

@Lurker00
Copy link
Author

Lurker00 commented Apr 5, 2024

Thanks for explanations and the fix!

Good news is that Humidity finally appeared, and I hope the Battery one day will appear too. It's strange that, according to Tuya logs, the sensor was sending both temperature and humidity, and even once - the battery level, but the temperature appeared from the first time, while humidity only on the second time. Weird, but now they are in sync.

So, I believe this ticket can be closed :)

@Lurker00
Copy link
Author

Lurker00 commented Apr 9, 2024

I thought LocalTuya should not try to connect to a low power device like this T&H Sensor. But I just enabled logging, and I see several lines like this:

2024-04-09 22:17:31.531 DEBUG (MainThread) [custom_components.localtuya.common] [bf9...qv2] Trying to connect to 192.168.0.37...

Why does it try to connect to a device known as never responding? Yes, it has "Device sleep time" set to 86400.

@xZetsubou
Copy link
Owner

It does re-connect every 5-seconds, all the devices do that. However, sleep time is the duration during which, if the device hasn't connected successfully, entities will shut down, and even pending status will reset.

@Lurker00
Copy link
Author

OK, now I better understand how it should work, but I see it works not as expected.

The current state on the Overview for Humidity value is "Unknown". The details show: updated 38 seconds ago, and Attributes/raw state is 36. The log records:

2024-04-10 12:58:36.376 DEBUG (MainThread) [custom_components.localtuya.sensor] [bf9...qv2] Entity Temperature - Additional attributes: {'raw_state': 27.3}
2024-04-10 12:58:36.376 DEBUG (MainThread) [custom_components.localtuya.sensor] [bf9...qv2] Entity Humidity - Additional attributes: {'raw_state': 37.0}
2024-04-10 12:58:36.376 DEBUG (MainThread) [custom_components.localtuya.sensor] [bf9...qv2] Entity Battery - Additional attributes: {'raw_state': 98.0}

2024-04-10 13:54:36.487 DEBUG (MainThread) [custom_components.localtuya.sensor] [bf9...qv2] Entity Temperature - Additional attributes: {'raw_state': '27.3'}
2024-04-10 13:54:36.487 DEBUG (MainThread) [custom_components.localtuya.sensor] [bf9...qv2] Entity Humidity - Additional attributes: {'raw_state': 37.0}
2024-04-10 13:54:36.487 DEBUG (MainThread) [custom_components.localtuya.sensor] [bf9...qv2] Entity Battery - Additional attributes: {'raw_state': 98.0}

2024-04-10 13:58:46.190 DEBUG (MainThread) [custom_components.localtuya.sensor] [bf9...qv2] Entity Temperature - Additional attrbutes: {'raw_state': 27.2}
2024-04-10 13:58:46.190 DEBUG (MainThread) [custom_components.localtuya.sensor] [bf9...qv2] Entity Humidity - Additional attributes: {'raw_state': 36.0}
2024-04-10 13:58:46.191 DEBUG (MainThread) [custom_components.localtuya.sensor] [bf9...qv2] Entity Battery - Additional attributes: {'raw_state': 100.0}

While I was writing this, the Humidity updated to 36%.

The "Device sleep time" is 86400 seconds. Why it showed "Unknown" for the humidity, if there were updates 4 minutes ago, and hour before, and the correct value for Temperature at the same time? I expect it to show the last available value at least 86400 seconds old, meaning, never "Unknown" after the first reading and with such data in the log.

@Lurker00
Copy link
Author

It seems that if the new value of a sensor is the same as the current one, it is not set, and the "time counter" (Device sleep time) is not reset.

Right now I see Humidity was updated 1 hour ago, Temperature was updated some minutes ago. In the corresponding payloads, Humidity was the same value.

@Lurker00
Copy link
Author

Created #199 about values from the sensor are not updated. The sensor itself works correctly, so the issue in the title was resolved.

@alx-pl
Copy link

alx-pl commented Apr 24, 2024

Well, there is a series of WiFi devices, in particular AVATTO WT198 thermostat

https://pl.aliexpress.com/item/1005005829037258.html

that can hardly be added when connection through the port 6668 is required. They seem not to be low power devices. Maybe there should be some way to add such without this initial connection

@open1999
Copy link

Hello,

the same difficulties with WIFI temperature and humidity sensor.

I looked at the network frames with tcpdump.

In fact the sensor cuts off its network interface and turns it on when the temperature or humidity is changed.

See image (HA on network 10, 192.168.10.18; sensor in VLAN50 192.168.50.31).

HA sends a message to 6668 the sensor does not respond (same with ARP or ping).

If the temperature or humidity changes the sensor wakes up and sends a message to "....eu-central-1.compute.amazonaws.com.https" and it can respond to Local Tuya.

After a few seconds the sensor turns its network off.

TCPDUMP sensor

To register the sensor in Local Tuya:
1/ I configure the sensor on Tuya Smart
2/ in Local Tuya I enter the informations
3/ I remove and replace the battery to wake up the network.

Version Local Tuya 3.2.5.1

@Lurker00
Copy link
Author

the same difficulties with WIFI temperature and humidity sensor.

Go to Reconfigure the sensor, put 0 to Manual DPS's, put 86400 to Device sleep timeout, an then it should work.

Version Local Tuya 3.2.5.1

I suggest to update to the latest 3.2.5.2 beta, because many bugs were fixed.

@open1999
Copy link

ok

Copy link

This issue was closed because it was resolved on the release:

@github-actions github-actions bot added stale and removed master/next-release Fixed in master branch, Will be ready in the next release stale labels May 26, 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
Projects
None yet
Development

No branches or pull requests

4 participants