Its all ok now, this is why I bridged the MQTT brokers
Thanks I agree having ports open to the internet is something I would rather avoid. However I already have one open to access HA so it is a reality I have to live with. Anyhow I notice that there is the option to use Authentification with Owntracks, but I am not sure if this is referring to the password set or it this is some kind of key based process⌠Any ideas?
Owntracks supports username and password, as well as client (and server) certificates (well, thatâs what I saw from 3 seconds poking at the documentation).
Also, just because you expose one service, doesnât mean that exposing others isnât something you should avoid if possible. Each service you expose increases the risks.
2 Likes
Could I URL post on the port I already have open for HA, 8123?
I havent tried that , all I know it worked on 1883 .
In theory I dont think it will because that is the port HA is bound to.
1 Like
Could someone explain what bridging CloudMQTT (with home hosted broker) has over just using CloudMQTT?
Would you not still be pushing/storing the same data through them?
Also, would you not still incur the same transfer fees as if you just hosted with them?
If you only have MQTT traffic that is for outside of your local network, then using CloudMQTT as your only broker makes sense.
However, if you have MQTT traffic that is local to your network, using CloudMQTT for that would
- Make it dependent on your internet to work.
- Be subject to the delays of sending messages through the internet
- Trusting that the security of the CloudMQTT broker is set up correctly and nobody has hacked it.
Using a bridge to CloudMQTT makes sure that only traffic that needs to go out into the internet does so.
1 Like
Would you be so kind as to elaborate on this? From my simple IT-ignorant mind, youâre still opening up something either way, whether itâs the port or the mosquitto bridge. Does mosquitto not have to do basically the same thing, and incur the same risks/vulnerabilities whether itâs talking to cloudMQTT or directly to devices?
Thank you!
If you bridge from your local mosquitto to cloudmqtt, you are connecting to an outbound internet service, like you do all the time browsing the web and what not.
If you open your local mqtt to the internet you are allowing the internet access into your network.
The initial connection is the important part security wise.
2 Likes
CloudMQTT have removed the ability to bridge under their free plan so I guess these instructions will only work if you have a paid subscription to MQTT. It would have been nice of CloudMQTT to have allowed at least one bridge for free users.
I have a helper script for this that is subscribed to the cloudmqtt topic. whenever a message gets published there, itâll forward it to my own mqtt server. Simple and effective since itâs only 1 topic on my end 
Ah ha!
Iâve just spent more than a few minutes trying and failing to get Mosquitto to bridge to CloudMQTT. I assumed (and it probably was) because I wasnât doing something in the config properly - all the forum entries on this that I could find are quite old now.
But are you saying this is no longer possible anyway (on hassio and using the free CloudMQTT plan)?
I use Owntracks and I used to have a port open for MQTT. I decided to close it and use HTTP instead but by doing this you lose some useful features in OwnTracks itself such as tracking friends.
I assume there is no alternative?
what frustrates and confuses me is that my old home assistant install can still bridge to cloudmqtt ⌠but my new set up can not âŚ
I have used Node-Red as an MQTT bridge and it seems to work fine between Cloudmqtt & Mosquitto.
I was just reading the website Losant will allow MQTT bridging with their free account. This is something I will try out.
I having troubles getting my mosquitto broker in Hassio to read the bridge.conf file file. I created a directory share/mosquitto, but am still getting an error when the mosquitto broker tries to open the configuration file. Has anyone else had this issue?