Wiznet makers

A Meter Reader with Two Independent Jobs

Safina Putri Tarigan shares an undergraduate thesis implementation that reads an ABB M1M20 power meter through W5500 Ethernet, then hands electrical measurements to an MQTT publishing loop. The ESP32 firmware separates these jobs with FreeRTOS, an operating system for scheduling embedded tasks, and a queue that carries samples between them. The practical question is how to keep meter acquisition and network publication organized when each operation has its own waiting time.

The project repository was shared in September 2026. Tarigan describes the thesis period as October 2025 through July 2026 in a public engineering profile, which also describes earlier ESP32 power-meter monitoring work. For this thesis, the author reports testing sampling frequencies from 1 to 10 Hz and studying delay, round-trip time, jitter and processor utilization.

Generated illustration: electrical measurements entering an ESP32 telemetry gateway.

What the Meter Sends

Modbus TCP lets a controller request values from numbered registers over an Ethernet network. The firmware acts as the requesting client and uses function code 0x03 to read the ABB meter. The implementation collects four quantities and converts register integers into engineering units before placing a sample in the queue.

The distinction between a meter capability and a selected register matters here. In the ABB M1M communication manual, 0x5B02 identifies L1 phase voltage and 0x5B10 identifies L1 current. Those are the voltage and current channels chosen by this firmware. Frequency comes from 0x5B32, while 0x5000 supplies imported active energy.

Voltage uses two registers at 0.1 V per count; current uses two at 0.01 A per count. Frequency occupies one register at 0.01 Hz per count, and imported energy occupies four at 0.01 kWh per count. The payload therefore gives a compact L1 electrical snapshot plus frequency and accumulated energy, rather than every available meter channel.

Generated illustration: the four quantities selected by the firmware.

Where W5500 Fits

The Ethernet initialization configures W5500 on the ESP32 SPI2 peripheral at 10 MHz. The connection uses GPIO19 for MISO, GPIO23 for MOSI, GPIO18 for clock, GPIO15 for chip select and GPIO4 for the interrupt. ESP-IDF attaches the Ethernet driver to a network interface, and the Modbus task exchanges requests and responses through a TCP socket.

The W5500 supplies the wired connection to the meter network. The selected Espressif driver transfers Ethernet frames into the ESP32 network stack; the application runs its Modbus and MQTT logic on the ESP32. This distinction helps a reader follow which component handles physical networking and which component schedules the telemetry work.

The firmware also starts ESP32 Wi-Fi. MQTT uses the configured broker address through the ESP32 networking stack, so adapting the project includes planning the local meter subnet and the broker route. The published source does not assign the MQTT socket to a particular interface.

A Queue Between Acquisition and Publication

The Modbus task is explicitly pinned to Core 1. Each queued sample contains voltage, current, frequency, energy and a timestamp taken before the register reads. A separate application loop waits for queued data, formats a JSON message and publishes it to the broker. The queue is created with space for 100 samples.

This arrangement separates two kinds of waiting. Meter polling can wait for a Modbus response, while MQTT publication can wait on network activity. Espressif documents that esp_mqtt_client_publish() sends in the calling task and can block. A queue gives the polling task a defined handoff point instead of making the entire acquisition sequence depend on one shared loop.

Generated technical diagram: the queue separates the producer and consumer.

The queue remains a finite memory buffer. The firmware waits briefly when sending a sample to it and provides no persistent store for disconnected operation. For an adaptation, the useful design decision is therefore how to handle a full queue or a lost broker connection, alongside choosing a sampling interval.

Reading the Acknowledgement Clock

MQTT is a publish-and-subscribe protocol: a device sends a message to a broker, which distributes messages to interested clients. This project publishes measurement messages at Quality of Service 1, which uses a broker acknowledgement. The acknowledgement gives the firmware an observable event at the other end of a publish operation.

The firmware records two starting points: the beginning of polling and the beginning of publication. When ESP-MQTT raises its published event, the code subtracts each starting timestamp from the current monotonic time. One interval spans polling through acknowledgement; the other spans publication through acknowledgement. A sequence identifier connects the reported acknowledgement metrics to the corresponding sample.

Generated technical diagram: two starting points share the broker acknowledgement endpoint.

These intervals describe progress to the MQTT broker acknowledgement. Database insertion and dashboard refresh happen farther downstream. Tarigan describes a monitoring chain of HiveMQ, Telegraf, InfluxDB and Grafana, plus a separate FastAPI control service. The public repository currently shares the embedded firmware; the backend components and numerical test results remain outside that release.

A Useful Firmware Study

The project offers a concrete study of register decoding, task separation and timestamp placement around network operations. Readers investigating similar architecture can also explore Modbus_MQTT_module, a separate W5500 and FreeRTOS project that combines protocol tasks with stored network settings. Tarigan's implementation focuses more narrowly on electrical samples and their acknowledgement timing.

FAQ

Q. What does W5500 do in this project? W5500 provides Ethernet connectivity for the ESP32 meter interface. The firmware reads the ABB meter using Modbus TCP.

Q. Which electrical measurements are included? The code selects L1 voltage, L1 current, frequency and imported active energy. Other meter registers can be selected when adapting the acquisition logic.

Q. Why place a queue between the tasks? The queue gives meter polling and MQTT publication separate execution paths. Its 100 slots provide bounded buffering between those paths.

Q. Does the measured delay include Grafana rendering? The timing endpoint is the MQTT broker acknowledgement. Grafana rendering and database ingestion occur downstream of that endpoint.

Q. Is the complete monitoring deployment included? The repository shares the ESP32 firmware. Reproducing the experiment also requires the meter configuration, an ESP-IDF build setup and the separately described monitoring services.