Crypto Mining Energy Automation: Meter → Modbus/MQTT → EMS → Miner Groups.

Crypto Mining Energy Automation ควรเริ่มจากการแยก 3 ชั้นให้ชัด: Monitoring, Control และ Safety เพราะการอ่าน Meter ผ่าน Modbus, การส่งคำสั่งผ่าน MQTT และการตัดไฟด้วย protection hardware เป็นคนละหน้าที่กัน

Architecture แบบ vendor-neutral:

Smart Meter / Power Meter
          ↓
      Modbus / API
          ↓
   Gateway / EMS
          ↓
 Schedule / Load Controller
          ↓
 Miner Group A / B / C / D

ถ้าต้องเชื่อมระบบอื่นด้วย:

PV / Inverter Meter ─┐
Main Smart Meter ────┼→ Gateway / EMS → Policy Engine → Miner Groups
Temperature sensors ─┤
TOU calendar ────────┘

เป้าหมายไม่ใช่ “ทำให้เปิดปิด Miner ได้จากมือถือ” แต่คือทำให้ controller รู้ว่า เมื่อไรควรเพิ่มโหลด, เมื่อไรควรลดโหลด และเมื่อไรต้อง fail safe

1. Monitoring Layer: อ่านก่อนควบคุม

Monitoring ควรตอบข้อมูลอย่างน้อย:

• Site active power kW
• Grid import/export
• Mining group power
• PV power / Solar surplus ถ้ามี
• Voltage/current ตาม meter ที่รองรับ
• Room/inlet temperature
• Communication health / stale data
• Current tariff period หรือ schedule state

ตัวอย่าง data path:

Smart Meter
→ Modbus RTU/TCP
→ Gateway
→ Time-series / Home Assistant / EMS

อ่านหลักการ protocol เพิ่มที่ Modbus Protocol

Monitoring layer ควรสามารถทำงานแบบ read-only ได้ก่อน เปิด control จริงภายหลังเมื่อ mapping, scaling, sign convention และ update interval ถูกตรวจสอบแล้ว

2. MQTT เป็น Message Layer ไม่ใช่ Protection Layer

MQTT เหมาะกับการกระจาย telemetry/event ระหว่าง Gateway, EMS และ service อื่น เช่น:

energy/site_kw
energy/grid_import_kw
solar/surplus_kw
mining/group_b/state
thermal/room_temp_c

Controller อาจ subscribe ข้อมูลแล้ว publish desired state เช่น:

mining/group_c/command = enable

แต่ MQTT broker outage, network delay หรือ stale retained message ต้องไม่ทำให้ระบบไฟสูญเสีย protection

อ่านต่อ: MQTT Protocol คืออะไร

3. Control Layer: คุมเป็น Miner Group

แทนที่จะเปิดปิดเครื่องแบบสุ่ม ควรแบ่งกลุ่มตาม policy:

Group A — Base load / always-on ตามแผน
Group B — Off-Peak expansion
Group C — Solar surplus
Group D — Curtailable / load shedding

แต่ละ group ควรมี:

• known load kW
• enable/disable mechanism ที่รองรับจริง
• minimum on/off time
• startup surge/behavior ที่ตรวจจริง
• state feedback
• manual override

ทำให้ controller ประเมิน capacity ได้เป็น block แทนการเดาโหลด

4. Use Case: Off-Peak → เพิ่มโหลด

Policy เชิงแนวคิด:

IF tariff_period == OFF_PEAK
AND site_capacity_margin >= group_B_kw
AND thermal_ok
THEN enable Group B

ถ้าเป็นวันหยุด/Weekend ต้องอิง calendar/version ที่ถูกต้อง ไม่ควร hard-code จากบทความเก่า

อ่าน logic ด้านเวลาเพิ่มที่ Crypto Mining + TOU

5. Use Case: Peak → ลดโหลด

IF tariff_period == PEAK
THEN disable Group D

แต่ Peak ไม่จำเป็นต้องแปลว่า “ปิดทั้งหมด” เพราะต้องมอง Energy economics และ workload policy ของ operator ด้วย

สิ่งสำคัญคือแยกคำว่า cost optimization ออกจาก emergency load shedding เพราะสองเหตุการณ์มี priority และ timeout ต่างกัน

6. Use Case: Solar Surplus → เพิ่มโหลด

ใช้ Grid/PCC measurement เป็น feedback จะดีกว่าใช้ PV generation อย่างเดียว

IF measured_export_kw > 20
FOR 5 minutes
AND thermal_ok
THEN enable 15-kW Miner Group C

เมื่อลดโหลด:

