MQTT Broker plugin needs often restarts

[MarcoGT]

Hi all,

I am using this plugin together with the Zigbee2MQTT and ShellyNGMQTT plugins; I often see that my automations are not triggered, the only solution is to restart the MQTT Broker; is it a known problem?

Thanks
Marco

[FlyingDiver]

It's been reported, but I've never been able to nail down a cause. And it doesn't effect everyone. You can schedule a regular restart of the plugin or use a different broker.

[MarcoGT]

Yes, already had a restart once a day, but does not help (not enough); I also tested a restart every 2 hrs, same problem.
If I want to switch to a new broker, need to update the info in the MQTT connector device and update every single device where I added the broker info, right?

Thanks

[FlyingDiver]

If I want to switch to a new broker, need to update the info in the MQTT connector device and update every single device where I added the broker info, right?

If you update the Connector device to refer to the new broker, then you shouldn't need to change anything else that uses that Connector. Shim devices only reference a Connector, not the actual broker.

[MarcoGT]

Yes, you are right.
Anyhow, the new Broker now runs on the same machine as the previous one (Indigo Server), that means ip/port are the same, everything is working fine.

Thanks

[SMUSEBY]

I just posted the following on another thread.

My 'solution' to the lack of reliability of MQTT/Shelly controls, is to initiate all commands with a reload of the broker plug-in and delay the commands 1 sec . It works, but it's awkward. I'm hopeful that running the MQTT broker independent of Indigo is a better solution.
I googled 'Mosquito' and found "Eclipse Mosquito". Is this the broker referred to? Could you please provide a little information on how to deploy it with Indigo?

I am using a combination of Lutron keypads and Shelly devices to be rid of the Insteon devices which are not only unreliable, but fail - especially the keypads. The Shelly devices are great and always work with the Shelly app. Indigo is my preferred means of management, but I have the same issue you reported.
I arrived at my Indigo/Broker plug-in solution after scheduling restarts every day, every hour, and finally giving up after every 5 minutes also failed to solve the problem. Experimenting, I discovered that the 1 second delay works. What is peculiar is that if a have a series of MQTT commands in an Action Group, one reload is sufficient. It's mysterious, and has been driving me crazy for over a year. I'd love a more robust and straightforward solution.
I'd be very grateful for any information on how you made the independent broker work. Warning -my IT expertise is limited to what I've learned with my guess-and-check methodology.
Bob

[whmoorejr]

I've never been able to nail down a cause. And it doesn't effect everyone.

I'm not sure if this will help with your troubleshooting or not. I've noticed a triggering anomaly that seems to be on the shims side. I see it happen when there is a slight overlap with triggers. When I disable (uncheck) the extra trigger, the main triggers resume and I start seeing the matches being made in the log again.

This may still be attributed to my limited knowledge of MQTT.... but I've been reading up quite a bit to get a better handle on things.... This is my trigger breakdown:

For a physical device, I have a trigger specific to that device and a trigger that is set for a specific topic message that can come from any device:
Physical Device : PD1.

Specific trigger: Match Owntracks, Match PD1, Match Any, End (The data I want is under that 3rd topic layer with no 4th topic)

General trigger: Match Owntracks, Match Any, Match Any, Match Event, End. (The data I want is under the 4th topic layer from any device)

Sometimes this works just fine, sometimes the specific triggers stop all together. A reboot of the plugins will sometimes cure it, but without a reboot or aything, if I disable the general trigger, all my specific triggers start going again.

My guess is it's me, so I'm still messing around with it... but in case it is part of something else affecting others.... this is what I was able to isolate.

[FlyingDiver]

I'd have to see a debug log on the connector plugin to see what's really happening. If the message is arriving at the connector at all, then the broker is working.

[whmoorejr]

I'll collect some logs. It typically takes about 24 hours for triggers to stop from my experience so far... so I re-enabled all the general triggers and letting it run. I'll post back in a day or two with details.

[FlyingDiver]

You might also want to get an MQTT client running as well, so you can cross check what the connector is getting with what the client is getting. Something like MQTTX.

[whmoorejr]

As of this morning, my "match" triggers are all still working.

I do have a shim trigger that isn't working... (assuming I set it up correctly)

Type: MQTT Shims Event
Event: Device Updated
Settings: MQTT-All Events
Condition: Always

Where "MQTT-All Events" is a shim that is updated whenever their is a publication "owntracks/+/+/event"

The shim "MQTT-All Events" last update was this morning at 07:13:00.

In the log, I see where the Trigger, MQTT Match All Events is matched and fires, but there is no other trigger fire.

I may not need this trigger. Can I add the action part of this trigger to the "match" trigger? Basically, it is a script that I want to run whenever there is a publication (from any physical device) to the subtopic "/event".

[FlyingDiver]

Well, you've managed to confuse the heck out of me. In any case, this thread is about the broker hanging and needing a restart. If you want to discuss a trigger issue for the connector or shim devices, please open a new thread.

The bottom line is, the broker itself is basically a black box. It's a function in an MQTT library that I just start and let it run forever. If it fails, it's supposed to exit and then I can restart it. If it silently hangs internally, I have no way to know that and can't force a restart. Unfortunately, development seems to have halted on this library. So it might never get updated. It works well enough for my purposes, and probably for others with low MQTT traffic (I only have one MQTT device at this time). Others should use Mosquitto.