[Feature] Add secondary MQTT Host + Port

[RaymondMouthaan]

Not sure if this has been requested before, but would it be possible to add a secondary MQTT Host + Port to Tasmota?

If primary MQTT host fails, retry the secondary MQTT host.

Just a nice to have feature.

Thnx,
Ray

[ascillato]

Hi,

Yes, it is a good idea.

This has been requested at #271

[ionciubotaru]

Yes, good idea, MQTT server is a single point of failure. Like wifi it's better to have 2 options.

[arendst]

I only see trouble when making two MQTT servers available:

• Normally the HA uses a fixed MQTT server IP address and has no failover capability (like Domoticz)
• If a device looses connection to MQTT server A it switches to MQTT server B only to find that all others are still on MQTT server A and no comms will happen between the two...
• what mechanism should trigger the MQTT switch of ALL devices considering the many wifi problems people already seem to have.

I forsee a lot of trouble and management to get this working and it's not worth the effort in my opinion.

[RaymondMouthaan]

Hi Theo,

After posting this request, I thought about the same bullets as you mentioned.

In my case I am using a hostname instead of ip to connect to my clustered mqtt servers. This cluster contains 2 or more mqtt server and if one goes down remaining server takes over via loadbalancing (Tasmota devices get a connection to remaining server).
So basically I wouldn't need a secondary mqtt setup with Tasmota.

As for me this request can be closed. Thanks for considering tho!

[ionciubotaru]

For example In a building there are many sonoffs (touch, POW, electrodragon, so.) and only one raspberry pi with MQTT. If raspberry pi stop working the whole building stop working. With 2 mqtt servers the building is still ok.
Using rules properly configured on each device HA becomes useless.
So, mqtt remain the only point of failure.
Mosquitto supports mirroring, 2 servers can manage the same system.

[ionciubotaru]

@RaymondMouthaan solution sounds good for me, too. So ignore my previous comment and close this issue.

[RaymondMouthaan]

@ionciubotaru I prefer emqtt within docker swarm ;)

[MikeKulls12]

I only see trouble when making two MQTT servers available:

* Normally the HA uses a fixed MQTT server IP address and has no failover capability (like Domoticz)

* If a device looses connection to MQTT server A it switches to MQTT server B only to find that all others are still on MQTT server A and no comms will happen between the two...

* what mechanism should trigger the MQTT switch of ALL devices considering the many wifi problems people already seem to have.

I forsee a lot of trouble and management to get this working and it's not worth the effort in my opinion.

I don't see these as issues. The first one is just one way to do it, quite often HA uses 2 destinations. For the second that's not someone's problem to work out from the tasmota side. It's actually REALLY easy to solve, just have consumers point to both. Third one is something to consider but normal part of coding. The answer would depend on how quickly things fail and the cost of retrying a second destination. If the cost is low, just do it. If the cost is high then wait for a few failures before failing over.

[NEoKhajitt]

I know this issue is closed, but i got some two cents on a scenario that i'm in now.

I have a working HA and MQTT setup and all my devices are working just fine, but i'm in the process to setup a whole new HAOS instance on new hardware and I want to change my configuration to be more, for the house and not for me, so different credentials, different DNSetc etc.

Now i know i can achieve what i want to do by either backup and restore my HA setting and start stripping down what i don't want, but i'd rather setup fresh since this is still my first HA setup and running in docker, i have done and tried a lot on this instance of HA.

so something that would have made life much easier in my head, would be the ability to add a second MQTT server on the tasmota firmware which in this case will be tied to a different instance of HA so i can test what I actually want to do before settling on it, without making any other changes to my HA. MQTT or the device it self.

for me having the ability to have a second MQTT server as quick troubleshooting, or even Disaster recovery in case you don't have it on your MQTT server would be a really nice to have.

[lalo-uy]

I belive you can setup mosquitto to forward messages to other server. El El dom, 16 de abr. de 2023 a la(s) 16:58, Niel Morgan < ***@***.***> escribió:

…

I know this issue is closed, but i got some two cents on a scenario that i'm in now. I have a working HA and MQTT setup and all my devices are working just fine, but i'm in the process to setup a whole new HAOS instance on new hardware and I want to change my configuration to be more, for the house and not for me, so different credentials, different DNSetc etc. Now i know i can achieve what i want to do by either backup and restore my HA setting and start stripping down what i don't want, but i'd rather setup fresh since this is still my first HA setup and running in docker, i have done and tried a lot on this instance of HA. so something that would have made life much easier in my head, would be the ability to add a second MQTT server on the tasmota firmware which in this case will be tied to a different instance of HA so i can test what I actually want to do before settling on it, without making any other changes to my HA. MQTT or the device it self. for me having the ability to have a second MQTT server as quick troubleshooting, or even Disaster recovery in case you don't have it on your MQTT server would be a really nice to have. — Reply to this email directly, view it on GitHub <#2937 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXBW4L6KC24JSW63FH2KHTXBRFNFANCNFSM4FD6NYLA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[teaalltr]

@arendst is this being considered? I think it'd be very useful!

[chunter1]

I would also very much appreciate the support of two independent MQTT hosts.

[Noschvie]

What is your use case? I have never seen mosquitto crashing… you can use your router to use an alternative broker.

[chunter1]

In my case i want to send the data to two different automation servers (Home Assistant and FHEM) in parallel.

[Noschvie]

Why not using a common broker?

[chunter1]

The two different automation servers are located at different sites and are totally unrelated. If one fails, the other still logs the data.

[Noschvie]

For example, you can use Mosquito's bridging mode.

[chunter1]

No, it‘s all about having two completely independent mqtt broker running.

[s-hadinger]

It's not supported nor planned.

Connecting in parallel to two distinct brokers would create a mess when it comes to subscriptions. Definitely not in the roadmap. Please find alternate ways.

[joba-1]

If you need to avoid single point of failure, I recommend using a floating ip: If one broker is not reachable, bring the ip down on that machine and bring it up on the other.

[teaalltr]

Sorry guys but I don't understand, why supporting having two wifi networks and not two mqtt brokers? Having two wifi networks is even more niche than two mqtt brokers, still you have that option in Tasmota. For me two mqtt brokers would be pretty useful and commonly used once available

[s-hadinger]

If you can’t connect to wifi it's game over.

High availability for mqtt is usually done through dns or other HA mechanism. This is very common.

There are no plans for configuring a failover mqtt server. And even lesser plans to connect to 2 mqtt servers at the same time. This is not the way mqtt was designed

[joba-1]

The two different automation servers are located at different sites and are totally unrelated. If one fails, the other still logs the data.

with different sites you mean one server cannot reach the other broker? Why then can the clients reach both brokers?

[Noschvie]

The two different automation servers are located at different sites and are totally unrelated. If one fails, the other still logs the data.

A block diagram would be helpful here

[chunter1]

As I notice, that there is no interest in implementing such a feature, i suggest saving time and ending the discussion.