Skip to Content

← All functionalities

Two-axis solar trackersCentral serverMQTTInfrastructure

One Mosquitto broker to supervise every tracker in the plant

Dozens of trackers reporting position and faults need a single meeting point. This example, from a real two-axis solar tracker deployment, provisions a central Mosquitto MQTT broker on the plant server with a commented setup script: an authenticated listener, persistence, sensible connection limits and the per-plant ID mapping CSVs (mapa_ids_101, mapa_ids_102, mapa_ids_general) that translate every MQTT client ID into a physical row and position in the field.

A locked-down mosquitto.conf

The configuration disables anonymous access, points to a password_file and enables persistence so retained states survive broker restarts. Logging captures errors, warnings and connection events — when a tracker drops off the network, the log timestamps it. Connection and keepalive limits are sized for a fleet of PLCs in the field rather than left at defaults meant for a developer laptop.

Users per role, not per device

Two accounts cover the whole plant: one shared by the tracker PLCs to publish state and subscribe to commands, another for the dashboard and analytics side. Passwords are created with mosquitto_passwd and stored hashed; placeholders in the script mark where real credentials go at deployment. Fewer accounts means simpler credential rotation when maintenance staff changes, with per-device certificates left as a later hardening step.

ID maps that tie MQTT to the field

Topic seguidores/101/3/estado tells you tracker 3 of plant 101 reported — but which physical machine is that? The CSV maps answer it: each per-plant file links local IDs to row and position, and mapa_ids_general consolidates all plants under global IDs for the central dashboard. A flat CSV is auditable by anyone with a text editor, which is exactly what you want during commissioning.

A snippet from the implementation

Straight from the example as deployed on the Central server — copy it freely:

set -e

# === 1. Broker installation ===================================================
apt-get update
apt-get install -y mosquitto mosquitto-clients

# === 2. Main configuration: /etc/mosquitto/conf.d/central.conf ===============
# - Port 1883 on the plant's internal network only.
# - allow_anonymous false: every tracker authenticates.
# - persistence: keeps the last state of each tracker across restarts.
cat > /etc/mosquitto/conf.d/central.conf << 'EOF'
# --- Main listener (plant internal network) ---
listener 1883
allow_anonymous false
password_file /etc/mosquitto/passwd

# --- Persistence of retained messages and sessions ---
persistence true
persistence_location /var/lib/mosquitto/

# --- Logging ---
log_dest file /var/log/mosquitto/mosquitto.log
log_type error
log_type warning
log_type notice
connection_messages true

# --- Conservative limits for a fleet of trackers ---
max_connections 256
max_keepalive 120
View the full working example Get the full project pack

The full example is a complete program — wiring header, setup and main loop — ready to adapt to your application.

Frequently asked questions

Why CSV files instead of a database for the ID maps?

At fleet scale the map changes rarely and is tiny. CSVs are versionable, diffable and editable in the field without tooling. The dashboard loads them at startup; a database becomes worthwhile only with thousands of devices.

How should the topic hierarchy be structured?

The deployment uses seguidores/plant/id/estado for telemetry and seguidores/plant/id/comando for orders. This lets the dashboard subscribe to seguidores/# while each PLC subscribes only to its own command topic.

Should the broker use TLS as well as passwords?

On an isolated plant network, password authentication is the common baseline. If trackers connect across shared or public infrastructure, add a TLS listener on 8883 with certificates — Mosquitto supports both listeners simultaneously.

Related functionalities