Tuya MCU Low-Power Wifi mode (protocol 0) support

[agittins]

Component name

tuya

Link to component documentation on our website

https://esphome.io/components/tuya/

Describe the enhancement

The Tuya MCU component currently implements the Tuya MCU Standard Protocol, Wi-Fi or Wi-Fi and Bluetooth combo protocol.

Other protocols are supported by the Tuya MCU specification, such as:

• MCU Standard Protocol Low Power Wifi, Wifi Power-Off https://developer.tuya.com/en/docs/mcu-standard-protocol/mcusdk-wifi-lowpower-powerdown?id=Kdpxm74got3pq
• MCU Standard Protocol Low Power WiFi, Wifi keep-alive
  • this appears to be the same as the wifi or wifi and bluetooth combo protocol, but the MCU uses an IO pin to wake the wifi module when it has operations to do.
• Others such as BLE, Bluetooth Mesh, Zigbee, PLC and more, all found in the nav menu of the pages linked above.

This FR is to modify the existing Tuya-MCU component to support specifically the Wi-Fi Power-Off protocol.

Given the range of protocols supported, I suggest a new configuration key be added, something like protocol: which would default to the existing "Wifi or Wifi and Bluetooth combo" version perhaps as wifi_ble_combo, and can be set to the new protocol variants as they are developed, such as wifi_poweroff.

This setting would alter the flow of communication to suit, and change how the different commands are treated for each version (although I suspect that the combination of command_id/version might be enough for that distinction).

It's worth noting that the main difference with the wifi power-off protocol is that the mcu keeps the wifi module powered off most of the time, but when something needs doing, it powers it on, performs comms and expects to power it off again in short order (unless an update is being performed etc).

Particular support is desired to also perform updates via a user-defined method (such as sending ESPNow packets, BLE or serial etc) rather than actually progressing through the full Wifi, api/mqtt etc init processes.

Use cases

I have a box full of Lenovo SE-741M Motion Sensors that have a PIR sensor, custom MCU and an esp8266-based tuya TYWE3S module.

The factory firmware is woeful because it requires the device to make a cloud mqtt connection to report every motion event, which is slow and wastes battery power (hence why I could buy a box of them for $4 each).

I would like to flash ESPHome on the wifi module so that immediately on power-up, it would talk to the mcu to gather the datapoints, then immediately broadcast the data via ESPNow (on my pre-defined wifi channels), then go to sleep.

I should be able to do this by implementing the tuya component and performing lambdas on the on_datapoint or similar events, and possibly by having to tweak the startup priority of different components etc.

At the other end, I currently have esp32 bluetooth proxies that I have also configured as sort of "espnow proxies", by having them relay any received espnow broadcasts to HA via the event bus. This end of it seems to work quite well, so far.

Anything else?

No response

[github-actions[bot]]

🏷️ I've automatically added the component: tuya label to help categorize this feature request.

[agittins]

I'd be willing to work on a PR to make this happen, but I'll probably need some hand-holding as my C-fu is not strong, and also I'd need to get a good idea of where the appetite is for the implementation and direction to take it (ie, if it should be an extension of the existing tuya component, or if there should be a new component created for each variation etc).

Maybe it comes down to whether one uses ifdefs to reduce the resulting compiled size or if using separate components is preferred, even if it results in code duplication. 🤷🏼‍♀️ - did I mention my c-fu is weak? :-)

Some super-helpful prior art exists in @brandond's https://github.com/brandond/esphome-tuya_pir solution, which uses the old uart.h custom_component method to implement their reverse-engineered solution.

Brandond has expressed some interest in possibly implementing the code into core if that was a desired thing, but I don't know if their availability or motivation persists - but the custom_component method now being removed means their solution no longer works without some manual intervention.