tuya: handle WIFI_SELECT and WIFI_RESET #10822
Merged
+29
−4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…E queries If WiFi reset is carried out on some Tuya devices, they will not respond to any commands from ESPhome until the MCU has determined a connection has established. ESPhome does not currently handle WIFI_SELECT or WIFI_RESET. Add ACK for WIFI_SELECT and WIFI_RESET from MCU. Following a WIFI_SELECT or WIFI_RESET from the MCU, it will send WIFI_STATE to determine the WiFi status. This will correctly reply in the following way with the relevant delays to simulate an actual connection in progress:- <300ms -> 0x00 (pairing/EZ) <900ms -> 0x02 (configured, not connected) <1500ms -> 0x03 (router connected) >=1500ms-> 0x04 (cloud connected) If a subsequent WIFI_STATE is received, it will only reply with 0x04 (cloud connected)
Remembers when we last received WIFI_SELECT so we can "ramp" WIFI_STATE replies.
…TATE Creates wifi_select_seen_ which is set true upon receiving WIFI_SELECT after MCU initiates WiFi reset procedure. Once correct response is sent to WIFI_STATE implying connection to Tuya servers is successful, wifi_select_seen_ is set false.
This reverts commit 19366a6.
If an MCU initiated WiFi reset is carried out on some Tuya devices, they will not respond to any commands from ESPhome until the MCU has determined a connection has established. This also occurs during initial setup of the device. ESPhome does not currently handle WIFI_SELECT or WIFI_RESET. This will initially ACK the WIFI_RESET/WIFI_SELECT by sending a WIFI_STATE with an empty payload. It then establishes the pairing mode from the received WIFI_RESET/WIFI_SELECT (0x00 = EZ mode, 0x01 = AP mode) WIFI_STATEs are then sent to simulate the process of establishing a connection to Tuya servers, in the following order. 0x00 (Entered EZ pairing mode) or 0x01 (Entered AP pairing mode) 0x02 (Configured, but not connected) 0x03 (Router connected) 0x04 (Cloud connected) Upon completion, the MCU is satisfied that a connection is established, and will allow control of the MCU via esphome. WIthout this, the device can be stuck and essentially becomes 'listen only'.
If an MCU initiated WiFi reset is carried out on some Tuya devices, they will not respond to any commands from ESPhome until the MCU has determined a connection has established. This also occurs during initial setup of the device. ESPhome does not currently handle WIFI_SELECT or WIFI_RESET. This will initially ACK the WIFI_RESET/WIFI_SELECT by sending a WIFI_STATE with an empty payload. It then establishes the pairing mode from the received WIFI_RESET/WIFI_SELECT (0x00 = EZ mode, 0x01 = AP mode) WIFI_STATEs are then sent to simulate the process of establishing a connection to Tuya servers, in the following order. 0x00 (Entered EZ pairing mode) or 0x01 (Entered AP pairing mode) 0x02 (Configured, but not connected) 0x03 (Router connected) 0x04 (Cloud connected) Upon completion, the MCU is satisfied that a connection is established, and will allow control of the MCU via esphome. WIthout this, the device can be stuck and essentially becomes 'listen only'.
If an MCU initiated WiFi reset is carried out on some Tuya devices, they will not respond to any commands from ESPhome until the MCU has determined a connection has established. This also occurs during initial setup of the device. ESPhome does not currently handle WIFI_SELECT or WIFI_RESET. This will initially ACK the WIFI_RESET/WIFI_SELECT by sending a WIFI_STATE with an empty payload. It then establishes the pairing mode from the received WIFI_RESET/WIFI_SELECT (0x00 = EZ mode, 0x01 = AP mode) WIFI_STATEs are then sent to simulate the process of establishing a connection to Tuya servers, in the following order. 0x00 (Entered EZ pairing mode) or 0x01 (Entered AP pairing mode) 0x02 (Configured, but not connected) 0x03 (Router connected) 0x04 (Cloud connected) Upon completion, the MCU is satisfied that a connection is established, and will allow control of the MCU via esphome. WIthout this, the device can be stuck and essentially becomes 'listen only'.
Contributor
|
To use the changes from this PR as an external component, add the following to your ESPHome configuration YAML file: external_components:
- source: github://pr#10822
components: [tuya]
refresh: 1h(Added by the PR bot) |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #10822 +/- ##
=======================================
Coverage 68.76% 68.76%
=======================================
Files 52 52
Lines 10689 10689
Branches 1437 1437
=======================================
Hits 7350 7350
Misses 2958 2958
Partials 381 381 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
jesserockz
approved these changes
Sep 22, 2025
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this implement/fix?
If an MCU initiated WiFi reset is carried out on some Tuya devices, the MCU will not respond to any commands from ESPHome until it has determined a cloud connection has been established. This also occurs during initial setup of the device. ESPHome does not currently handle WIFI_SELECT or WIFI_RESET.
This will initially ACK the WIFI_RESET/WIFI_SELECT by sending a WIFI_STATE with an empty payload.
It then establishes the requested pairing mode from the received WIFI_RESET/WIFI_SELECT (0x00 = EZ mode, 0x01 = AP mode)
WIFI_STATEs are then sent to simulate the process of establishing a connection to Tuya servers, in the following order.
0x00 (Entered EZ pairing mode) or 0x01 (Entered AP pairing mode)
0x02 (Configured, but not connected)
0x03 (Router connected)
0x04 (Cloud connected)
Upon completion, the MCU is satisfied that a connection is established, and will allow control of the MCU via ESPHome. WIthout this, the device can be stuck and essentially becomes 'listen only'.
Types of changes
Related issue or feature (if applicable):
This is an issue that I've personally had for a long time. My 5 year old pressed some buttons on my Zemismart YH002 blind motor which started the WiFi reset procedure, and the device stopped responding to all commands from ESPHome. Others have had similar issues , however the listed fix (initiate WiFi reset) doesn't work for me, it appears later versions of the MCU require a satisfactory response before allowing commands to be executed, and will only report changes in state otherwise.
As well as handling the WiFi reset procedure, this allows for initial setup to be done without ever having to connect to a Tuya server.
Pull request in esphome-docs with documentation (if applicable):
Not applicable
Test Environment
Example entry for
config.yaml:Not applicable
Checklist:
tests/folder).Tested locally on various Zemismart YH002 devices, I have no other Tuya devices to try. My YH002s have had the WBR3 modules replaced with ESP-12S if that's relevant. These devices only send a WIFI_SELECT rather than a WIFI_RESET, however, the Tuya documentation suggests the required responses are identical.
If user exposed functionality or configuration variables are added/changed:
Not applicable
This is the first contribution I've ever made, and first pull request I've ever submitted (long time lurker) - so please go easy on me if I've done something incorrectly!