DPS update speed

[myhomeiot]

Thanks for great integration!

I'm thinking to move few my devices from localtuya integration. Everything works much better with your integration but I found that localtuya integration updates device dps much faster. For example if I turn on/off or change target temperature of my dehumidifier using Tuya mobile application, or PM25 sensor was updated, the localtuya integration get the new data almost instantly in your integration it's takes around 20-25 seconds. Can you explain this? Is it possible to make this faster?

[make-all]

I have not looked closely at how localtuya is handling updates, but they have their own forked version of pytuya which they have customised themselves (this integration is using tinytuya, which is another derivative of the original pytuya). There are a couple of things that might improve the speed

1. as an early design decision, the upstream developer (nicole-ashley/homeassistant-goldair-climate) chose to poll the devices rather than use a persistent connection to allow co-existence of the mobile app and home assistant. Co-existence doesn't really work that well, since the app doesn't similarly co-operate, so a persistent connection might help. Though I did try it once, and any improvement didn't seem to be automatic, since the poll commands still need to be sent over the persistent connection, but it allow the poll rate to be increased without overloading the tuya device.
2. Tuya devices send out broadcast messages. I have thought about using these for discovery, but I suspect that they may also help with getting push updates from the device without polling.

[myhomeiot]

Thanks for explanation, polling explains the slow updates.

About co-existence with Tuya mobile app, I know from the forum that many Tuya compatible bulbs can handle only one connection but fortunately for me all my Tuya device can handle more than one connection and I doesn't have this problems and unfortunately I can't test this case.

[fabianluque]

I second this request. I have a fan I have configured that definitely updates instantly under Local Tuya and takes a little longer with this integration.

Another issue I’m experiencing that might be related is that a quick succession of commands like turn on/off a light sometimes results in some of them to be delayed.

[make-all]

It seems the way that localtuya does it is to use a persistent connection with asyncio, but it isn't as simple as making the connection persistent, the way the connection is handled also needs to change. tinytuya has added support for persistent connections, so refactoring device.py to use it should give a big improvement to update speed for external status changes, though it still probably will not be sufficient to support battery powered sensors.

[Fannangir]

@make-all, just updated to the new version. When I control the switch from HA, no issues. When I use the switch (simple_switch) physically, it updates HA after about 2-3 minutes.

