CloudMQTT Bridge, Mosquitto & Owntracks

Can anyone provide me with a working example of this please?

I’ve got everything fine with the bridge. Mosquitto is able to pull the data from CloudMQTT. I tested this with a MQTT device tracker, which provides me with a string of data, battery, loc, etc not the usual home and not_home.

From what I can see online I should be able to link the Owntracks device tracker with the local Mosquitto MQTT broker. However this doesn’t seem to work. If I switch back to my original setup of pulling CloudMQTT straight in to HASS and not through Mosquitto, the Owntracks device tracker works fine.

It seems I may have missed something and the data being sent to Mosquitto from the CloudMQTT bridge isn’t what the Owntracks tracker is looking for?

I would love to hear form someone that has this setup working completely!

Out of curiosity, why are you using CloudMQTT and Mosquito? Why not just pass through one or the other?

@turboc - I wanted to use it so that I could use MQTT on my own network, without having to expose it externally, and still use Owntracks.

I’ve found the same problem, never chased down what the cause was. It should work, based on people’s experiences in other threads. I may have a poke again another time.

So why not have Owntracks come straight to your Mosquito server? Sorry if I’m missing something obvious…

Because:

There have been various threads where others have expressed the same desire, because they too understand that the more software you expose to the Internet, the more you increase the risks of a compromise.

1 Like

I guess my point is this. You already have your cloud vendor coming in with ontracks on it. what difference does it make whether it goes to HA directly or to the mosquito server? Putting the mosquito server in between just seems to be adding a layer of complexity. Have your internal devices use the mosquito server.

Now if your goal is to get rid of the cloud vendor, then you would have to open a port for ontracks to talk directly to your mosquito server. but either way, I think having multiple MQTT broakers talking to each other is just more complexity than is needed. You have the same open ports either way though since ontracks is coming in from the outside.

It means exposing the MQTT broker to the outside world, something I’d like to stay away from if possible. There are no ports open for CloudMQTT to push the location to HASS. I would like to use the local MQTT broker for other services that don’t require outside access.

There are multiple topics on this community with people discussing why and now to implement this, however I have not encountered anyone having this problem.

And that’s fine. But your request sounds like you are trying to send your owntracks data from your cloud provider to your local broaker instead of directly to hass. Are you trying to get rid of CloudMQTT?

Setup owntracks to send to CloudMQTT -> CloudMQTT sends directly to HASS
Setup local devices to send to Mosquito -> Mosquito sends directly to HASS

That would be fine but as far as I’m aware you can’t run two brokers within HASS. It’s either one or the other. I’m not trying to get rid of CloudMQTT at all. So yes, I am trying to bridge CloudMQTT to my local MQTT.

Owntracks > CloudMQTT > Bridge > Local MQTT.

Now that would really stink. I’m not sure, but it would sure put a damper on my plans since that’s exactly what I’m thinking about doing here shortly.

The way the bridge works is that it can be in either direction. So you can configure a bridge on your local MQTT server and it’ll connect to the external MQTT server. It doesn’t have to be inbound.

All you have to do is have your “master” MQTT server bridging to the other one or ones. You can even have it as a one way feed. It’s worth a read of this thread.

in the /etc/mosquitto/conf.d directory make 2 files.

1 mosquitto.conf
all this file has in it is
include_dir /etc/mosquitto/conf.d

2 cloudmqqt.conf
connection cloudmqtt
address cloudmqqtserver:cloudmqqtport
remote_username xxxxxxxx
remote_password xxxxxxxxx
clientid xxxxxxxx
try_private false
start_type automatic
topic # in

Restart your mosquitto server with -c /etc/mosquitto/conf.d/mosquitto.conf

That did it for me. I think… I’m seeing updates in HA at least.

I also setup a bridge in cloudmqtt to forward all messages, there are some posts out there about how to do it by reaching out and getting them, instead of taking a push. That won’t be as realtime though since you are waiting on a poll I think.

False alarm, not working again.

Ok, I think I’ve found something. It seems that if I restart mosquito, is stops working UNTIL I restart HA. Once I restart HA, it starts working again… I’ve only tried this a couple of times, but that seems to be the case right now…

Ok, I’m going out for a while. I’ll check it while I’m out and see if it’s keeping up with me…

Watch this video from Ben @bruhautomation, super helpful and helped me get my MQTT set up and working perfectly.

Yes, Ben’s video’s are always helpful. The problem we are/were having is getting the bridge between mosquitto and cloudmqtt working and still having HA talk to mosquitto. I’m thinking it mostly came down to having to restart HA any time we restarted mosquitto.

It kept up with me. HA showed correctly when I was gone, and updated correctly when I got back home.

Here is what I have config wise.
on the system where you have mosquitto installed

  1. in the /etc/mosquitto directory create the following file and name it mosquitto.conf

    Place your local configuration in /etc/mosquitto/conf.d/

    A full description of the configuration file is at

    /usr/share/doc/mosquitto/examples/mosquitto.conf.example

    pid_file /var/run/mosquitto.pid

    persistence true
    persistence_location /var/lib/mosquitto/

    directory where you want hour mosquitto log files placed

    log_dest file /home/mosquitto/mosquitto.log

    include_dir /etc/mosquitto/conf.d

  2. in your /etc/mosquitto/conf.d directory create a file called cloudmqtt.conf as follows:

    connection cloudmqtt
    address :
    topic # in 1
    try_private true
    notifications false
    start_type automatic
    remote_clientid <user on cloudmqtt that has r/w access>
    remote_username
    remote_password
    keepalive_interval 60 # by default this is 300, I wanted to see transactions flowing so I set it to 60
    cleansession true
    bridge_protocol_version mqttv311
    local_clientid
    bridge_cafile /etc/ssl/certs/ca-certificates.crt
    bridge_insecure false
    allow_duplicate_messages true # I set this to make sure I got the messages even if I got them twice. Twice is better than not at all.

in your homeassistant directory modify your configuration.yaml file as follows.

mqtt:
  broker: <ip address for local mosquitto server>
  port: 1883
  username: <local mosquitto username>
  password: <local mosquitto password>

Here is what’s happening. Whenever mosquitto is restarted, it loses all it’s subscriptions. When it comes back up and re-establishes with HA, HA isn’t re-subscribing for it’s owntracks subscriptions so nothing gets sent to HA. One we restart HA, it re-requests for the subscriptions and things start flowing again.

I’ve had enough fun for today. Until tomorrow.

1 Like

Great finding, thanks. Sounds like there’s a bug/feature in the way HA handles MQTT :frowning: