Ashfaa Im glad you got it working, from what you have described you have done it seems right.
My mqtt seems to be behaving perfectly.
Im afraid I dont know what might be wrong .
What have you put into your local mqtt config file?
Hi all
I just manage to connect the cloudmqtt bridge with my mosquitto server i receive the updates from owntracks on the topic oqntracks/phone/phone .
I manage to extract the battery level But i don’t know if the location is working or not since i cannot see anything on the map. Could be because i am home.
I do have few errors in to the bridge connection on cloudmqtt log
1490231154: mosquitto version 1.4.10 (build date Thu, 25 Aug 2016 15:32:03 +0100) starting 1490232954: Error saving in-memory database, unable to open /var/lib/mosquitto/19744/db.new for writing. 1490232954: Error: Disk quota exceeded. 1490233517: Error in poll: Interrupted system call
Although i can see in the local mqtt that the message with location is received and battery level is displayed in HA.
If anyone can help me with this or point me in the right direction will be much appreciated.
Thanks
i dent change anything on my local mosquitto mqtt config file
it wont show your icon on the map if you are at home. If you have access to your home assistant outside of your network (IE DUCKDNS and LETSENCRYPT and port forward) when you leave home check it from your phone by looking at the MAP (menu on the right hand column.)
Thanks for your response.
Just an hour ago i had the confirmation that is working and quite well.
Now to create automation for it.
Although i continue to have errors in the cloudmqtt log:
1490201538: Connecting bridge http (http:1883) 1490201538: Error creating bridge: Name or service not known.
Thanks for all the help.
How odd!
If I understand correctly (although Im nowhere near an expert) your mqtt shouldnt be working.
I wouldnt know unless I saw your mqtt setup in your home assistant config (blank out sensitive data) even then I may not be able to help.
Which mqtt is your home assistant pointing too? local or remote?
Checklist.
Setup DUCKDNS and LETSENCRYPT
https://home-assistant.io/blog/2015/12/13/setup-encryption-using-lets-encrypt/
Follow the instruction from this link to setup your local mosquitto.
https://community.home-assistant.io/t/mqtt-working-mosquitto-cloudmqtt-bridge/1830
Make sure your cloudmqtt bridge points to your local MQTT (an address like this).
mqtt://USER:[email protected]:1883
Make sure you have forwarded port 1883 to your Mosquitto PI?
1 Like
Hi all, is there any benefit to using cloudMQT as a bridge to a local MQTT broker, maybe security? Why not just open up a port forward and link Owntracks direct…?
I would be interested to find out how you managed that.
When I tried, all the tracked phones seem to have the same ID or at one stage it would only track one phone.
It may be an issue with my ISP (Virgin Media), it messes with my ports, and I am limited with the port forwarding also.
Will be getting a new router soon (or get a different ISP) .
I’m using a bridge so I don’t have to expose my MQTT broker to the Internet. External devices can talk to a CloudMQTT instance, and everything internal can talk to the internal broker. Why increase the risks if you don’t have to 
2 Likes
Check the OwnTracks configuration on each device. You should have separate accounts on the MQTT server for each phone.
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.