Multi-protocol reader for ESP32-S3-ETH with support for RS-485 and M-Bus

Provided by the customer:

1. Breadboard

2. ESP32-S3-ETH

3. RS-485 TTL modules HW-519 — 4 pcs.

4. Multiplexers: HW-178 or CJMCU-4051

5. M-Bus master to TTL converter

6. DC-DC converter 24V → 5V

7. Power supply 24V 3A

8. Temperature sensor XY-MD02

9. 2 water meters with M-Bus overlays

10. Sharky 775 heat meter with M-Bus module

11. NIK meters:

    1. NIK 2100 AP6T.2200.MC.11

    2. NIK 2307 0.5s ART T.1620.MC.22

12. Manufacturer documentation on the RS-485 protocol (for meter operation)
    
    

1. Hardware platform:

1. Controller: ESP32-S3-ETH

2. Available UARTs: 3 hardware UARTs

3. Converters:

   1. 5 x RS485-TTL (HW-519 or compatible)

   2. 1 x M-Bus-TTL Master

4. Multiplexer: HW-178 or CJMCU-4051

5. Additional modules: DC-DC, temperature/environment sensors
   
   

2. Connection:

1. One UART (UART1 or another available) of ESP32 is used for reading from 6 channels via the multiplexer.

2. The multiplexer switches access to one of the 6 converters at any given time.

3. Multiplexer switching logic is implemented through 3 GPIO (S0, S1, S2).
   
   

3. Main firmware functionality:

3.1. M-Bus (1 channel)

1. Scanning devices on M-Bus: identifying active addresses

2. Polling each M-Bus device by its unique address (identifier)

3. Collecting and parsing consumption values or other indicators
   
   

3.2. RS-485 (5 channels)

1. Scanning each of the 5 RS-485 channels for devices (can be implemented via polling known addresses or NIK protocols)

2. Polling each device on the channel (address, model)

3. Supporting requests for NIK 2100 and NIK 2307 (details in notes)
   
   

3.3. Generating output data

All results should be structured in JSON format, for example :

{

  "data": [

    {

      "device": "NIK 2100 AP6T.2200.MC.11",

      "id": "1234567890",

      "type": "rs485-1",

      "value": "128.45",

      "timestamp": "2025-05-05T12:34:56"

    }

    // ...other devices

  ]

}

The final format will be determined during collaboration

4. Firmware requirements:

1. Output file in .ino format for Arduino framework (for PlatformIO or Arduino IDE)

2. Implement polling loop:

   1. Polling interval — configurable (e.g., once every 5 minutes)

3. Store JSON results in RAM (output via Serial, UART, or Ethernet)

4. Timestamps — via RTC or NTP (if needed)
   
   

5. Development result:

1. Ready and tested .ino firmware file that:

   1. polls all 6 channels (M-Bus and RS485-1…5)

   2. generates valid JSON with device data

   3. outputs JSON via Serial

      2. Firmware documentation

Notes:

Additional information regarding RS-485 operation for NIK meters:

NIK 2100 AP6T.2200.MC.11 and NIK 2307 0.5s ART T.1620.MC.22 use a protocol based on IEC 62056-46, -53, -61, -62 standards, which involves HDLC framing and COSEM/DLMS data structures.

Communication with the meter includes stages:

1. Initialization of connection (sending SNRM frame and receiving UA response).

2. Authorization via AARQ packet with password (user, operator, or administrator).

3. Processing AARE response to verify authorization.

4. After authorization — exchanging GET requests using OBIS codes to read indicators.

5. Ending session with DISC packet.

• Authorization uses a 16-byte password transmitted in the AARQ field. Access type (user/operator/admin) is set in the user ID.

• After 5 unsuccessful authorization attempts with the same ID, access is blocked for 30 minutes.

• All packets are wrapped in HDLC structure with CRC checksums (calculated with 16-bit CRC, algorithm provided in the documentation).

• Meter addressing is done in HDLC format based on serial number (conversion algorithm also provided in the documentation).

• Note that not all meters may respond to address scans — in such cases, polling by a known list of serial numbers is possible.