@CyborgAndy Glad to hear, that you have published all your fixes and upgrades to GitHub! So we have a current source code base to continue development or for debugging. 
Thank you for the gateway connection fix! I just upgrade my OH instance from 3.2 to 3.3 and successfully tested your snapshot. 
Have a nice weekend!
It seems that still some people are interested in this MySensors binding being updated further.
I'm currently using in openHAB 3.2 the version that @vores8 kindly provided in post #109 on 21/07/2022, based on the source fork from @ncollins (https://github.com/nikolac/openhab2-addons/tree/mysensors-oh3-migration).
Now I noticed that there seems to be a bug in the ethernet gateway with reconnecting after the TCP connection is lost. The loss of the connection is detected, but it is not disconnected and re-established afterwards.
I would like to look at this in the " current" source code and if possible develop a fix and provide it.
Therefore the question to the community and especially to @vores8 and @ncollins, if the source code adapted to OH 3.2 or now to OH 3.3 has been uploaded by you to GitHub. If so, under which repository and branch? If not, please catch up on it for us so that we can merge the adaption you have made to the source and possibly bundle and ensure further development.
Thanks a lot in advance! 
tekka, first of all, thank you very much for your efforts and shared results on MYSController and MYSBootloader! 
I am trying to upload new firmware to battery operated nodes via MYSController 1.0.0beta. But it seems that MYSController does not send an ST_FIRMWARE_CONFIG_RESPONSE message after the node has sent an I_PRE_SLEEP_NOTFICATION before its next smart sleeping. Thus no firmware packages are requested from the node using ST_FIRMWARE_REQUEST messages.
Uploading firmware to nodes that are not sleeping and powered by a power supply basically works. One limitation seems to be that the node has to be restarted while MYSController is connected to the gateway. My guess is that the ST_FIRMWARE_CONFIG_REQUEST message from the node must be received first by MYSController before the assign firmware selection inits a ST_FIRMWARE_CONFIG_RESPONSE message. If the nodes are not sleeping, this can easily be done using the request reboot function of MYSController. In the case of the battery-operated node, this reboot request is not transmitted on the next wake-up respectively pre sleep notification.
I also noticed another bug: After receiving the reboot messages from a node, it is always set as a Sensebender board.
My setup:
MySensors version: 2.3.2
Gateway: ESP8266 with RFM69HW
Nodes: Canique MK2 boards (Moteino clone) with Atmega328P, RFM69HW, 4mbit Winbond W25X40CLSNIG flash chip and DualOptiboot bootloader.
@tekka: I would like to have a look at the code of MYSController to understand the firmware OTA start problem and the wrong detection of the board and to fix it if necessary. Would you be interested in making your code available on GitHub, for example, so that MYSController is developed further together? Please don't bother with code cleaning in advance.
I experience the same behaviour with an ESP8266 wifi gateway. In the MySensors sources I found the reason why this doesn't work:
In the file core\MyGatewayTransportEthernet.cpp in lines 98 to 106 the ethernet server is initialized:
#if defined(MY_GATEWAY_CLIENT_MODE)
#if defined(MY_USE_UDP)
EthernetUDP _ethernetServer;
#endif /* End of MY_USE_UDP */
#elif defined(MY_GATEWAY_LINUX) /* Elif part of MY_GATEWAY_CLIENT_MODE */
EthernetServer _ethernetServer(_ethernetGatewayPort, MY_GATEWAY_MAX_CLIENTS);
#else /* Else part of MY_GATEWAY_CLIENT_MODE */
EthernetServer _ethernetServer(_ethernetGatewayPort);
#endif /* End of MY_GATEWAY_CLIENT_MODE */
For my gateway the last statement without the constant MY_GATEWAY_MAX_CLIENTS is used to define the server. Thus it is clear why only one connection is kept.
Maybe the ESP8266 examples should be updated. Or the ethernet server code should be reworked. 