Wiznet makers

Cover image generated by Gemini.

ESP32-C3 + W5500 + CANbus: CAN ↔ MQTT Bridge Board

This project combines an ESP32-C3, a W5500 (wired Ethernet), and a CAN transceiver on a single board, and uses it as a bridge (gateway) between CANbus and an MQTT broker.
The author states that ESPHome is used mainly for OTA (firmware update) convenience, and the data path is built around MQTT.

Repository:

https://furmwareupdates.com/2025/08/19/esp32-c3-w5500-canbus/

2) Why send CAN data over MQTT?

CAN and MQTT are used in different environments.

• CAN: A communication bus used inside machines (vehicles, robots, industrial equipment), where multiple modules share short messages (ID + data) quickly and reliably.
• MQTT: A messaging protocol running on Ethernet/Wi-Fi networks, where devices publish/subscribe through a broker (server).

In other words, CAN data usually stays inside the machine, while MQTT is a practical way to send data to servers, dashboards, and storage systems.
That is why a gateway is used: it reads CAN messages and publishes them as MQTT topics, and (if needed) converts MQTT commands back into CAN messages and sends them to the CAN network.

3) When is this type of gateway useful?

• When a CAN-based system already exists in the field and you want to build monitoring / logging / alarms on a server
• When you need remote diagnostics and also want to send control/configuration commands
• When it is difficult to modify the existing equipment, and you want to extend it by adding only a gateway in the middle

4) Hardware Architecture

• MCU: ESP32-C3
• Ethernet: W5500 (SPI-based)
• CAN: CAN transceiver
• Additional: An RS485 transceiver was added late, but it is not routed to a connector—only test pads are provided (left for future expansion).

5) How it works (CAN ↔ MQTT)

The system is built around a simple flow: “read CAN → publish to MQTT, receive MQTT → send to CAN”.

CAN → MQTT (publish)

When a CAN frame is received, the payload is converted to a HEX string and published to MQTT topics such as:

• canbus/raw/out/<can_id> : raw output by CAN ID
• canbus/canopen/out/<group>/<node> : the same data is also published using a CANopen-style categorized topic structure

MQTT → CAN (send)

When JSON is received on canbus/in, the firmware parses fields such as can_id and data (HEX string), builds a CAN frame, and transmits it on the CAN bus.

6) Network / firmware setup (ESPHome example)

• In the shared example configuration, Wi-Fi is enabled, and the W5500 Ethernet configuration is commented out.
• The author separately notes that wired Ethernet has been tested.
• The CAN configuration is defined by TX/RX pins and bitrate (example: 250 kbps).

7) Points to highlight compared to similar projects

• The goal is not “CAN testing”, but a clear CANbus ↔ MQTT broker integration.
• The board includes wired Ethernet using W5500, and pin definitions are shown in the configuration (commented).
• MQTT output is provided in both raw and CANopen-style categorized topic formats, which helps downstream systems organize data using topic structure alone.
• EasyEDA project files are provided, so there is a clear path for reproducing / manufacturing the same design.

8) Example applications

• Industrial data collection (OT → IT): publish CAN status/alarm frames to MQTT for monitoring and log storage
• Remote diagnostics / maintenance: observe field data via MQTT, and send control frames back via MQTT → CAN when required
• Test / validation environments: collect CAN messages into a broker to build dashboards, rule engines, or analysis pipelines
• Future expansion: if RS485 is routed to a connector later, the board can be extended into a combined CAN + RS485 gateway (current version uses test pads only)