ESP32 + RS485/Modbus: โครงสร้างระบบอ่าน Meter และ Sensor อย่างไรให้ถูก

การเชื่อม ESP32 กับ Meter/Sensor ผ่าน RS485 + Modbus RTU เป็น use case ที่มีประโยชน์มากกับ Energy Monitoring, Solar, Smart Farm และ Automation แต่ปัญหาที่พบบ่อยคือรีบ copy wiring/code ก่อนรู้ว่าอุปกรณ์จริงใช้ electrical interface และ register map แบบไหน

โครงที่ควรเข้าใจก่อนคือ:

ESP32 UART
   ↓ TX/RX
RS485 Transceiver
   ↓ A/B bus
Meter / Sensor
   ↓ Modbus RTU
Register data
   ↓
ESP32 software / ESPHome
   ↓
Home Assistant / MQTT / Gateway

1. ESP32 UART ไม่ใช่ RS485 โดยตรง

ESP32 มี UART peripheral แต่ field bus RS485 ต้องมี transceiver/interface ที่เหมาะสม

MCU logic
  ↓
RS485 transceiver
  ↓
Differential bus

อย่าต่อ A/B จาก field device เข้าขา TX/RX โดยตรง

อ่านพื้นฐาน physical layer ที่ RS485 คืออะไร

2. ตรวจว่าอุปกรณ์ใช้ Modbus RTU จริงหรือไม่

คำว่า RS485 บน terminal ไม่ได้ยืนยันว่า protocol คือ Modbus

ต้องตรวจ manual ว่า:

protocol: Modbus RTU หรือ proprietary
baud rate
parity
stop bits
device address range
register map
supported function codes

ถ้า manual ไม่มี register map อย่าเดาว่าจะอ่านเหมือน Meter รุ่นอื่น

3. Wiring ต้องอิง Manual ของทั้งสองฝั่ง

ชื่อขาอาจเป็น:

A / B
D+ / D-
485+ / 485-

convention อาจต่างกันระหว่าง vendor

ดังนั้นต่อจาก manual ไม่ใช่จากสีสายหรือคำว่า A/B อย่างเดียว

และต้องพิจารณา:

common reference/ground ตาม architecture
isolation
shield
surge/transient
termination
cable type

ตาม environment จริง

4. DE/RE Control ของ Transceiver

RS485 2-wire half-duplex transceiver จำนวนมากต้องสลับระหว่าง transmit/receive ผ่าน control pin

concept:

Receive
  ↓
Enable TX
  ↓
Send Modbus request
  ↓
Wait UART TX complete
  ↓
Disable TX
  ↓
Receive response

ถ้ากลับ receive ช้าเกินไป อาจพลาดต้น response

ถ้าปล่อย transmitter ค้าง อาจ block device อื่นบน bus

library/framework มักช่วยจัดการ แต่ต้อง configure pin/mode ตาม hardware จริง

5. Serial Settings ต้องตรงทุกตัว

ตัวอย่าง configuration:

9600 baud
8 data bits
Even parity
1 stop bit

หรืออาจเป็น:

19200 8N1

ค่าจริงต้องมาจาก device manual/configuration

บน bus เดียวกัน device ที่คุยกันต้องใช้ serial parameters ที่ compatible

6. Device Address ไม่ใช่ Register Address

Modbus RTU มี device/server address เช่น:

Meter 1 → address 1
Meter 2 → address 2

ส่วน register address คือข้อมูลภายใน device เช่น voltage/power/energy

อย่าสับสนสองอย่างนี้

7. Register Map คือหัวใจของ Integration

ก่อนเขียน code ต้องรู้:

Function code
Register address/offset
Data type
Length
Scale
Unit
Signed/unsigned
Word order
Invalid/sentinel value

ตัวอย่าง conceptual:

raw = 2305
scale = 0.1
unit = V
→ 230.5 V

หรือค่าหนึ่งอาจใช้ 2 register เป็น float32/uint32

อ่าน semantics ที่ Modbus คืออะไร

8. ปัญหา 40001 / 30001 / Offset 0–1

manual บางเล่มแสดง logical register เช่น 40001 แต่ library ต้องการ protocol offset 0

อย่าแก้ด้วยการบวก/ลบ 1 แบบสุ่ม

ต้องตรวจว่าเอกสารใช้:

reference notation
zero-based offset
one-based numbering
function code แยกหรือรวมในเลข

9. Endianness / Word Order ทำให้ตัวเลขดูมั่วได้

ค่า 32-bit บนสอง register อาจมี word order ต่างกันตาม vendor

อาการเมื่ออ่านผิด:

float ขนาดมหาศาล
ค่าใกล้ศูนย์ผิดปกติ
negative แปลก ๆ
ค่าเปลี่ยนไม่สัมพันธ์กับของจริง

อย่าแก้ด้วยการ swap byte/word จน “ดูสมเหตุสมผล” โดยไม่ยืนยัน manual/test reference

10. Polling Rate ต้องไม่เร็วเกินไป

การอ่านทุก register ทุก 100 ms ไม่ได้ทำให้ระบบดีขึ้นเสมอ

ต้องดู:

baud rate
number of devices
register count
device processing capacity
response timeout
data change rate