Tested with Local Tuya (@rospogrigio rospogrigio), works as expected in both ways (reacts immediately <1sec.

I believe the issue became worse, in previous version it was updating faster (about 30 sec.).

[make-all]

Can you please look in the log for any messages from tuya-local.

[make-all]

I have released 2023.1.2 based on my investigation into how my protocol version 3.1 device is working when set to "auto" protocol detection.

[Fannangir]

Just updated to 2023.1.2. It s better, usually synchronized with the switch immediately, but occasionally losses sync. Meaning, I turn off from the switch (physically), but the status in HA is still on (happens occasionally. There is nothing in the log (it is clear).

The log from the integration switch: { "home_assistant": { "installation_type": "Home Assistant OS", "version": "2023.1.5", "dev": false, "hassio": true, "virtualenv": false, "python_version": "3.10.7", "docker": true, "arch": "x86_64", "timezone": "Asia/Jerusalem", "os_name": "Linux", "os_version": "5.15.80", "supervisor": "2022.12.1", "host_os": "Home Assistant OS 9.4", "docker_version": "20.10.19", "chassis": "vm", "run_as_root": true }, "custom_components": { "smartthinq_sensors": { "version": "0.29.3", "requirements": [ "pycountry>=20.7.3", "xmltodict>=0.12.0", "cchardet>=2.1.7" ] }, "sonoff": { "version": "3.3.1", "requirements": [ "pycryptodome>=3.6.6" ] }, "nuki_ng": { "version": "0.2.1", "requirements": [] }, "adaptive_lighting": { "version": "1.4.1", "requirements": [] }, "mass": { "version": "2022.12.1", "requirements": [ "music-assistant==1.8.7.2", "git+https://github.com/music-assistant/databases@fix-breaking-sqlalchemy-cursor-changes#databases==0.6.3" ] }, "powercalc": { "version": "v1.3.0", "requirements": [ "numpy>=1.21.1" ] }, "huawei_mesh_router": { "version": "0.8.4.1", "requirements": [] }, "citymind_water_meter": { "version": "2.0.10", "requirements": [] }, "circadian_lighting": { "version": "2.1.3", "requirements": [] }, "hacs": { "version": "1.29.1", "requirements": [ "aiogithubapi>=22.10.1" ] }, "alarmo": { "version": "v1.9.7", "requirements": [] }, "xiaomi_cloud_map_extractor": { "version": "v2.2.0", "requirements": [ "pillow", "pybase64", "python-miio", "requests", "pycryptodome" ] }, "ramzor_sensor": { "version": "0.1.0", "requirements": [] }, "scheduler": { "version": "v0.0.0", "requirements": [] }, "webrtc": { "version": "v2.3.1", "requirements": [] }, "ui_lovelace_minimalist": { "version": "v1.1.6", "requirements": [ "aiofiles==0.8.0", "aiogithubapi>=22.2.4" ] }, "browser_mod": { "version": "2.2.0", "requirements": [] }, "hebcal": { "version": "2.0.9", "requirements": [] }, "localtuya": { "version": "5.0.0", "requirements": [] }, "iphonedetect": { "version": "1.4.0", "requirements": [] }, "simpleicons": { "version": "v2.2.0", "requirements": [ "simpleicons==7.14.0" ] }, "shelly": { "version": "1.0.2", "requirements": [ "pyShelly==1.0.2", "paho-mqtt==1.6.1", "websocket-client" ] }, "reolink_dev": { "version": "0.61", "requirements": [ "reolink==0.0.64", "aiosmtpd>=1.4.2" ] }, "ytube_music_player": { "version": "20220205.01", "requirements": [ "ytmusicapi==0.24.0", "pytube==10.5.1", "integrationhelper==0.2.2" ] }, "miwifi": { "version": "2.9.0", "requirements": [] }, "tuya_local": { "version": "2022.1.2", "requirements": [ "pycryptodome~=3.16.0", "tinytuya==1.9.1" ] }, "smartir": { "version": "1.17.6", "requirements": [ "aiofiles==0.6.0" ] } }, "integration_manifest": { "domain": "tuya_local", "iot_class": "local_push", "integration_type": "device", "name": "Tuya Local", "version": "2022.1.2", "documentation": "https://github.com/make-all/tuya-local", "issue_tracker": "https://github.com/make-all/tuya-local/issues", "dependencies": [], "codeowners": [ "@make-all" ], "requirements": [ "pycryptodome~=3.16.0", "tinytuya==1.9.1" ], "config_flow": true, "is_built_in": false }, "data": { "name": "Shelter Room Light", "type": "simple_switch", "device_id": "REDACTED", "local_key": "REDACTED", "host": "REDACTED", "protocol_version": "auto", "api_version_set": 3.3, "api_version_used": 3.3, "api_working": true, "status": {}, "cached_state": { "updated_at": 1673985828.14835, "1": false }, "pending_state": {}, "connected": true, "home_assistant": { "name": "Shelter Room Light", "name_by_user": null, "disabled": false, "disabled_by": null, "entities": [ { "disabled": false, "disabled_by": null, "entity_category": null, "device_class": null, "original_device_class": "switch", "icon": null, "unit_of_measurement": null, "state": { "entity_id": "switch.shelter_light_master", "state": "off", "attributes": { "device_class": "switch", "friendly_name": "Shelter Room Light" }, "last_changed": "2023-01-17T20:03:48.148645+00:00", "last_updated": "2023-01-17T20:03:48.148645+00:00" } } ] } } }

[make-all]

I would suggest switching protocol version to 3.3. With it set to "auto", if the device starts giving errors or refusing connections for some reason, the auto protocol detection will trigger, which will delay the reconnection as it tries the different protocol versions. In particular, trying version 3.2 seems to take a long time to fail. I find with my devices, even when they do not respond right away because of errors, they are back around 5 seconds later with the protocol version set to a fixed version.

[make-all]

And when you "turn off from the switch", do you mean a switch on the device itself, or are you killing the power with an external switch (which would send the device completely offline and unable to communicate the state change).

[Fannangir]

I am talking about switching on and off from the touch button on the switch (switch power is not cut, always powered). I have tried to set to version 3.3 manually. Hard to tell whether I see a difference, as I don't think that the device disconnects (there is no message of device became unavailable in the logs. I have simply tried to turn on/off the switch about 20 times. It seems like it is synchronized about 17-18 times out of 20, which is actually not perfect but not bad either, which could be the fact that setting 3.3 manually did help. Thank you very much for your hard work supporting the issue.

[make-all]

I tried this myself, and after 35 attempts, finally got a delay of 2s to reflect the state when tinytuya got an invalid response from the device immediately after the switch. It seems I am unable to reproduce any substantial issue, so any additional info you can gather would help (maybe by setting the log level for custom_components/tuya_local/device, or tinytuya to debug).

[Fannangir]

As a simple test, I have tested for two switches which are synchronized as a master/slave (used in a hall to switch the same light from two places). It losses synchronization after the second/third switch of any of the two switches. Both are 3.3. To provide a log, could you please instruct me how to enable the logging in the logger(what exactly should be used)?

[make-all]

logger:
  default: warning
  logs:
    custom_components.tuya_local.device: debug

[Fannangir]

Thanks, Just adding the switch to test, enabled the logger. In the meanwhile, I have found another bug, less critical. I have, by mistake, chosen 3.2 instead of 3.3 as the protocol. The integration is stuck on the add screen without timeout or any error, you have to cancel manually and start over adding the device.

[Fannangir]

OK, enabled the logs, the issue still persists, occasionally, the switch state change isn't caught by the HA state. I press the touch switch, it changes state to off (physical switch), the light connected physically to the switch turns off, and the LED of the switch is off, but HA state is on. The log is clean, nothing caught. Is there anything else I can enable to debug so it could catch additional debug info?

[Fannangir]

By the way, another observation I could see, this is how the log of the switch looks like:

We can see that it skips a change (there are missing on/off switches between the states). There are multiple ONs and OFFs, when we expect to see on>off>on>off.... Another case could be that it reads the same state twice (just a guess).

[make-all]

You said you had two switches linked. Is the syncing of switch states also causing the command to be sent twice to the light? I don't think it will cause any problems, as long as the light itself is able to handle it.

[Fannangir]

I have unlinked it, as I can’t control the light. As the slave switch doesn’t receive the off command from the master switch (we see ON and ON again, no OFF), the slave switch stays on. So I am not sure what would be the reason. It might be that the OFF is interpreted as ON, or it is double ON, or it simply misses the toggled state. Till this morning, after about 12 hours, the log has no Tuya local messages.