Even if the TuyaMCU does try talking over the TX/RX, it looks like it would be fairly simple to temporarily disconnect the traces on the rear of the board that are going to U2 pins 13 & 14 (the MCU’s TX/RX connection). Could even just cut the 3.3v going to the rest of the board and/or the MCU itself @ pin 24, but not sure how much I like that method… either way, it’s a sure sight easier/faster to do this and then reverse it than to attempt removing and reinstalling the TYWE2S module. I plan to try flashing one later this evening if I get a chance.
I really suggest stepping up your soldering game. Seriously, it’s way easier to desolder it than to hack up the board you are proposing to.
I am using this cheap 858D hot air (around 30 bucks), a bit of patience and it goes out like it should.
That’s my after:
1 Like
First my soldering game is just fine, as I’m an Avionics Technician by profession, and have nearly 30 years electronics experience overall.
Second I don’t have to do this at all, as my Feit switches were flashed via Tuya-Convert long ago. I’m doing this because I’m working on another project that involves the TYWE2S module which cannot be as easily / safely removed without the higher end equipment that I have at work. Unfortunately bringing in things like this is strictly prohibited there, and I can’t remotely justify having my own variants for an occasional project like this. I have lots of these switches just sitting in a box (replaced majority of them with MJ dimmers), so this was something I could tinker with, tear apart, mill into, etc. at home, and not really care if I damaged it while doing so.
Lastly not everyone has the skill or know-how to do what was easy for you (or myself if needed) to do. Since finding that taking off the TYWE2S module covers was super easy (again it just pries right off with little effort, and doesn’t need to be desoldered itself), I thought I’d look into and share here a potentially less daunting method of flashing these dimmers. Removing the cover and disconnecting / reconnecting those 2 long isolated traces on the back of the board is not 'hacking up the board" IMHO. I’ve seen lots of people on here and other forums severely damage their smart devices (lifted pads, damaged traces, heat stressed components, etc.) while improperly attempting to desolder / resolder their ESP module. This on the other hand utilizes the 4 pin headers on the board, so the most difficult thing is having a steady hand to touch and ground out the GPIO0 pin on the ESP if you ask me. If doing the tiny bit of disconnecting and reconnecting 2 simple traces is too difficult for someone to do, what do you suppose is going to be the result of them attempting to remove and replace the TYWE2S module???
1 Like
Wow. I didn’t mean to offend you…
The job is easy, take hot air gun, 400 C temperature, make U shaped moves - focusing on ground plane (VCC, RX TX etc pins will heat up quickly, only back - GND, looks like mechanical bond - is what will hold you up) and just maybe a minute of patience - its done, you can lift it up, and work on BIG pads to solder wires for flashing. I have only limited experience doing reflow, no near professional experience, so I can say that it is easy. If you prefer to take of the shield (which is probably as hard as taking entire thing off) and then try super fine soldering job - its up to you. I am just trying to say that you all guys might be one little step before desoldering it like a pro ($30 hot air gun).
You didn’t really, but I did feel the need to set the record straight concerning my skills and why I’m proposing this method.
As for doing it my way, I finally had a free minute to do it today, and it works / flashes just fine. I can’t express how easy it is to remove the TYWE2S cover… seriously I can remove it faster than the time it takes for your heat gun to warm up. Also the 2 traces just need 1 trace just needs to be finely cut… nothing drastic that will require jumper wire, but that is an option if someone damages them. Here’s a couple pre, during, and post cuts on my board:
Updated pics to show single cut
That’s it. Scrape scrape, cut cut, flash, and solder solder… that’s all the “super fine soldering job” one needs to do. The hardest part, if you will, was holding my grounded test lead to the ESP’s pin 15 GPIO0 for a couple seconds. Again you’re just briefly touching a ground to the above pin during power on to get the ESP chip into flashing mode. You DO NOT need to solder anything to the ESP chip / TYWE2S module! If someone doesn’t have a fine point test lead (or can’t find it like my dumb butt couldn’t), you can make a very functional ghetto one with some fine wire, a sewing needle, and some electrical tape. Here’s a pic of that ghetto setup 
I do recommend a good magnifying visor, glass, or scope though as it is a pretty fine / small pin leg on the ESP chip. But that’s it… a couple seconds on the ESP pin while the Mrs. plugged in the USB, and it was Tasmotising away! 
Updated post to reflect single Tuya MCU TX to TYWE2S RX trace cut.
4 Likes
Just an update, but for those doing the flash via my solderless method (I honestly don’t count resoldering the 2 TuyaMCU traces ), please continue being gentle / careful in removing the TYWE2S module cover.
I’ve been partially using the above method to flash some Lohas Candelabra bulbs (a bulb that utilizes multiple solder points on the back of the module in addition to the bottom copper pads… makes it an absolute bear to remove without professional solder rework stations), and I inadvertently popped off the top left smd cap. Got absolutely lucky and found it still sitting on the board… it’s not much bigger than a grain of sand, and required painstaking patience to resolder properly. I can only assume I hit it with my scribe since it’s near the hole I use to start the lid removal. It is the only 1 out of 6 bulbs I’ve flashed so far that this has happened to. The only other issue that has occurred has been tiny bits of the copper ground layer sticking to / coming off with the lid solder points from time to time. Unless it tears into the circuit area of the module this isn’t a huge issue, and I only bothered repairing one that tore without completely tearing off from the board… and that was mostly to keep it from inadvertently touching something somehow and causing a short to ground.
Anyways, just wanted to point out those issues I’ve had so you don’t get too cocky like I started to and damage things.
1 Like
Does anyone know how to sync the 3-way status in tasmota? The switch with the load doesn’t update the switch at the end of the traveler, for some reason (works vise versa).
well, I am pretty sure that 3way is done in TuyaMCU, ergo its not a wifi chip job. Ergo you shouldn’t have any problem.
Are you using two of the Feit dimmers for your 3-way, or the Feit coupled with a non-smart switch? Either way double check your wiring, as the 3-way functionality is handled via the Tuya MCU as previously mentioned.
Turns out I just needed to do a power reset to get the MCUs to talk to each other. All good now!
1 Like
hah, typical day for esphome based dimmer! It loses sync with HA and stops to react to the commands… Reset helps
Thank you to everyone above and their efforts to get these dimmer running, as well as the pics and instructions. I’ve got a stack of these dimmers at home, and have started desoldering/flashing/resoldering the TY chips. I’m loading Tasmota 9.4.0 and I have one weird quirk with the operation.
If I send a MQTT packet to the dimmer under the “cmnd/dimmer” topic, i can make the brightness change easily. If the light is OFF (POWER = OFF reported in WebUI console & HA) and i send the packet to change the dimmer level, it reports back as “POWER = ON” as well as the correct dimming level. However, the lights don’t always actually turn on (Both the console logging AND HA show it as powered on). Sending a “POWER ON” command (either via console or MQTT) does in fact turn the lights on, at the previously sent dimmer level.
However, this isn’t predictable. Sometimes the lights will actually turn on.
Is anyone else experiencing this odd behaviour? I would like to the lights to remain off, as I’m simply trying to set the brightness for the next time it’s turned on, based on time of day. (ie dim at night, full bright during the day).
Is this a coding bug in tasmota, or is this behaviour the result of the TuyaMCU reacting to the dimmer command?
@Xplode
I have the same exact behavior “sometimes”. My homemade fix is to force two consecutive brightness commands that are very near and that increases the chance of it working almost 100% of the time.
For minimum brightness
ouvrirhalllow:
mode: restart
sequence:
- service: mqtt.publish
data:
topic: cmnd/Dimmer2/Dimmer
payload: 2
- delay: 00:00:01
- service: mqtt.publish
data:
topic: cmnd/Dimmer2/Dimmer
payload: 1
- delay: 00:00:01
- service: light.turn_on
data:
entity_id: light.dimmer2
I have 6 dimmers, three of which are non-dimmable led drivers and the other three are dimmable LED bulbs. I never had to do this workaround for the non-dimmable led drivers, and I had to do the above work around for the three other dimmable bulbs. I don’t know why; I haven’t investigated more than that since the workaround is enough for 99.9% of the time or so. In a year, maybe it failed to open once.
EDIT: Just re-read your message, and this is exactly what you’re trying to do: I also use “SetOption20 1”, if that matters. I do that because I want to set the brightness twice before actually opening the led bulb (I use motion detection to open lights, and I want to avoid firing up the LED 100% when it’s dark outside, so I set brightness to 1 and 2 twice, then issue a turn on command)
1 Like
Thanks for the reply. If I’m understanding your original comment correctly, you’re trying to reliably turn on the light? So I’ll skip that part.
However, the Setoption20 parameter seems to be EXACTLY what I am looking for. I will try it tonight and see if I get more predictable behaviour. Thank you! I’m honestly not sure how I missed that since I am using Setoption19 in my gear. You’d think I’d have seen that next line down!
Ok I just fired up the Setoption20 “ON” for one of the dimmers and it doesn’t seem to turn on now when I send MQTT commands from HA dashboard. The tasmota result doesn’t show “POWER = ON” like it used to either (it showed on, but only actually turned on soooometimes).
But now the buttons in HA are broken - they don’t turn the lights on anymore. So I messed around with it and then turned off Setoption19 (Auto-discovery) and then turned it back on again. Annoyingly it created a new entity with the same name but “_2” added to the end. However, it now appears to turn on/off when commanded, as well as I can change the dimmer level in the background.
So THANK YOU FOR TIP! I had stalled out on this project and wasn’t sure about installing more of these if I couldn’t control them as I wanted. So Thank you again!
Next task is figuring out groups so I can do 3-way dimmers and have physical dimming control from both switch locations.
1 Like
sorry whats the reason for cutting that trace and soldering again?
Also, I flashed one already and connects while using the usb adapter. However, the status led continues to blink. Should it be fine once I install it into the wall?
To make sure that other MCU does not interfere with your flashing. It’s connected to the same pins, and uses that to send control commands.
Okay cool. Well the flash worked so I guess I did it right. Hopefully my newbie solder job worked after.
So right now the only thing that doesnt seem is when I manually adjust the dimmer on the switch it doesnt report that back to HA.
When I change the dimmer from HA I get these unknown messages in the log even though I see the status lights move.
[17:18:36][C][tuya:030]: Configuration will be reported when setup is complete. Current init_state: 0
[17:18:36][C][tuya:031]: If no further output is received, confirm that this is a supported Tuya device.
[17:18:38][V][tuya:349]: Sending Tuya: CMD=0x00 VERSION=0 DATA=[(0)] INIT_STATE=0
[17:18:52][W][api.connection:078]: ESPHome Logs 2021.9.1 (10.0.0.30): Connection reset
[17:18:52][V][api:107]: Removing connection to ESPHome Logs 2021.9.1 (10.0.0.30)
[17:18:53][V][tuya:349]: Sending Tuya: CMD=0x00 VERSION=0 DATA=[(0)] INIT_STATE=0
[17:18:58][D][light:035]: 'livingroom_light' Setting:
[17:18:58][D][light:050]: Brightness: 72%
[17:18:58][D][tuya:499]: Setting datapoint 2 to 721
[17:18:58][W][tuya:502]: Setting unknown datapoint 2
[17:18:58][V][tuya:349]: Sending Tuya: CMD=0x06 VERSION=0 DATA=[02.02.00.04.00.00.02.D1 (8)] INIT_STATE=0
[17:18:58][D][tuya:499]: Setting datapoint 1 to 1
[17:18:58][W][tuya:502]: Setting unknown datapoint 1
[17:18:58][V][tuya:349]: Sending Tuya: CMD=0x06 VERSION=0 DATA=[01.01.00.01.01 (5)] INIT_STATE=0
Figured there was an issue with tx from the cut. Tried repairing it and now the manual dimmer buttons dont work. So im thinking it totally messed this one up
Make sure when you re-soldered the TX line back together that you are not accidentally soldering it to the ground plane (i.e. the larger copper areas outside of the traces. It doesn’t quite sound like the case, but I’d double check it with a multimeter to verify you don’t have a short if you’re still having weird problems. As for your dimmer buttons not talking to HA, that sounds like firmware setup issue. From your log it looks like you’re using ESPHome, which I don’t personally use anymore due to occasional communication / heartbeat drop outs. Read through the first few months of this post for proper ESPHome setup, as in those days Tasmota had its own communication issue, so ESPHome was what most of us were using to get some resemblance of functionality.
1 Like