The only relevant post I've found so far seems to be this one: https://community.tp-link.com/en/business/forum/topic/583776

I had my SSH port set to a non-standard port when I tried to adopt this switch the first time around, when it kept getting reset to 192.168.0.1.

The question I have is this - is the switch configuration supposed to be carried into Omada during the adoption process? If the IP is reset or the LAG LACP config is lost I'll lose the connection to my router. I need someone to verify whether or not the switch's LOCAL UI configuration will be carried into Omada. I believe setting my SSH port to something other than port 22 might've caused this problem.

Am I on track here?

That didn't work...Switch still reverting to 192.168.0.1 during the Omada adoption process...

  @RamtinR So how can the switch be configured within the controller if it's resetting the IP to 192.168.0.1? Why would the adoption place the switch on a network it can't communicate with? I'm fine with configuring in the Omada controller, but can't even get to that point if Omada cuts the switch off from the rest of the network? How do I ensure it gets adopted with an IP that can be accessed from my network?? The adoption into Omada doesn't even work because the switch gets cut off from the network before it can be adopted by the controller...this is a huge bug in my opinion. The switch's local LAN IP should NEVER be changed during the adoption process, or it would be impossible to adopt it. 

How was anyone able to get this switch adopted if they're on something other than a 192.168.0.x network?? I had zero issues getting a TL-SG2210P adopted properly into Omada, should be the same process for all these switches. 

The switch has loop prevention built-in, so loops probably weren't the issue. The OPNsense router, on the other hand, was configured to communicate via LACP LAG to the Switch over 3 ports, so I believe when the switch was resetting, communication between the router and the switch was gone, meaning the switch wasn't getting an IP or connection over the WAN (from the router), breaking the adoption process. The entire LAN interface (plus all VLAN's) go over the LAG group on the router, so LAN <-> WAN was breaking during the adoption process, because the switch config was being reset entirely. From my understanding, when LACP is enabled between two devices, it has to go through a LAG negotiation process or things won't work at all. Hopefully in the future *some* basic configs, such as IP and LAG, can be migrated during the adoption process. I hadn't configured anything on that switch beyond LACP LAG to the router.

I should've just connected the cables and waited to do the LACP LAG configuration in OPNsense until AFTER the adoption process had completed. Lesson learned.