IF measured_export_kw < 5
FOR 3 minutes
THEN disable Group C

ตัวอย่างมี hysteresis และ delay เพื่อไม่ให้กลุ่ม Miner สลับเปิดปิดถี่เมื่อเมฆผ่าน

อ่าน Energy Flow เพิ่มที่ Crypto Mining + Solar

7. Use Case: Main Load สูง → Load Shedding

ถ้าโหลดรวมเข้าใกล้ operational limit:

Site load > soft limit
→ shed Group D
→ recheck
→ shed Group C/B ตาม priority ถ้าจำเป็น

การตั้ง soft limit ควรต่ำกว่า protection threshold และต้องมาจาก electrical design/operating policy ของไซต์ ไม่ใช่ตั้งให้เท่าพิกัด breaker แล้วหวังว่า software จะตอบทัน

Load shedding controller เป็น operational control ไม่ใช่ replacement ของ breaker/relay/protection

8. Use Case: Temperature สูง → ลด Mining Load

Mining แปลงพลังงานไฟฟ้าส่วนใหญ่เป็นความร้อนในพื้นที่ จึงควรนำ thermal condition เข้า policy

ตัวอย่าง:

Room temperature > warning threshold
→ disable flexible groups

Temperature sensor stale
→ fail to conservative state

ค่า threshold ต้องมาจาก equipment/environment design ของระบบจริง บทความนี้ไม่กำหนด universal temperature setpoint

9. Monitoring / Control / Safety Boundary

Monitoring

หน้าที่:

• อ่าน Meter/Sensor
• เก็บข้อมูล
• ทำ Dashboard
• แจ้งเตือน
• สร้าง Load Profile

Failure ของ Monitoring ไม่ควรทำให้ protection หาย

Control

หน้าที่:

• Schedule ตาม TOU
• Enable/disable Miner groups
• Limit load ตาม Solar/site capacity
• Execute load shedding policy

ต้องมี timeout, stale-data handling, manual override และ state verification

Safety

หน้าที่:

• Overcurrent / short-circuit protection
• Ground fault / earthing protection ตาม design
• Thermal protection
• Emergency isolation
• Contactor/relay interlock ตามความเหมาะสม
• Fire/electrical safety measures

Safety layer ต้องทำงานได้แม้ Gateway, MQTT, Home Assistant หรือ EMS ล่ม

10. Home Assistant ใช้ตรงไหนได้

Home Assistant เหมาะกับ monitoring, orchestration และ automation ในระบบที่ออกแบบ boundary ชัด เช่น:

Meter → Modbus integration
Sensors → Dashboard / history
Automation → Desired mining group state

แต่ไม่ควรทำให้ Home Assistant เป็น single safety controller สำหรับโหลดกำลังสูง

อ่านแนวคิดระบบที่ Advanced Home Assistant for Makers

สำหรับ production EMS อาจใช้ PLC, industrial gateway หรือ controller อื่นแทน/ร่วมกับ Home Assistant ตาม reliability requirement

11. Data Quality ก่อน Automation

ก่อนอนุญาต control ควรตรวจ:

• Meter address / register map
• scale factor
• sign convention import/export
• timestamp และ timezone
• stale sensor detection
• update cadence
• missing data behavior
• controller restart state
• network partition behavior

ถ้า input ผิด เช่น export sign กลับด้าน ระบบที่ตั้งใจเพิ่ม Miner ตอน Solar surplus อาจเพิ่มโหลดตอนกำลัง import Grid สูงแทน

12. จาก Calculator ไป Control Policy

Crypto Mining Energy Calculator ใช้หา economic envelope ก่อน เช่น:

• Group load กี่ kW
• runtime เป้าหมายกี่ชั่วโมง
• Peak/Off-Peak split
• Solar share scenario
• Energy cost/saving

จากนั้นจึงนำ policy ไป validate กับ measured load profile

Calculator scenario
→ measured load validation
→ control policy
→ dry-run / monitoring-only
→ bounded control
→ operational review

ไม่ควรกระโดดจาก spreadsheet assumption ไปเปิด/ปิดโหลดจริงทันที

สรุป

Architecture ที่ดูแลต่อได้ควรเป็น:

Meter / Sensor
→ trusted telemetry
→ Gateway / EMS
→ bounded policy
→ Miner Groups

โดยมี Safety protection แยกออกจาก software control อย่างชัดเจน

เมื่อทำเช่นนี้ TOU, Solar surplus, site capacity และ temperature สามารถเป็น input ของ Energy Optimization ได้โดยไม่เปลี่ยนระบบ automation ให้กลายเป็น single point of failure ของระบบไฟ