Proposal for tcMenu remote control using a 2nd embedded target fitted with switches, encoders, and an LCD for an ergonomic UI

[AtmosphEng]

Hi Dave and co.,
I have a feature request which would allow a kind of embedControl functionality but running on a 2nd dedicated wired or wireless target device. My project devices are usually ESP32-WROOM and/or ESP32-S3. I've already mentioned to you this functionality a while back as an unofficial hack. However this has actually been tested and is available now if two (identical or similar) target devices are programmed with the same tcMenu tree with tcMenuDesigner Generated Code, and IOT remote control is set to e.g. Serial2 on both target devices.

If both target devices (say device-A and device-B) are now connected with a cross-over (x-over) cable (i.e. TxA to RxB, and TxB to RxA) then one or both target devices can control their own tcMenu-A and the other target tcMenu-B interchangeably. I've tested this at 115200-8-n-1. The advantage of this simple interconnection is that it allows the embedded tcMenu rendering of device-B to be almost obtained almost for 'free' after the device-A code is working as expected on its own. The remote control is now possible without requiring embedControl to be installed on a separate host.

In addition to the wired x-over above, I've recently done some extra wireless testing with this Serial x-over method with good success too. To achieve this I've added two more devices each with Serial2 ports and programmed them to act as a transparent wireless serial bridge using the following wireless connection types:
(1) Bluetooth pairing,
(2) TCPIP over Wifi, and
(3) ESP-NOW peer-to-peer.
However, adding the extra transparent wireless serial bridge to achieve this is not optimal, and it would be great if a Code Generation option could be added so that at least for ESP32 devices, their onboard wireless hardware of Bluetooth and Wifi could be used instead - Wifi would be my strong preference for the greater range distance. Perhaps the second target device could be designated as an embedded remote control 'Client' for such connections.

I apologise in advance for the hack, as this is rarely popular with the original developer(s). But the advantages seem too good to me to be ignored. Two good use cases come to mind:
(a) an embedded remote control 'Client' can be fitted with more ergonomic input devices for operation e.g. switches and rotary encoders, than is easily possible with host-based embedControl, and
(b) it can help with the eternal embedded problem of running out of IO pins by adding a second device for the User Interface (UI). device-A just needs to allocate 2 pins at most for a UI hardware Serial port and device-B can have the switches and/or encoders and/or local LCD fitted.

Please let me know if you would be interested in making the above embedded remote control a standard part of the tcMenu feature set. I can sponsor a modest amount to help this along. If you need more details, test setups or diagrams, please let me know.
Thanks for reading.

[AtmosphEng]

Could you please give me some feedback on the feasibility of adding an embedded 'client' via wifi in the tcMenuDesigner Code Generator, as outlined above? I made a sponsorship contribution to support this request.