Hi everyone,

I'm currently working on developing a protocol converter that reads data from Modbus RTU slave devices (via RS485) and sends the collected data to a cloud server using HTTP POST over GPRS or Ethernet.

I have successfully implemented Modbus RTU communication and can read holding/input registers using Function Code 0x03/0x04. I also have the HTTP client code working (sending JSON/XML payloads). However, I'm facing challenges in mapping the Modbus RTU data to the HTTP payload structure.

My Questions:

1. What is the standard approach or best practice to map Modbus RTU registers (e.g., 40001, 40002) to HTTP parameters or JSON fields?
   • For example, if I read two registers representing temperature and humidity, how should I define them in the outgoing HTTP request?
2. Which HTTP parameters are typically required from the server side to do this mapping effectively?
   • Do I need:
     • Base URL (e.g., http://server.com/api/data)
     • HTTP method (GET/POST)
     • Expected fields or keys (e.g., temperature, humidity)
     • Content-Type (e.g., JSON or XML)
     • Headers?
3. How should I handle scaling, byte-order (endianness), and data type conversions (e.g., Modbus floats or 16-bit integers → JSON numbers)?
4. Is there any standard format or user manual I should follow for mapping Modbus registers to HTTP fields for such converters?

 

I apologize in advance because this is going to sound harsh.

You're a new member here and created several threads on this topic (here as well as on Stack Overflow), looking for someone to do your work for you. The engineering challenges you're facing are the "secret sauce" for protocol converter (gateway) manufacturers. Anyone that has the knowledge to answer these in-depth questions, is not just going to offer it up to you. The magic behind creating sensible mappings and providing all the features required for converting between different protocols is what sets protocol converter manufacturers apart from one another. These types of engineering decisions are the life-blood of these companies. Obtaining the knowledge to properly make these decisions requires months of research into the protocols, most commonly used features, field usage, markets, competing products, etc.

I do wish you luck on your ambitious endeavor. However, I'm afraid you're going to need to make these decisions yourself if developing a protocol converter yourself is the path you choose to take.

If instead you wish to use an existing product or software for this conversion, you can take a look at the following options:
https://www.adfweb.com/Home/products/Modbus_HttpRest.asp
https://store.chipkin.com/products/http-data-to-bacnet-and-modbus-quickserver-gateway
https://openautomationsoftware.com/knowledge-base/how-to-access-modbus-data-rest-api/
https://github.com/jpirko/restmbmaster