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.
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
-
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
-
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.
Great finding, thanks. Sounds like there’s a bug/feature in the way HA handles MQTT
Awesome, just to confirm is this using the Owntracker device tracker in your hass config also?
Yes, using owntracks
I think there is an option we can set in Mosquitto that makes it keep it’s subscriptions so that HA doesn’t have to. I’ll look into that today.