Dual RS485 Modbus Gateway Adaptation | Obeita
Delivered project. The completed hardware and software met the customer’s agreed requirements in testing. Specifications for a new project must be agreed separately.
Obeita completed and delivered a dual RS485 Modbus gateway project using an ESP32-C3 architecture. Work ran from customer requirements and contract scope through hardware and software design, physical testing and delivery. The distinguishing integration task was translating separate Modbus RTU data sources into an agreed upstream view without losing the meaning of their registers.
Defining bus behaviour and useful data
The public architecture separates the RS485 buses and provides Modbus TCP mapping and MQTT publishing directions. Each bus has its own serial settings and polling requirements, while the application needs a consistent interpretation of register values. Requirements and contract scoping joined these concerns into the functions to be delivered.
Byte order, register order, data type and engineering scaling are part of that mapping. A floating-point value spread across registers cannot be interpreted from an address alone. Similar integrations also need bounded timeouts, retry counts and scan-time budgets, with separate bus scheduling, so that an unresponsive device does not silently determine the reporting behaviour of the whole gateway.
Combining gateway firmware with local management
Obeita completed hardware and software design for the agreed gateway. The documented management direction includes browser configuration, live data, online writes and OTA development scope. These functions require explicit choices about editable settings, register permissions and update behaviour.
The documented compact hardware uses ESP32-C3 and MAX485ESA transceiver paths. TPS5430DDA converts 12 V to 5 V, while AMS1117-3.3 supplies the logic rail. Rail mounting and an external 2.4 GHz antenna make field wiring, termination and access to configuration controls relevant to the integration.
Keeping adaptation and verification specific
For a new application, the device register maps should be paired with the requested Modbus TCP or MQTT fields before polling and mapping are finalised. Online writes need clear permissions. Configuration retention, interrupted-update recovery and bus-isolation behaviour need explicit requirements if they are included in the new scope.
Documented architecture and configuration
The table records the documented architecture, configuration directions and selection boundaries for this case. Optional items, firmware-dependent choices and expansion directions are not independent guarantees that every listed option was delivered. The agreed project hardware, software and functional scope define the actual delivery.
| Item | Configuration |
|---|---|
| Controller | ESP32-C3 |
| Field buses | 2 independent RS485 / Modbus RTU channels |
| Upstream services | Modbus TCP mapping and MQTT publishing |
| Data handling | Byte-order conversion and engineering scaling |
| Management | Web setup, live data, online writes, OTA development scope |
| Enclosure direction | 82 × 54 × 32 mm, rail mounted |
Delivery outcome and test scope
The contracted gateway hardware and software were completed and delivered. Physical functional testing confirmed that the delivered project met the customer’s requirements.
This outcome applies to the agreed functions. It does not publish a scan-rate or capacity guarantee, establish compatibility with every register map, or claim specific interrupted-OTA and disconnected-slave test results. The management items remain subject to their documented development scope.
Discuss a similar project
Send Obeita the device lists and register maps for both buses, required reporting behaviour, target TCP or MQTT fields, and any online-write or update requirements. These inputs define a similar gateway around the data and management behaviour the application actually needs.