TuyaMCU: handle WIFI_SELECT / WIFI_RESET without soft-locking MCU #24063
+23
−3
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
… MCU pairing logic When WIFI_SELECT or WIFI_RESET is received, this sends a WIFI_STATE ramp 0x00/0x01 up to 0x05 to simulate successful WiFi connection up to 'cloud connected' to exit pairing mode and reallow Tasmota control of the MCU
…into development
eku
reviewed
Oct 26, 2025
Co-authored-by: Erik Kunze <eku@users.noreply.github.com>
Owner
|
Will fix asap. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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.
Description:
If an MCU initiated WiFi reset is carried out on some Tuya devices, the MCU will not respond to any commands from Tasmota until it has determined a cloud connection has been established. This also occurs during initial setup of the device. At present, Tasmota will reset the WiFi settings, but doesn't give the MCU the status updates it expects, essentially soft locking it.
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 Tasmota. Without this, the device can be stuck and essentially becomes 'listen only'. We then continue with the existing functionality of resetting the current Tasmota WiFi settings.
As well as properly handling the WiFi reset procedure, this allows for initial setup to be done without ever having to connect to a Tuya server.
I've tested this on two YH002 blind motors (module swapped WBR3 to ESP-12S) - one previously used, one brand new out of the box. Both working fine. I've been unable to test with an ESP32 device as I haven't got any.
Related issue (if applicable):
I never formally created an issue, but my comment on this page explains the initial issue.
Basically, 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 Tasmota, and would only report changes in position that were initiated by button presses on the unit itself.
I saw a post suggesting ESPhome may have handled this situation so moved these across to that in hope, however that didn't work for me either, so I delved deeper to fix the underlying issue. I've already had a PR merged for the same for ESPhome here, I felt it made sense to try and implement a fix here too.
Checklist:
NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass