Crypto Mining + TOU: ใช้ Off-Peak ลดต้นทุนไฟอย่างไรโดยไม่หลงกับตัวเลข Savings.

Crypto Mining + TOU มีประโยชน์เมื่อ mining load สามารถเพิ่ม/ลดตามเวลาได้จริง แต่คำว่า “รันเฉพาะ Off-Peak แล้วประหยัด” ต้องแยกให้ชัดว่าประหยัดเพราะ rate ต่ำลง, เพราะ runtime ลดลง, หรือเกิดทั้งสองอย่างพร้อมกัน

ถ้าลดเครื่องจาก 24 ชั่วโมงเหลือ 10 ชั่วโมง ค่าไฟย่อมลดมากแม้ไม่ได้ใช้ TOU เลย เพราะ kWh ลดลง การวิเคราะห์ที่ดีจึงต้องแยก energy reduction ออกจาก time shifting

TOU เป็นเรื่องของเวลา ไม่ใช่ชื่อโหลด

TOU แบ่ง Energy charge ตามช่วง Peak/Off-Peak ของ tariff ที่บัญชีนั้นใช้จริง ไม่ว่าโหลดจะเป็น EV, Chiller, Pump หรือ Miner หลักการเดียวกันคือ:

Peak kWh × Peak rate
+
Off-Peak kWh × Off-Peak rate

สำหรับ calendar/rule ที่เว็บมี provenance อยู่ ให้ตรวจที่ มิเตอร์ TOU และ ปฏิทิน TOU ปี 2569

อย่านำ calendar เก่าหรือวันหยุดจากปีอื่นมาใช้เป็น source of truth เพราะ holiday classification เปลี่ยนตามปี

ตัวอย่าง: 35 kW แบ่ง Runtime 4h Peak + 8h Off-Peak

Total load = 35 kW
Peak runtime = 4 h/day
Off-Peak runtime = 8 h/day

พลังงานต่อวัน:

Peak     = 35 × 4 = 140 kWh
Off-Peak = 35 × 8 = 280 kWh
Total    = 420 kWh/day

30 วัน:

Peak     = 4,200 kWh/month
Off-Peak = 8,400 kWh/month
Total    = 12,600 kWh/month

จากนั้นจึงคูณ rate ที่ตรงกับบัญชีไฟจริง

Crypto Mining Energy Calculator ให้กรอก Peak/Off-Peak rate เอง เพราะบัญชีโรงงานหรือกิจการจริงอาจไม่ใช่ residential tariff ที่ใช้เป็น default reference

Load Shifting กับ Runtime Reduction ไม่เหมือนกัน

Load Shifting จริง

สมมติเดิม Miner ทำงาน 12 ชั่วโมงอยู่แล้ว แต่ย้ายจาก:

Peak 6h + Off-Peak 6h

เป็น:

Peak 2h + Off-Peak 10h

Total runtime ยัง 12 ชั่วโมงและ kWh รวมเท่าเดิม สิ่งที่เปลี่ยนคือ distribution ของ Grid energy

Runtime Reduction

ถ้าเปลี่ยนจาก 24h เป็น 12h:

kWh ลดประมาณครึ่งหนึ่ง

นี่ไม่ใช่ผล TOU เพียงอย่างเดียว และ hashing time ก็ลดตาม runtime

เวลารายงาน savings จึงควรบอก baseline เสมอ เช่น saving vs 24/7 Grid ไม่ควรเขียนว่าเป็น “TOU savings” ทั้งหมด

Weekend / Holiday ทำให้ Mining Schedule น่าสนใจขึ้นได้ แต่ต้องดู Calendar จริง

ถ้า tariff ของบัญชีมี Off-Peak ตลอดเสาร์–อาทิตย์หรือวันหยุดตามเงื่อนไขปีนั้น โหลดที่ยืดหยุ่นอาจเพิ่ม runtime ในช่วงดังกล่าวได้

แนวคิด:

Weekday Peak      → ลด Group C/D
Weekday Off-Peak  → เพิ่ม Group C/D
Weekend Off-Peak  → เพิ่ม runtime ตาม capacity
Holiday Off-Peak  → เพิ่ม runtimeเมื่อ calendar ยืนยัน

