Alas I am kind of drifting towards..... Hive. I've been told they support private channels/topics for free also.
For the sake of it, I may see what their front end looks like and how easy it is to do it.
OK - I'll leave you to explore that route.
Let me know if you ever need further help with BeeBotte.
1 Like
Again, thanks.
It is a whole new world which broker to use. Pros and cons.
Andrew,
As @Jbudd has said earlier - why not go with one of the Zero Conf networking options ? The easiest is Zerotier.
The steps are straightforward and within your wheelhouse
- Setup an account at Zerotier
- Setup a network at Zerotier
- Install the client on your RPI where your broker is - this will then be assigned a reserved address that does not change on the Zerotier network - in the Zerotier console allow that node on your network you created
- Install the Zerotier client on your phone/tablet - you will get a unique address also - in the Zerotier console allow that client onto your network
- Tell whatever client you are running on your phone to attach to the unique IP address of the RPI - this will not change regardless of what your ISP does
Done
Craig
1 Like
Andrew is pretty emphatic about not wanting a VPN style solution:
I am keeping my local MQTT brokers.
I am needing an external one for a very specific task. Remote devices talk to it and it will always work.
My IP address can change at the drop of a hat and so if it changes the remote devices will fail to connect.
I think he may not realise that Zerotier can/will automatically reconnect when either device changes it's IP address - because it is an outbound connection from each endpoint, just the same as using a cloud based MQTT broker is.
Or else the unspecified "special task" really can't cope with an IP address change.
Whatever, Hive should work fine.
Yes as most people who have not used SDN before they think it is more complex than it is and do not understand the capabilities.
Regardless of what the special task is - the Zerotier service will shield it from any knowledge of the underlying IP addressing.
Craig
Ok, to explain things a bit more:
I have local MQTT brokers.
This project on which I am working needs a broker that is always there.
I can't use my local brokers as I said because the IP address can change at the drop of a hat.
This project will use an external one - still haven't decided, but HIVE is the next one I'll try.
Be it it works or doesn't I'm not going to then change all the local brokers to use the external one.
There is no need.
And if my uplink ever dies, my local stuff won't be able to work.
So there is/are NO options for that.
So in this specific case I will assign the external broker to the one MQTT-IN node and then send its output to do the magic things I need done.
Where is the data for the MQTT broker coming from ? i.e. is it coming from a device on your local network - if so your whole project is relying on your local network being available
Read my lips IT DOES NOT MATTER if your local broker address changes - Zerotier creates a virtual network and gives your local machine a static address on that Virtual network - this is overlaid on top of your home network - the Zerotier client on your Rpi continually talks to the ZeroTier servers and tells them where it can be found
Craig
1 Like
@Trying_to_learn
They talked me into zero tier also,
I'd have to say it works different then a standard vpn service and i love it,
when i am accessing things on my local network through zero tier, I haven't had any issues.
it was very intimidating at first but i was able to set up pretty easy.
just read its info page a little and see what its capabilities are.
Remember you don't have to try everything you look at but if you don't look at it you may miss something that is what you need or want.
cheers
After I noticed this:
I thought that maybe the hivemq broker would provide resilience in the event that the subscribing Node-red machine goes off-line. It doesn't.
I set up the hivemq broker on a couple of Pies (even though I've had it in use before this was a complicated and irritating procedure) and started publishing messages with QOS 2 and Retain true.
Messages published while the subscribing Pi was offline were not delivered when it rebooted.
Here is another explination of what's going on with me and MQTT:
I have a LOCAL NETWORK. It talks with the LOCAL MQTT broker. There is no need for an internet connection.
Using a broker on the internet would kind of fail if the uplink (internet connection) fails.
Remember, I live in Oz and it happens now and then.
It would be STUPID in every aspect if my broker was not available because the internet was not connected and my machines could not talk to one another.
"It doesn't matter if your IP changes, blah broker will still be found.
Yeah, fantastic. Not much good to me though if the link is down.
Any machine using blah broker finds it because of DNS.
I am using an EXTERNAL broker for ONE THING ONLY.
That is because I am needing external devices from OUTSIDE my LAN to find a broker.
That is on the big internet and I am not too worried.
AGAIN:
If there is ABSOLUTELY NO UPLINK how are my local machines supposed to talk to this remote broker?
I'm not going to rely on an uplink working for my LOCAL network to have MQTT between themselves.
They (the other device/s) talk to it and ONE node listens to that EXTERNAL broker and shows me messages if/when the arrive.
How is this so difficult to understand?
Apologies for going on about this Andrew.
I don't want to try and force you to use one solution rather than another.
I just get the impression you are rejecting some suggestions based on a misunderstanding of how they would work.
If you use Hivemq, Beebotte or other cloud based brokers they are in addition to your local broker.
If you use Zerotier, Tailscale, PiVPN or other VPN approach they provide access to your local MQTT broker from the internet in addition to access over your LAN
- My local MQTT broker is at 192.168.1.11:1883. My local devices connect using this address and it all works even if the internet connection is down.
- Zerotier gives me a virtual network so I can also access it securely from the coffee shop at 192.168.192.11:1883. My local devices do not use this IP address. If my home internet connection is down, connection from the coffee shop fails.
- Hivemq gives me an external broker at 3315816bc21d2cc714d54e26a297594e.s1.eu.hivemq.cloud:8883. My local devices do not use this broker at all. If my home internet connection is down, I can still send messages from the coffee shop but they won't be delivered to Node-red at home.
The best option for me is one I understand and can easily maintain. I hope you find the best option for you.
3 Likes
Well explained
Andrew, the basic question to ask - where is the data for your external broker going to come from - assuming it is a device on your LAN ? If so this means for your external solution to work (i.e. to get data a feed it to the remote devices) then your home network needs to have a working internet connection.
Completely aside from this as @Jbudd has summarised pretty well.
Adding Zerotier to your local broker on your network - extends that broker so that it is available securely across the internet - it is still totally availabel to all local clients on your LAN - regardless of the state of the internet connection.
Nothing changes with your current setup on the LAN on your broker - you continue to use it as you would now - Zerotier just gives you the ability to securely connect to the SAME broker from outside your network - regardless of whether your INTERNET IP address changes or not
Craig
Good question. As has been said by others, no-one is suggesting that you change the way your local mosquitto works locally. The point is that in addition to that broker working locally you can make it available to your external devices from outside your lan by using, for example, zerotier. That is therefore a viable alternative to using a cloud mqtt broker.
Thanks for the explanation.
Originally when I first started External brokers were not an option for me.
Good to know if they are configured correctly I can use an external broker that will be used, and if the uplink fails things fall back on the local broker.
I won't go on as I think it is not needed.
In answer to the question regarding from where the data comes is:
An EXTERNAL device that is NOT on my LAN.
Which is why I need to be able to give the broker a NAME (rather than an IP address) and then in the bigger scheme of things any IP changes will be covered by DNS in/on the internet.
(Which is where the external device is)
Thanks @Colin.
I have now been brought up to speed that if I use certain external brokers, if the uplink fails, it falls back on the local one.
(All)
So the normal broker which is installed on the local machine doesn't support an external broker.
But if I use (install?) the other broker names they support use of said broker and if the link (sorry:uplink as I call it) fails, it falls back to the local one.
Lesson learned.
Well.... not quite... nothing falls back anywhere unless you add logic (or a flow) to do that...
The data path you are talking about (I think) is
External device (phone?) -> external broker -> internal broker -> the rest of your internal Node-RED world
To get from the external broker to the internal one either you can configure a bridge (eg see here - Mosquitto MQTT Bridge-Usage and Configuration ) OR you can create something in Node-RED - eg an MQTT client inside that subscribes to messages from outside - IF you do this then you need to be careful about setting up loops - ie send a message out and then immediately get it back etc...
But yes - If the link to external fails then everything inside will still talk to the local broker and be OK.
1 Like
Ok, thanks for clearing that up.
But as it is - and as it is working - I'll leave the ONE MQTT IN node to the external broker and let it receive the external messages and act accordingly.
The existing local/internal brokers I'll leave as is.
Yes indeed - if it's working... don't fix it !
1 Like