Energy Meter ที่ค่าหลักเปลี่ยนเป็นระดับวินาทีอาจไม่ต้อง poll หลายสิบครั้งต่อวินาที

polling เร็วเกินไปอาจเพิ่ม timeout/collision/load โดยไม่เพิ่มข้อมูลที่มีประโยชน์

11. Group Register Reads เมื่อเหมาะสม

ถ้า register ต่อเนื่องกันและ device รองรับ การอ่าน block เดียวอาจ efficient กว่า request ทีละค่า

แต่ต้องไม่อ่านข้าม invalid/reserved range โดยไม่ดู manual

12. Timeout / Retry ต้องมีขอบเขต

ถ้า device ไม่ตอบ:

request
  ↓ timeout
retry 1
  ↓ timeout
retry 2
  ↓
mark unavailable / continue next device

ไม่ควร loop retry ไม่สิ้นสุดจน node อื่นบน bus หยุดทั้งหมด

ควรมี:

timeout
retry limit
backoff
offline state
error counter

13. Data Freshness สำคัญกว่า Last Value

สมมติอ่าน Power ล่าสุดได้ 3.2 kW

หาก Meter offline 20 นาที ค่าเดิมไม่ควรถูกใช้เป็น realtime power ต่อ

ควรมี:

value = 3.2 kW
age = 20 min
status = stale/unavailable

โดยเฉพาะเมื่อข้อมูลไปสั่ง Battery/EV/Load control

14. Read ก่อน Write

เริ่ม integration ด้วย read-only telemetry ก่อน:

Voltage
Current
Power
Energy
Temperature
Status

เมื่อ mapping ถูกและ data verified แล้วค่อยพิจารณา write

การเขียน:

start/stop
setpoint
export limit
mode

มี consequence สูงกว่าและต้องยืนยัน documentation/permission/safety boundary

15. ใช้ ESPHome ได้ไหม

ได้ ถ้า use case อยู่ใน capability ของ component

ESPHome มี Modbus และ Modbus Controller components สำหรับอ่าน/write entity ตาม configuration

เอกสาร:

แต่ ESPHome ไม่รู้ register map vendor เอง

เรายังต้องกำหนด address, register type, value type, scaling และ write behavior ให้ถูก

16. ESPHome vs Custom Firmware

ESPHome เหมาะเมื่อ:

integration pattern มาตรฐาน
register map ชัด
Home Assistant เป็นปลายทางสำคัญ
polling/control ไม่ซับซ้อนมาก

Custom firmware อาจเหมาะเมื่อ:

protocol variation ซับซ้อน
timing เฉพาะ
data processing/queueing มาก
gateway มีหลาย protocol/service

อ่านภาพรวมที่ ESPHome คืออะไร

17. หลาย Device บน Bus เดียว

Architecture:

ESP32 Gateway
  ↓ RS485
  ├─ Meter #1 address 1
  ├─ Meter #2 address 2
  └─ Sensor #3 address 10

Controller poll ทีละ device ตาม schedule

ต้องไม่ใช้ address ซ้ำและ topology/termination ต้องเหมาะสม

18. จาก Modbus ไป MQTT/Home Assistant

อย่า expose raw register number ไป application หากไม่จำเป็น

Gateway ควร normalize เช่น:

Register 40123 raw 3250 × 0.01
        ↓
site/pump/pressure_bar = 32.50

หรือ entity:

Main meter active power = 4.2 kW

ทำให้ downstream ไม่ผูกกับ vendor map

19. Energy Monitoring Example

3-phase Energy Meter
      ↓ RS485 / Modbus RTU
ESP32 / ESPHome Gateway
      ↓
Normalized V/A/kW/kWh
      ↓
Home Assistant / MQTT
      ↓
Load Profile Analyzer / EMS

ข้อมูล Meter ควรแยก per-phase และ total ตาม device capability ไม่ใช้วิธีคูณเฟสเดียว × 3 หากโหลดไม่สมดุล

20. Smart Farm Example

Flow / Pressure Sensor
      ↓ RS485 / Modbus
ESP32 Gateway
      ↓
Local state + telemetry
      ↓
Pump/Valve policy / MQTT

control ที่มี consequence ต้องมี timeout/interlock/protection independent ตามระบบ

Checklist ก่อนเปิดระบบ

protocol จริงคือ Modbus RTU หรือไม่
A/B/polarity ตาม manual หรือไม่
isolation/reference/termination ถูกหรือไม่
baud/parity/stop bits ถูกหรือไม่
device address ไม่ซ้ำ
function/register map revision ตรง model/firmware
datatype/word order/scale/unit ถูก
polling rate เหมาะสม
timeout/retry/offline state มี
write register ถูกปิดไว้ก่อนถ้ายังไม่ validated

สรุป

ESP32 + RS485/Modbus จะเสถียรกว่าเมื่อเราไม่มองมันเป็น “ต่อสองสายแล้วอ่าน register” แต่แยกเป็น:

UART
→ RS485 electrical layer
→ Modbus RTU
→ Vendor register map
→ Data normalization
→ MQTT/Home Assistant/EMS

ตรวจทีละ layer และเริ่มจาก read-only monitoring ก่อน จะลดทั้งเวลาหา bug และความเสี่ยงจากการเขียน command ผิดอุปกรณ์