I experience a similar issue. I get frequent timeout warnings - but have no reason to believe my broker has issues. The systems behaves normal and all mqtt clients get the data just fine.

I think it is logged in to your mqtt broker successfully, but Uptime Kuma don't receive topic response within 40 seconds.

I had the same issue, and I just found out that the topic part is case-sensitive. Perhaps this is the issue for yourself as well. Unfortunately, the “error” message from Kuma was not helpful at all. “Timeout” keeps me questioning if the connection works at all.

@louislam I don't think that's the case here. I tried subscribing and kept sending a message to the topic to keep it updated and still got the timeout error.

@buliwyf42 the topic case matches exactly what's on the broker. I don't think that's the case here.

• I increased the test interval to 120s and I don't get any more errors. Before I got either a message with the topic value - or with the timeout error. Now I get the availability but no ping value and therefore the graph is empty.

We are clearing up our old issues and your ticket has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 7 days.

Maybe the issue is not really an issue: If your topic is not updated within the timeframe of the kuma update interval - the test will fail.
Yet the mqtt broker might be happy and alive - so I am not sure what to suggest.

We are clearing up our old issues and your ticket has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 2 days.

This issue was closed because it has been stalled for 2 days with no activity.

Ok this issue is Close but I have the same Timeout if I configure 2 MQTT Task with the same MQTT Server. If I deactivating one of them, no timeout issue, but when both are active the timeout is occur. The MQTT Server is the Node-Modul from https://flows.nodered.org/node/node-red-contrib-aedes - is this a new perspective for this issue or should I open a new one?
THX, Alex

@AleksCee Feel free to open a bug issue if it is reproducible.

The current implementation is here:

FWIW, I was using a wildcard (+ or #) as a topic, to check if any sensor was sending data.

MQTT Monitor was connecting, and receiving messages. It still failed with TIMEOUT because of this check messageTopic === topic: https://github.com/louislam/uptime-kuma/blob/master/server/monitor-types/mqtt.js#L104

sensors/+ isn't exactly sensors/xyz, so this condition was never true. I'm not sure why this check is here. If a message is received while the client is subscribed to a topic, its topic must be correct.

@EricDuminil

If a message is received while the client is subscribed to a topic, its topic must be correct.

It is very helpful for me. Thank you

FWIW, I was using a wildcard (+ or #) as a topic, to check if any sensor was sending data.

MQTT Monitor was connecting, and receiving messages. It still failed with TIMEOUT because of this check messageTopic === topic: https://github.com/louislam/uptime-kuma/blob/master/server/monitor-types/mqtt.js#L109

sensors/+ isn't exactly sensors/xyz, so this condition was never true. I'm not sure why this check is here. If a message is received while the client is subscribed to a topic, its topic must be correct.

I hit the same issue. Wildcards are not possible.

I simply removed the if (messageTopic === topic) check, and MQTT monitor worked perfectly fine with wildcards, both in 1.23.15 and beta2.

sensors/#, sensors/+/info received messages and the monitor was green. If I replaced the topic with an incorrect one, e.g. typo/# or #/info, no message was received, the monitor timed out and was red.

AFAICT, it shouldn't change the behavior for topics without wildcard.