# MQTT Smart Socket?

**URL:** <https://discourse.nodered.org/t/mqtt-smart-socket/58169>\
**Category:** Hardware\
**Created:** [11 February 2022 18:29 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169 "2022-02-11T18:29:49Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![MakerMan](https://avatars.discourse-cdn.com/v4/letter/m/82dd89/32.png) [@MakerMan](https://discourse.nodered.org/u/MakerMan)\
**Post date:** [11 February 2022 18:29 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/1 "2022-02-11T18:29:49Z")

</div>

I am looking for a smart socket that will connect to a third party WiFi network and which can be configured to connect to my MQTT broker (at a fixed public IP address).

I want to be able to turn this on and off with MQTT messages from Node Red and also remotely read its status (i.e. off or on).

Any recommendations for such a product?

N.B. I have no control over the network to which the smart socket connects, I only have credentials to use the network.

---

<div class="post-metadata">

**Author:** ![greengolfer](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/greengolfer/32/28276_2.png) [@greengolfer](https://discourse.nodered.org/u/greengolfer)\
**Post date:** [12 February 2022 08:15 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/2 "2022-02-12T08:15:58Z")

</div>

All shellys have MQTT capabilities.  
They have a smart plug: [Shelly Plug S - Shelly Cloud](https://shelly.cloud/products/shelly-plug-s-smart-home-automation-device/)  
It just works 🙂

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [12 February 2022 08:41 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/3 "2022-02-12T08:41:04Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [12 February 2022 14:13 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/4 "2022-02-12T14:13:25Z")

</div>

> [@MakerMan](#):
>
> N.B. I have no control over the network to which the smart socket connects, I only have credentials to use the network.

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.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [12 February 2022 15:05 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/5 "2022-02-12T15:05:05Z")

</div>

> [@TotallyInformation](#):
>
> let's take care to inform people of the risks.

You are absolutely right, of course. I consider myself suitably admonished.

---

<div class="post-metadata">

**Author:** ![MakerMan](https://avatars.discourse-cdn.com/v4/letter/m/82dd89/32.png) [@MakerMan](https://discourse.nodered.org/u/MakerMan)\
**Post date:** [12 February 2022 16:40 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/6 "2022-02-12T16:40:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Sean-McG](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/sean-mcg/32/54677_2.png) [@Sean-McG](https://discourse.nodered.org/u/Sean-McG)\
**Post date:** [12 February 2022 17:15 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/7 "2022-02-12T17:15:10Z")

</div>

> [@MakerMan](#):
>
> the option of implementing this as additional configuration of an already installed ESP32 based 'outstation'

I would just add a relay to this in that case.

---

<div class="post-metadata">

**Author:** ![MakerMan](https://avatars.discourse-cdn.com/v4/letter/m/82dd89/32.png) [@MakerMan](https://discourse.nodered.org/u/MakerMan)\
**Post date:** [12 February 2022 18:03 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/8 "2022-02-12T18:03:08Z")

</div>

> [@Sean-McG](#):
>
> I would just add a relay to this in that case.

Yeah, that's probably what I'll do!

And it's good now to be aware of the Shelly products too!

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [12 February 2022 19:37 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/9 "2022-02-12T19:37:09Z")

</div>

> [@MakerMan](#):
>
> is not 'public' but is provided by a third party for customer use. It is also professionally configured and managed.

OK, not so bad then, I was worried that this might be a university network 😀

> [@MakerMan](#):
>
> isolates clients

That is good as it massively reduces the attack possibilities.

> [@MakerMan](#):
>
> I limit access to my MQTT broker to traffic with the WiFi network public IP address, while accepting that this could probably be spoofed.

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.

---

<div class="post-metadata">

**Author:** ![hominidae](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/hominidae/32/4174_2.png) [@hominidae](https://discourse.nodered.org/u/hominidae)\
**Post date:** [12 February 2022 20:55 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/10 "2022-02-12T20:55:34Z")

</div>

...any plug flashable with tasmota will work: [https://templates.blakadder.com/](https://templates.blakadder.com/)

regarding save access from remote, I recommend the following:

- connect plugs to local Broker
- create account on public broker (I use cloudmqtt)
- manage user accounts on public broker. create one for local and as many as needed for remote access
- create a bridge from local to remote broker, use TLS and bridge only the required topics needed
- when remote, use secure access (https, tls, wss, ...) to connect to public broker and you will be able to view/control anything that is bridged from local

---

<div class="post-metadata">

**Author:** ![hominidae](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/hominidae/32/4174_2.png) [@hominidae](https://discourse.nodered.org/u/hominidae)\
**Post date:** [12 February 2022 20:59 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/11 "2022-02-12T20:59:59Z")

</div>

...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 😉

---

<div class="post-metadata">

**Author:** ![MakerMan](https://avatars.discourse-cdn.com/v4/letter/m/82dd89/32.png) [@MakerMan](https://discourse.nodered.org/u/MakerMan)\
**Post date:** [12 February 2022 21:34 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/12 "2022-02-12T21:34:23Z")

</div>

> [@TotallyInformation](#):
>
> Of course, you would ideally enforce TLS encryption on the broker but it is unlikely that your IoT devices will support it.

My IoT device is custom on ESP32, but despite many attempts, I've still not managed to get TLS working between my broker and this, but that's one for another forum!

---

<div class="post-metadata">

**Author:** ![dvovla](https://avatars.discourse-cdn.com/v4/letter/d/c67d28/32.png) [@dvovla](https://discourse.nodered.org/u/dvovla)\
**Post date:** [13 April 2022 10:40 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/13 "2022-04-13T10:40:38Z")

</div>

Flash Tasmota firmware to any suitable ESP8266 based wifi plug.

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [13 April 2022 12:05 UTC](https://discourse.nodered.org/t/mqtt-smart-socket/58169/14 "2022-04-13T12:05:25Z")

</div>


