Alternative MQTT broker

[MacWyznawca]

Would there be a chance to add an alternative MQTT broker (with same parameters as primary)? If it did not get to the first one, it would try to the other (as with WiFi SSID1, SSID2).

[Satellietje]

That would be fantastic. Good idea!

[ionciubotaru]

In your home install 2 raspberry pi each one with his own mqtt broker, dns, dhcp server and better wifi AP Each dns will resolve the brocker's name to it's own ip. If one machine crash, the second one will do the same job. Of course you must mirror the brokers This is the basic of a 0 fault system.

[MacWyznawca]

Thanks @ionciubotaru. I have QNAP TS-251+ 8GB RAM with Docker. I use Orange Pi Zero as a backup. Now, I hardcoded second MQTT brocker in Tasmota firmware. If QNAP in maintenance etc. my Sonoffs and Electrodragons connect to Orange Pi.

[stefanbode]

I have never seen mosquitto crashing :+1: How should the second MQTT broker be handled? As a backup, if the first one does not answer or in parallel to be connected and receiving messages from both. Last option would require major code changes, that could cause RAM issues because this is always a bottleneck at ESP8266

[MacWyznawca]

@stefanbode Mayby don't crash, but I sometimes must restert my QNAP ex. after firmware upgrade 😉 This is several minutes…

[cobra85ec]

can i use adafruit as a MQTT broker

[davidelang]

sure, why wouldn't you?

On Thu, 6 Apr 2017, cobra85ec wrote:

can i use adafruit as a MQTT broker

[cobra85ec]

i try but it wont connect....sorry im kinda new to this

[davidelang]

so do they require a password or TLS? it's really not safe to be doing mqtt over the Internet without TLS, you really don't want to have random hackers able to control your switches

how does adafruit enforce unique names? do you have a unique name on your device?

There are all sorts of questions, but they are probably better asked of the adafruit folks

On Thu, 6 Apr 2017, cobra85ec wrote:

i try but it wont connect....sorry im kinda new to this

[cobra85ec]

im not sure... so its best to buy a PI3>>?

[legotheboss]

@cobra85ec Pi is the easiest and safest option. The Pi stays on your network, so the Sonoffs and MQTT broker as a whole won't be exposed to external attack.

[cobra85ec]

ook.. i got my pi3 and got mosquitto setup and running.... thank u... i get msg when light turn on and off.. but how to i publish a comand to turn light on and off

[davidelang]

what home automation software are you using? you can also use raw mqtt tools (mqtt dashboard for android for example) to subscribe and publishe messages

[cobra85ec]

yes i can pub & sub to topic.... the topic is stat/Light5/POWER on android im using mqtt dash

[davidelang]

sending that topic to the mqtt server will have no effect on the sonoff, because it isn't looking for stat/ messages, it's looking for cmnd/ messages

On Sat, 8 Apr 2017, cobra85ec wrote:

yes i can pub & sub to topic.... the topic is stat/Light5/POWER on android im using mqtt dash

[cobra85ec]

so what should the comand look like.... mosquitto_pub -d -t cmnd/Light5 -m "power on" ..?

[davidelang]

please read the wiki, specificially the commands page https://github.com/arendst/Sonoff-Tasmota/wiki/Commands

[cobra85ec]

i got it now thx...mosquitto_pub -d -t cmnd/Light5/POWER -m "on"

[dummylabs]

I believe this is very useful to have alternative MQTT broker settings. In my setup I have local MQTT broker on my Raspberry Pi (which SD card is not most reliable thing in the world) and reserve MQTT broker somewhere in the cloud. Having alternative broker, home devices does not depend on internet connectivity most of the time and continue working if Raspberry Pi is offline due to corrupted SD card (internet connection should be alive).

How should the second MQTT broker be handled? As a backup, if the first one does not answer or in parallel to be connected and receiving messages from both.

1. It should work as a backup. When main MQTT broker is offline, client should switch to alternative broker after some timeout/reconnection attempts.
2. Clients should try to switch back to main broker if reserved broker become unavailable.

Don't think it is necessary to support automatic back switch to main broker while client is connected to reserved broker as it's resource consuming feature which can be done manually (i.e. by resetting client or temporary switching off reserved MQTT broker). I don't even see problems if some clients are connected to main broker and others to reserved broker as soon as those are bridged.

[pnuding]

Regarding cobra85ec's comment earlier - I tried connecting to Adafruit's io.adafruit.com broker, and I get repeated

00:52:19 MQT: Attempting connection... 00:52:19 MQT: Connected 00:52:20 MQT: trafficlight1/LWT = Online (retained) 00:52:20 RSL: trafficlight1/cmnd/POWER = 00:52:20 MQT: Attempting connection... 00:52:21 MQT: Connected 00:52:21 MQT: trafficlight1/LWT = Online (retained) 00:52:21 RSL: trafficlight1/cmnd/POWER = .... until the server eventually blocks me for a few minutes. There are no other clients connected, especially not using the same client id.

Connecting the same setup to my own mosquitto works fine, strangely

[davidelang]

do they require encryption? (they should)

[stefanbode]

There was a bug in TASMOTO some time ago regarding the fingerprint verify. This causes a reconnect of the client and might be a problem with adafruit. But I think this was fixed. Can you take a look into your mosqitto log, also using TLS please and check if there is a disconnect and reconnect. Just for testing you can also use my build. This works for sure with TLS. Just look at my fork of TASMOTO.

[raf1que]

Hi @pnuding - did you ever manage to get tasmoto working with adafruit? If so, advice appreciated

[yashildoongoor]

@raf1que have been able to make it work with adafruit ? The problem is the payload

[ghost]

If you have a concern about Mosquitto crashing, you can set up a watchdog. It will create a heartbeat script, and if it down't get a response from the service, it restarts the service.

[ascillato2]

See #2937

[darkez]

I solved the issue updating the mqtt server ip in the router. router: 10.0.0.1 mqtt_server_1: 10.0.0.2 <- main mqtt_server_2: 10.0.0.3 <- backup

mqtt_server_1 is the main one but can be offline for maintenance purposes , mqtt_server_2 checks continuously if mqtt_server_1 is reachable, when it isn't, it sends to router the update command.

if you have a fritzbox is very easy to tell it to associate an hostname to an ip with a python script.

In this way the tasmota device can just use a fixed hostname, the router redirects the commands to the active device.