I am exactely at the same point!
using the MY_GATEWAY_* as a node is a big big issue, when you want to have a "higher" number of those. each of these devices has to be configured as a gateway in whatever controller you use.
following some other posts, the developers seem to have no view on ip-based sensors, and the word "gateway" is a little bit misleading.
the mysensors framework is a perfect framework for sensors though.
the AP-feature of ESP32 ESP8266 e.a. devices is, as you stated correctly, a perfect way to build a wifi-based backbone for such devices.
Some days ago I started to run exactely into this "problems" and as a easy to use "workarround" I tried the following:
I use a ESP* devices as an access-point and run a tenetserver on it. all the traffic is then bridged to one of the serial interfaces, which is (in my case) connected to a "mYsensor Ethernet gateway" , that uses a "fake" rs485 on its inside serial. those two serials are connect via crossed-over TX/RX lines. (see this sketch and activate the swap option)
next "problem" are the ip-based client-nodes. I also expected that the "gateway" would register itself and all the nodes behind on the "outside" interface, but thats not implemented. SO the only way to gt that working is:
ESP*-IP-Client node (aka bridge):
Start wifi and connection to a AP.
Defina a Softserial device (with loopback)
Start a telnet-client(!!!) on the device and bridge all input/ouput to a that device.
Use MySensors framework (MY_RS485) and define the use of Softserial as the device (the same softserial as defined above).
THESE clients can now connect to
) an MySensors network either with conneting to a MY_ESP_GATEWAY or MY_ETHERNET_GATEWAY doe to the fact, that the IP-connection is nothing else but simple "serial over ip" if you want to name the child like that.
*) to a "bridge" like described above
maybe thats not teh nicest solution but a way to get serial transport over ip running.
*) "repeating nodes" could generate a denial-of-service by repeatedly re-transmitting the same packets
*) Wifi-AP and Wifi-Client on the same device is a bad idea: the Wifi itself is something like a hub (and definately not a switch in the ip-network-speaking), what means: you bring additional traffic to that hub (aka HF-channel) and screw down the performence
one more (future) thoughts:
maybe someone should try something like a "IP-Concentrator" or "Arduino based Controller" functionality. That means:
*) IP or mqtt-Gateway-functionality as already possible with mysensors
*) MySensor Gateways can connect to that devices via TCP. Incomming traffic needs to be "rewritten" for example NodeId of the connected GW needs to be altered into the last byte of the IP-address and vice versa
I am very sure that somebody already made this, but the difficulty is (as far as I see) the nameing of funtionality: GATEWAY vs. CONTROLLER vs. NODE vs.BRIDGE ...
The main argument against "a MySensor Sensor is always ONE Gateway" is, as you already stated, the amount of gateway-connections you have to maintain.
a last thought:
I have not played arround much with Nodemanager, but I think that "concentrator" functionality as well as "SerialOverIP" transport could maybe be easyly done there
(wenns zu unverständlich war, erklär ich das auch gern nochmal in deutsch)