TuyaMCU to 2 wifi interfaces?

ESPHome
1

Is it possible to connect tuyaMCU RX TX to two separate wifi interfaces - ie. one for esphome and other (with realy to tun it off from esphome) original tuya as piggyback?

This way I could have local control and at the same time, if i wish, original tuya controls too.

2

No, the ESPHome firmware wipes out & replaces the Tuya firmware.

If you want local control while still using the Tuya firmware, look into custom integrations on HACS like localTuya & TuyaLocal. Maybe one of those allows local + cloud access.

3

Just a quick question - do you know what tuyaMCU is?

4

Literally an MCU made by Tuya

1 Like
5

Supposedly it is possible like this, at least that is best LLM answer I got.

esphome:
  name: tuya_dual_link
  
esp32:
  board: esp32dev

# 1. Disable UART Logging (Free up UART0 if needed, though we use UART1/2 here)
logger:
  baud_rate: 0
  level: DEBUG

# 2. Define the 3 UART Interfaces
uart:
  # UART A: The "Official" connection for ESPHome Component
  - id: main_mcu_bus
    tx_pin: GPIO17
    rx_pin: GPIO16
    baud_rate: 9600

  # UART B: Connection to the Original Tuya Module
  - id: orig_mod_bus
    tx_pin: GPIO25
    rx_pin: GPIO33
    baud_rate: 9600

  # UART C: The "Spy" - Just listens to what the MCU says
  - id: spy_bus
    rx_pin: GPIO32
    # No TX needed, this is a passive ear
    baud_rate: 9600

# 3. The Tuya Component (Standard)
# It thinks it has full control. It reads from GPIO16.
tuya:
  id: tuya_mcu
  uart_id: main_mcu_bus
  # Set status_interval high (e.g. 1min) to reduce collision risk with Original Chip
  # The Original Chip will handle the frequent polling.
  status_interval: 60s 

# 4. The Proxy Logic (Corrected)
interval:
  - interval: 1ms
    then:
      - lambda: |-
          // PATH 1: Original Chip -> TuyaMCU
          // We read from the Original Module and inject it into the MCU line.
          // We check if the MCU line is busy to avoid crashing packets.
          if (id(orig_mod_bus).available()) {
             while (id(orig_mod_bus).available()) {
               char c = id(orig_mod_bus).read();
               id(main_mcu_bus).write(c);
             }
          }

          // PATH 2: TuyaMCU -> Original Chip (The Return Path)
          // CRITICAL FIX: We read from the "Spy" bus (UART C), NOT the main bus.
          // This leaves the data on the main bus for the Tuya Component to read.
          while (id(spy_bus).available()) {
            char c = id(spy_bus).read();
            id(orig_mod_bus).write(c);
          }

I do thing that the lambda stuff will need a lot of fixing.

But maybe it can help someone who is looking into the same/similar thing to perfect the LLM output into actual working solution.

This way ESPHOME act ast proxy for tuya module, to communicate with tuyaMCU and supposedly it should also handle the collisions and heartbeats.

Another LLM kept kept pushing for 74HC4052 or 74HC4053 - but I think it does not get what simultaneous usage means :slight_smile:

6

It’s against forum rules to help others with LLM output… :wink:

2 Likes
7

I don’t think it is meant that way and without correctly flagging it as such, but point taken.

Probably not many people interested in this solution anyway.

8

You mean like the serial output of the MCU to be piggybacked onto two seperate ESP style WiFi boards? Im assuming you do not want to interfere in the functioning or reprogram the MCU itself.

As well as interference from two antennas at close proximity using similar frequencies, the UART output from the MCU is probably expecting some handshake or response from the WiFi module, which often just simply is acting in UART style passthrough mode. Unless the other one was in pure benign vampire mode, they would clash and confuse the MCU.

Try it. Connect a serial port to USB adapter (like the one you use for flashing) and run a terminal program on your computer. See what happens. Watch the two way traffic on the TX/RX pins. Your serial cable is acting the part of your second WiFi module. This setup is often used for reverse engineering where decoding commands and responses often is done unencrypted on the serial link on the board. Change one thing, observe the conversation. Change another and see again. Soon a pattern emerges that you can duplicate in your own code.

Making a backup of your original firmware so you can reflash the ESP device might be what you are looking for, giving you the flexibility to swap to ESPHome as you wish, but not causing confusion.

Take a step back. What are you sensing? What are you controlling? Can ESPHome in conjunction with HomeAssistant solve the problem? If not, why?

Not sure I understand your use-case requirements. What are you specifically trying to do that requires this duality?

What specific Tuya device are you trying to monitor and modify?

9

Don’t worry, I’m not about to flag your post… But seriously, it’s likely getting tighter in near future to keep the forum for human members helping human members…
At year 2050 I would probably be flagged to be AI racist :wink:

10

The Daleks will be out, chanting in unison: Exterminate, exterminate…

AI and LLMs are often confused. We are at the bleeding edge of a rapidly advancing technology, and the teething problems are showing. Particularly embarrassingly so in the HomeAssistant field with open source, weekly updates, and constant changes that they fail to keep up with. Hopefully by 2050 the AI learning algorithms will have considerably improved, testing, matching, sifting, and weighing before regurgitating their slop. We will have learned to use it as an adjunct, a tool, rather than a guru to be blindly followed, being bitten often enough to be wary and untrusting.

11

I have exactly this scenario on my to-do list, reverse engineering a MCU equipped Tuya device to crack the code, and monitor chatter on the serial port. Won’t be using a spare ESP module like you are proposing however. Not sure if I will find time these holidays, but I will be watching your progress.