Modbus Device Monitoring Scenario

Scenario Description

Periodically collect Modbus RS485 slave device data (temperature/humidity/air quality) via poll trigger. Collection results are automatically reported to the platform via MQTT and displayed on an OLED screen.

Required Peripherals

Peripheral	Type	Description
uart_rs485	UART(1)	RS485 communication port
modbus_sensor	MODBUS_DEVICE(51)	Modbus sensor device
oled1	LCD(36)	OLED display (optional)

Complete Configuration Process

Method 1: Web Interface Configuration (Recommended)

This scenario requires first configuring Modbus RTU serial port and slaves, then creating poll collection, MQTT reporting, and OLED display actions in peripheral execution.

Area	Field	Example Value / Status
Status Overview	Risk Level	Low
Status Overview	Enabled Tasks	0
Status Overview	Timeout Rate	0%
Status Overview	Total Polls / Success / Failed / Timeout	0 / 0 / 0 / 0
Basic Config	Enable Modbus RTU	Enabled
Basic Config	Peripheral Config Selection	Select configured RS485/UART peripheral
Basic Config	Transfer Type	Passthrough (Raw HEX frames)
Basic Config	DE Pin (RS485)	14

Sub-device Name	Type	Slave Address	Device Info	Enable	Actions
Temp/Humidity	Collection	2	FC04 @0 x2 [2 mappings]	ON	Edit / Map / Delete
PM25-10	Collection	1	FC03 @0 x2 [2 mappings]	ON	Edit / Map / Delete
Weather Louver	Collection	4	FC03 @500 x8 [6 mappings]	ON	Edit / Map / Delete

Step 1: Configure Peripherals

💡 Prerequisite: Modbus sensor device and OLED display must be configured in advance (refer to examples/54-modbus-sensor-devices.md)

Required Peripherals:

• uart_rs485 - UART(type: 1) - RS485 communication port
• modbus_sensor - MODBUS_DEVICE(type: 51) - Modbus sensor device
• oled1 - LCD(type: 36) - OLED display (optional)

---

Step 2: Configure Peripheral Execution Rules

Rule: Poll Modbus Sensor Every 5 Minutes

1. Click Peripheral Execution in the left menu

2. Click the Add Rule button

3. Fill in basic configuration:

   • Rule Name: Collect Environment Quality
   • Report Data: ✅ Enabled (auto-report collection results)
   • Enable: ✅ Enabled

4. Configure trigger:

   • Trigger Type: Select Poll Trigger
   • Poll Interval: 300 (300 seconds = 5 minutes)
   • Response Timeout: 1000 (1000ms)
   • Max Retries: 2
   • Request Interval: 100 (100ms)

5. Configure actions (3 actions needed):

   Action 1: Poll Modbus Task 0

   • Action Type: Select Modbus Poll
   • Target Peripheral: Enter modbus-task:0 (fixed format)
   • Task Index: [0]
   • Execution Delay: 0

   Action 2: Poll Modbus Task 1

   • Action Type: Select Modbus Poll
   • Target Peripheral: Enter modbus-task:1
   • Task Index: [1]
   • Execution Delay: 200 (200ms delay to avoid bus conflicts)

   Action 3: OLED Display Data

   • Action Type: Select OLED Display
   • Target Peripheral: Select oled1
   • Display Template:

     #EnvMonitor
     Temp: ${modbus_temp.value}°C
     Humidity: ${modbus_humi.value}%
     CO2: ${modbus_co2.value}ppm

   • Execution Delay: 500 (500ms delay to wait for data collection to complete)

6. Click the Save button

💡 Tip:

• targetPeriphId format is fixed as modbus-task:N, N is device index
• syncDelayMs must be set between multiple Modbus actions to avoid bus conflicts
• When "Report Data" is enabled, collection results are automatically reported via MQTT

---

Method 2: JSON Configuration File Import

Communication Parameter Description

Parameter	Value	Description
pollResponseTimeout	1000	Maximum 1 second wait for slave response
pollMaxRetries	2	Retry 2 times after failure
pollInterPollDelay	100	100ms interval between two requests

Data Flow

1. Poll trigger fires every 300 seconds
2. ACTION_MODBUS_POLL collects data from task:0 and task:1 sequentially
3. Collection results are stored in sensor cache
4. OLED display action references cached data to update screen
5. reportAfterExec: true causes collection results to be reported via MQTT

Precautions

1. Modbus Ready: Poll trigger automatically checks if Modbus is ready; skips if not ready
2. Action Interval: Set syncDelayMs between multiple MODBUS_POLL actions to avoid bus conflicts
3. Failure Backoff: No retries within 30 seconds after communication failure to avoid blocking the system
4. Async Execution: Modbus polling executes in FreeRTOS async tasks, not blocking the main loop