อย่าฮาร์ดโค้ด “วันหยุด = Off-Peak” จากบทความเก่า ระบบ automation ควรใช้ dataset/calendar version ที่ตรวจสอบแล้ว หรือ schedule ที่ operator อนุมัติ

Whole-Site Load สำคัญกว่า Miner Schedule อย่างเดียว

สมมติ Miner 100 kW ถูกเปิดช่วง Off-Peak แต่โรงงานมี base load 500 kW อยู่แล้ว การเปิด Miner อาจยังชนข้อจำกัด service, transformer หรือ operational limit

จึงควรมอง:

Base site load
+ Mining groups
= Site load

แล้วดู capacity margin ตามเวลา

ถ้ามี interval data ใช้ Load Profile Analyzer เพื่อดู hourly/day-type pattern ก่อนกำหนด miner groups

TOU Cost Comparator ใช้เป็น Sanity Check ได้

ถ้าอยากเห็นผลของ Peak → Off-Peak แบบ kWh รวมไม่เปลี่ยน ใช้ TOU Cost Comparator เพื่อ isolate load-shifting effect

ส่วน Mining Calculator ตั้งใจให้เปรียบเทียบ 24/7 baseline กับ scheduled runtime ซึ่งอาจเปลี่ยน kWh รวมด้วย จึงตอบคนละคำถาม

Rate ต้องมาจากบัญชีจริง

Mining Calculator มี default rate ที่มาจาก snapshot PEA residential + Ft + VAT เพราะต้องการ deterministic starting point ที่มี provenance แต่ไม่ได้หมายความว่า site mining ใช้อัตรานั้น

ก่อนตัดสินใจจริง ต้องตรวจ:

• tariff class ของบัญชี
• Peak / Off-Peak energy rate
• Ft ที่มีผลในงวดนั้น
• VAT / tax boundary
• service charge
• demand charge หรือ charge อื่นถ้ามี
• contract / special tariff ของไซต์

ถ้าองค์ประกอบใดไม่ได้อยู่ใน simple per-kWh model ต้องนำไปคำนวณเพิ่ม ไม่ควรบังคับให้ calculator แสดงความแม่นยำเกินข้อมูลที่มี

Automation ควรควบคุมเป็น Group

การเปิด/ปิด Miner ทีละเครื่องจาก cloud API ไม่จำเป็นต้องเป็น architecture ที่ดีที่สุด การแบ่งกลุ่มช่วยให้ policy deterministic กว่า เช่น:

Group A = Base mining load
Group B = Off-Peak expansion
Group C = Solar surplus
Group D = Curtailable / load shedding

Controller สามารถตัดสินจาก:

• Current tariff period
• Site kW
• Solar surplus
• Temperature
• Grid/import limit

แต่ protection ของวงจร, breaker, thermal trip และ emergency stop ต้องอยู่ใน safety layer ไม่ใช่ฝากไว้กับ scheduler

อ่านต่อ: Crypto Mining Energy Automation

Solar + TOU ควรเป็น Combined Scenario ไม่จำเป็นต้องแยก URL เพิ่ม

ถ้าไซต์มี Solar ด้วย วิธีที่ไม่ double-count คือ:

Mining energy
→ หัก Solar self-consumption
→ Grid remainder
→ แบ่ง Grid Peak / Off-Peak

จึงควรดู Crypto Mining + Solar ร่วมกับหน้านี้ โดยไม่จำเป็นต้องสร้างบทความ Solar+TOU อีกหน้าแยกจนเกิด intent ซ้ำ

สรุป

TOU เหมาะกับ Mining เมื่อ load เป็น flexible จริงและ schedule ไม่ชน capacity ของไซต์ แต่การประเมินต้องแยกสามเรื่อง:

1. kWh ที่ลดจาก runtime reduction
2. kWh ที่ย้ายจาก Peak ไป Off-Peak
3. rate/tariff จริงของบัญชี

ถ้ามี interval data และ calendar ที่ verified จะลดความเสี่ยงของ scenario estimate ได้มากกว่าการตั้งเวลา Miner จากค่าเฉลี่ยรายเดือนเพียงอย่างเดียว