TheEebb
commented
3 years ago The fix for the Feit dimmer is as follows:
- Don't mangle communications. That means wait for a response before sending another command. By default Tasmota doesn't wait. It continues to send commands expecting either the companion MCU to queue them or to simply drop them. This leads to an inconsistent state between the Tuya device and the MCU. In my implementation I added a queue to allow for async communication. Of course a simple fix would be to either block or discard commands until the last command is completed.
- Send acks when the protocol in the official Tuya MCU document says so and wait for responses as dictated.
- Start communication by sending nothing but zeros. MCU expects the lines to be pulled low for a certain amount of time before the start of communication. I am unsure if this is specific to the device used-- does it reset it? does it flush the comm buffer? does it allow the comm lines to settle? Since I don't have the details on how it was implemented and also not wanting to spend time reverse engineering the hw I'm simply going to leave it as it works; but its a more educated guess than empirically derived solution.
That's basically it. I haven't had time to merge my work with mainline since I added too much to it. My implementation is extensible for other Tuya devices-- potential future proofing. But I doesn't look like that will happen since Tuya is branching out to SoCs that are currently not supported by Tasmota.
EDIT: I want to clarify start of communication means when the device is reset/initialized and begins first communication with the MCU. Basically any time a known state between Tuya and MCU has not been established.
beren12
Hi @TheEebb
Thanks for all the hard work you put into this. I've been running this on 2 of my Feit Dimmers for a few days without a failure to respond after many many failures running ESPHome.
Since your commit was the entire source code of Tasmota I'm having a really hard time understanding what is it you changed that fixed the communication lockup. Any chance you can help point me to the section that was modified to better understand what was done to fix this?
There is a separate effort to fix this as part of ESPHome tuya: Use queue for sending command messages and it would be great to see if the two solutions are similar.