How do I monitor an external broker?

Brain not working today and I know this should be relatively straight forward but how do I monitor my Synology NAS Docker Eclipse Mosquitto status? Watchtower recently upgrade the container and the broker went down but I didn’t know. I need to create a notification in these scenarios.

The MQTT config reports hass/status (offline/online) but that is for HA itself. I need to know if the broker dies while HA is up.

You could setup a MQTT Sensor (Binary or otherwise) to listen to the $SYS topic. This is what the $SYS topic exposes on a mosquitto instance:

Using something like that, if the broker does go down, then you could have HA notify you. However, I would go with something like Portainer, Prometheus, or even the Docker API. My personal choice is Prometheus as it’s robust enough to monitor dozens of containers in a pretty small footprint.

Thanks for the reply. One would assume that any topic updates on $SYS would actually die if the broker goes offline so I’d have to set up a sensor around that? I’ve tried monitoring $SYS/broker/clients/# and get nothing so I’m assuming there is some trick to monitoring broker system messages?

It might be easier just to group a bunch of my MQTT clients together and create a binary sensor that triggers if they all go offline indicating a network or broker issue that requires further investigation?

$SYS/broker/clients/# should work as $SYS is still a standard topic for MQTT. Can you post the sensor config?

Indeed, it is a standard, but is it possible to create a sensor out of a wildcard topic ?

Honestly? No idea. I’ve not tried it. However, there is the $SYS/broker/clients/total topic that would work well for a numeric sensor.

People that know more than me say no:

https://www.hivemq.com/blog/why-you-shouldnt-use-sys-topics-for-monitoring/

3 Likes

I know that article well as we run multiple MQTT clusters for work. While the article is correct, those use cases are mostly for production/enterprise environments. To be fair, outside of the most hardcore of home automation enthusiasts, no one is running multi-tenant, MQTT clusters in their home environment; Most often they’re running a single instance, most likely in a docker container. I might be one of the outliers as I run a small, load-balanced MQTT cluster behind a haproxy instance hosted on my opnSense box.

For the home user looking to track if their broker is online and responding, and/or wanting to see what clients are doing, $SYS topics are fine for that. It’s when you start getting into multi-tenant, enterprise level clusters that the $SYS topics fail as they aren’t scalable across the cluster.

Thanks. I’ve tried subscribing to $SYS/broker/clients/# but the subscribe button is greyed out in MQTT.fx when $SYS is added at the front as I’m assuming it doesn’t recognize/support ‘$’ as a valid topic name.

My approach has been to create groups with six MQTT entities that are spread around the house; two from each of the three access points. I’ve got four groups in total; one for each of my three AP’s and a ‘master’ group that contains the other three sub groups.

I have custom SSID overrides on my AP’s so devices don’t roam to weaker AP’s so it’s easy to assign two MQTT entities that are connected to a specific AP. In that way, I can report if the problem appears to be AP related (after a rogue UniFi update) or whether multiple devices connected to multiple AP’ are all offline indicating a possible broker offline issue.

I’ve just created half a dozen binary_sensors like the examples below as so far it seems to be working well.

binary_sensor:
  - platform: mqtt
    name: "Lounge Dimmer MQTT Status"
    state_topic: "shellies/shellydimmer-DB2D26/online"
    value_template: "{{ value }}"
    payload_on: "true"
    payload_off: "false"
    device_class: connectivity

  - platform: mqtt
    name: "Sonoff POW Washer MQTT Status"
    state_topic: "tele/washer/LWT"
    value_template: "{{ value }}"
    payload_on: "Online"
    payload_off: "Offline"
    device_class: connectivity
1 Like