Mosquitto listening on two ports (inside/outside LAN)

I have not found a way to initiate a command from my smartphone from outside my WLAN to Node-RED. I tried Telegram (chats arrive at the bot, but do not initiate anything in Node-RED, because they arrive from the wrong direction) and e-mail (polling interval too long). Other push solutions seem to cost some amount and maybe they only send push information TO the phone (?).

So I started playing with Tasker and the MQTT publisher plugin. It works flawlessly within my WLAN. I did not use any user login to mosquitto so far and don't want to change all devices inside the LAN.

Then I started a second mosquitto call with the configuration file:

port 1888
allow_anonymous false
password_file /etc/mosquitto/

and redirected a port xxxx from outside to the port 1888. Surely an extra ssl option would have been useful, but until now I do not see a requirement for that.
The user credentials in the file are created with the command mosquitto_passwd.

I could have transferred all desired topics manually from one broker to the other or I could have used the bridge option of Mosquitto.
But then I realised the concept "listener" within Mosquitto, which can define another instance of the first mosquitto listening to another port with different settings.

This is my current configuration: I created the following file


per_listener_settings true

port 1883 # maybe not required here
allow_anonymous true

listener 1888
allow_anonymous false
password_file /etc/mosquitto/
mount_point external/

With the mount_point option clients from outside only have access to topics starting with "external/", but do not see this extra topic. Mosquitto will add the prefix automatically for all communications via this port.

subcribe to Mosquitto port 1883 (without login): external/phone/start
publish something to Mosquitto port 1888 (with the user credentials from the password file): phone/start
and vice versa.
If you omit the mount_point option the clients from outside have access to all topics (which may be useful for other people). You could also play with ACL rights for certain topics.

Feedback welcome! :grinning: :face_with_monocle:

1 Like

Not quite sure what you mean there. I have both command-based and conversation-based controls available on my bots. I can easily control lights for example and query the state of lighting and heating.

Lack of SSL/TLS means that you are sending everything - including your ID and Password in clear text over the Internet. Not really the smartest of approaches.

A reasonable approach - apart from the lack of TLS. Of course, there is always some risk when exposing anything to the Internet. Using a non-standard MQTT port helps with that somewhat as does using id/pw so the risk is quite low.

The advantage of Telegram is that all of the security complexities are dealt with for you and you have a ready-made interface with simple buttons (keyboards as Telegram call them) and conversational interfaces. You also get sound, video and location msg types too along with a common client across multiple platforms. But perhaps the main benefit is that you don't need to allow any inbound connections from the Internet.

I can send messages via Telegram/Android to the bot and let him reply or send messages from the bot from Node-RED to my user id.

I tried to use Telegram from Tasker (Android) via But I can send only a chat message as bot and not TO the bot.

That means I cannot send automated (!) messages from my phone to Node-RED via Telegram for example with Tasker!

Can't tasker create a new Telegram msg in a channel? e.g. simulate a user?

Certainly, you cannot have two bots talking to each other because that is a recipe for disaster! That is a deliberate design choice by Telegram.