I would really love to see a way to configure multiple MQTT Servers in the MQTT integration.
Right now, it seems, that the limit is one… which should work for MOST cases, but in some others you might have different systems that have their own built in MQTT server.
I know, that you could configure a bridge, but what is the reason for limiting the configuration to one?
Mosquitto can be configured to bridge messages from other MQTT servers as well.
You can add an external MQTT server on another machine and setup a bridge for selected topics (or all). I did that for a while, just running mosquito on a Pi and bridging in things that HA needed.
Mosquito is tied kind of tightly into HA, so adding another instance would be a bit tough but I’m sure already possible as a different software addon.
Yes, I am aware of the “Bridge” configuration.
anyway - there’s a specific reason for this request - and configuring a bridge would require to be able to change settings on systems that bring their own MQTT implementation (which could be, that it is not always possible).
In my case, my wallbox does have it’s own mqtt server - and I faced issues in the past when using a bridge…
I want to avoid using the Wallbox’ MQTT for other services, such as z2m - and causing unnecessary load on the Wallbox… also, I want to run a test of a new Software package for this wallbox - and right now, this newer Software is running in a dedicated test environment on my Proxmox installation)…
It has - of course - it’s own MQTT and using the same topic by default.
Again, I can change the topic, and use an MQTT Bridge configuration - but just be able to configure another MQTT Server in the integration would make it so much easier.
And there’s still no explanation, WHY it is not possible to configure a second Server.
Now, imagine, I want to integrate something communicating per MQTT, to which I don’t have access to configure it to use a bridge, etc.
+1 on this one. I use MQTT for Shelly (more responsive for my usage, regular entity carries a time delay for triggering) and now got a solar power hub that also uses MQTT. Configuring a bridge that then connects to Home Assistant seems a bit complicated and counter-intuitive, Home Assistant is the Hub for all Integrations, so why do I need to consolidate multiple MQTT servers elsewhere and then source them into Home Assistant. It would be very nice to have this ability directly in the MQTT integration to add a second MQTT server in the connectivity of the integration that will push its entities into Home Assistant.
-1 from me on this.
MQTT with multiple brokers from one device (eg HA) gets messy almost immediately and is very difficult to diagnose as MQTT brokers do not have a mechanism to show who updated a topic/payload. It is far tidier to have one master broker with other devices that might have use of their own broker bridged into that.
Likewise HA having device discovery and updates originating from multiple brokers is also really difficult to diagnose and may have conflicting entries. A single broker avoids this.
You don’t need a bridge, simply change your shellies to use the solar power hub’s broker.
Totally agree. I have more than 900 mqtt entities, I don’t look forward to any breaking change by this FR.
image having to change this
trigger:
- payload: 'ON'
platform: mqtt
topic: sensor/doorbell_sensor
to
trigger:
- payload: 'ON'
platform: mqtt
topic: sensor/doorbell_sensor
broker: one
or this
action:
- data:
payload: '14163857'
topic: home/OpenMQTTGateway/commands/MQTTtoSRFB
service: mqtt.publish
to
action:
- data:
payload: '14163857'
topic: home/OpenMQTTGateway/commands/MQTTtoSRFB
service: mqtt.publish
broker: two
a nightmare.
With two mqtt servers , but not at the same time ?
like in case if one doesn’t work use other, is this possible?
An MQTT client, like Home Assistant, can only login to one MQTT broker.
Multiple brokers can be arranged in a load-sharing configuration. If one fails, others handle the additional load. The load-sharing is transparent to the client.
However, this FR is requesting the ability for an MQTT client, Home Assistant, to simultaneously login to multiple different brokers. I don’t see how that would be achieved given that MQTT doesn’t support the concept.
Home Assistant would need to be able to spawn multiple concurrent clients, each connected to a separate broker. It would introduce additional complexity (see francisp’s post) for a feature that wouldn’t be needed by most users.
And when there’s a designed alternative available: bridged brokers.
It would be good to hear about these issues. I’ve been running a bridge for a couple of years without issues — and it runs at very high rates (>4000 messages/s).
in my case, my wallbox (openWB) comes with its own MQTT Broker.
When I connected it to the MQTT Broker in HomeAssistant (Configured as bridge) - I faced the issue, that old values appeared from time to time, in a very unpredictable way.
It is likely, that this was related to some settings regarding persistency or similar, but I was not able to change this behaviour with config changes.
And I have several other reports of the same cases in the forums for that Wallbox, with the same configuration.
Since I am using the MQTT broker of the Wallbox directly, everything is running fine and as expected.
– Sure, I could use this broker for everything else, too - but tbh: I don’t want to use my Wallbox as a MessageBroker for Z2M or other stuff…
If you have one mqtt defined use that as default, if you have multiple add the name of the broker in the sensor and action definitions. This is the way the modbus integration handles it. No need to change your configs.
I agree this is a limitation for home assistant and even deserves it’s place in a WTH thread.
If I want to pull in a sensor from an external mqtt server I have to sync that topic to the local mqtt server and read that. Feels like a strange reasoning.
The message now has even been changed to “Adding addional ones is not needed”:
To me that sounds the same as “There is no need to do external API calls, we already have an API”
I know I can sync topics to/from external MQTT servers but it just feels strange to have to do this.
Compare it with the modbus integration that allows you to set multiple servers and if you have multiple defined you have to pass the name of your server along when defining the sensor or call the modbus write register service.
EMQX add-on and bridging to the rescue for now I guess.
It communicates via TCP or UDP (or serial). You can configure multiple Modbus hubs, where each hub uses a particular TCP/UDP/serial port. Then you list the entities that communicate via that hub (by listing them under the hub’s configuration). I’ll hazard a guess that an environment containing multiple Modbus hubs is more prevalent than multiple MQTT brokers.
Home Assistant supports MQTT configuration via YAML and automatic discovery. Redesigning both protocols to support multiple brokers can be a breaking change (currently, the MQTT broker’s configuration isn’t part of an MQTT entity’s configuration)
I empathize with users who could benefit from it but the low demand, high effort, and disruptive impact aren’t an appealing proposition for a volunteer software developer.