Provided the remote network can access your mqtt broker via the internet then it should be straightforward. Configure the plug with your mqtt address and credentials and it should just work. Make sure the plug you select can be configured for whatever type of connection and credentials you are using.
You will need to be very careful about security with this setup. You are transferring control messages over a public network and it is highly likely that a cheap Wi-Fi switch will not have any real security (TLS) on it. That may mean that anyone with basic skills trawling through the Wi-Fi network may be able to take control of the switch and indeed may well be able to send/receive information to/from your MQTT Broker. In the worse case, they may well be able to get access to your server and do anything they like.
Folk responding to questions like this - please let's take care to inform people of the risks.
Yes, it's a fair point. Clearly, unencrypted MQTT traffic on public networks is an exposure.
I should possibly have stated that the WiFi network I would be using is not 'public' but is provided by a third party for customer use. It is also professionally configured and managed.
I did some testing previously and established that the WiFi network in question (a) isolates clients and
(b) has a fixed public IP address
I limit access to my MQTT broker to traffic with the WiFi network public IP address, while accepting that this could probably be spoofed.
In my case the data and control is entirely non-critical.
As a point of information, I have two solutions to implementing the control (simple off/on) I'm considering. The 'lazy' option would be to use a 'smart' socket and define the control functions in NodeRed, but I also have the option of implementing this as additional configuration of an already installed ESP32 based 'outstation' which currently operates as a data collector only.
OK, not so bad then, I was worried that this might be a university network
That is good as it massively reduces the attack possibilities.
You might want to limit the access from the network to only allow a specific root topic as well. That will help you if you want to later bridge MQTT brokers.
Of course, you would ideally enforce TLS encryption on the broker but it is unlikely that your IoT devices will support it. Without TLS, there is no point in adding user id/password for clients either.
...newest tasmota supports TLS on mqtt, I believe, but for a local broker, I am still using the connection without (only "secured" my devices and broker in a separate VLAN, where Kids and guests are not allowed