NR subscribe and then republish MQTT

Is it bad or incorrect to use a public MQTT in this case HiveMQ to a local MQTT? I am subscribing to a external SIM7600 ESP that sends data via 4G to HiveMQ (public 1883) then using NR to read this MQTT and resend to a local MQTT.

It seems to work but keen to understand if there is a preferred way to do this?

Bad potentially. It depends on what you do with the data.

If you are just reading & displaying values - the risk is minimal (so minimum effort, maximum gain)

However if you depend on these values for some automation or control, then you do realise the public broker is exactly that - public & could be written to at any time by any other user in the world.

1 Like

Thanks Steve, more around the flow causing issues. After creating the flow and bouncing my host.... I had a NR failure of all flows so I was just keen to see if I had caused the issue with a loop or something else. Public MQTT yes agree issue is the TSIM 7600 ESP doesnt support 8883 TLS so I am limited in what I can use.

And to add to that. You should never be blindly accepting external input to your systems anyway. Doubly so for a public server belonging to someone else.

So you should have a validation process for each subscription.

Making IoT sensor data available over the Internet is particularly troublesome where TLS isn't available. Ideally what you would do would be to set up a VPN if the devices don't support TLS directly.

Un-encrypted links can be intercepted of course but the data can also be changed in-flight. This would be a big worry for more critical infrastructure.

If you want access to a remote broker, then take a look at BeeBotte (they offer a FREE tier).
You can setup your own personal channels for your Node-RED project.

https://beebotte.com/plans

Thanks, I see it support 1883 which is where my issue lies. My TSIM 7600 doesnt support 8883 over 4G and HiveMQ private free tier is TLS/8883. Will have a play as it seems to fit what I need.

" Beebotte MQTT is accessible on mqtt.beebotte.com and accepts cleartext (port 1883) and secure (port 8883) connections."