EV Smart Charging: ออกแบบชาร์จตาม TOU, Solar Surplus และโหลดบ้านอย่างไร.

EV Smart Charging ไม่ใช่แค่ตั้งเวลาว่า “เริ่มชาร์จ 22:00” และไม่ใช่แค่สั่ง Charger ให้ตามกำลัง Solar แบบวินาทีต่อวินาที ระบบที่ใช้งานได้จริงต้องรู้พร้อมกันอย่างน้อยว่า บ้านกำลังใช้ไฟเท่าไร, Grid กำลัง Import/Export เท่าไร, ตอนนี้เป็น Peak หรือ Off-Peak, รถต้องได้พลังงานอีกเท่าไร และ Charger สามารถรับคำสั่งแบบใดได้จริง

เป้าหมายของ Smart Charging จึงควรเป็นการจัดลำดับข้อจำกัดหลายเรื่องพร้อมกัน:

• ลดค่าไฟด้วย TOU
• เพิ่ม Solar self-consumption
• ไม่ดึงกำลังเกิน site/main limit
• ส่งพลังงานให้รถทันก่อนเวลาออกเดินทาง
• ลดการเปิด-ปิดหรือปรับกระแสถี่เกินไป
• มีพฤติกรรมที่คาดเดาได้เมื่อ Sensor, Network หรือ Controller มีปัญหา

หน้า ชาร์จ EV ด้วย TOU คุ้มไหม ตอบเรื่อง economics ของ tariff ส่วน Solar EV Charging ตอบเรื่อง energy flow และ Solar opportunity cost บทความนี้ต่อยอดสองส่วนดังกล่าวไปยัง control architecture แบบไม่ผูกยี่ห้อ

ถ้าต้องการลอง logic เดียวกันแบบ interactive ใช้ EV Smart Charging Simulator เพื่อใส่ Site Limit, House Load, Solar surplus, TOU และพลังงานที่ต้องเติมก่อนเวลาออก แล้วดูทั้งคำแนะนำกำลังชาร์จปัจจุบันกับ timeline simulation โดยไม่ส่งคำสั่งไปยัง Charger จริง

Smart Charging ควรแยกเป็น 5 ชั้น

โครงสร้างที่ดูแลต่อได้ควรแยก Measurement, State, Policy, Control และ Safety ออกจากกัน:

Smart Meter / PCC / Inverter / Charger / optional EV data
                         ↓
                    Measurement
                         ↓
 Grid import/export / House load / PV surplus / data freshness
                         ↓
                       State
                         ↓
 TOU + Solar + Site capacity + Departure target + User preference
                         ↓
                       Policy
                         ↓
 EVSE current / power setpoint / enable / schedule
                         ↓
                      Control

Electrical protection / equipment-native limits / emergency isolation
                         ↓
                       Safety

สิ่งสำคัญคือ Safety ไม่ควรอยู่ปลาย Automation chain เพียงอย่างเดียว Breaker, RCD/RCM ตามระบบที่กำหนด, earthing, cable sizing, EVSE-native protection และข้อจำกัดทางไฟฟ้าต้องทำงานได้แม้ Home Assistant, MQTT, Cloud หรือ Gateway ใช้งานไม่ได้

1. Measurement: อย่าเริ่ม Automation จาก PV Power ค่าเดียว

ถ้าต้องการ Solar surplus charging ข้อมูลที่มีประโยชน์ที่สุดมักเป็นค่าที่สะท้อน net flow ที่ PCC/Grid connection ไม่ใช่ดูเฉพาะกำลังผลิตของ Inverter

ตัวอย่าง:

PV production        7.0 kW
House load           2.5 kW
Battery charging     1.5 kW
Potential EV surplus 3.0 kW

แต่ถ้าระบบมี export limit, battery priority หรือโหลดอื่นเปลี่ยนพร้อมกัน การคำนวณจาก PV - House load แบบตายตัวอาจไม่ตรงกับพลังงานที่ไหลจริงที่ Grid

จึงควรมีข้อมูลอย่างน้อยตาม use case:

• Grid import/export ที่ PCC
• House/site load หรือข้อมูลที่คำนวณกลับได้
• PV generation เมื่อใช้ Solar policy
• Battery power/SOC ถ้า Battery มี priority ในระบบ
• EVSE state และ commanded/actual charging power ถ้าอ่านได้
• timestamp / data freshness
• tariff state เช่น Peak/Off-Peak

ถ้ามี interval data อยู่แล้ว ใช้ Load Profile Analyzer เพื่อดู pattern ก่อนออกแบบ control rule จะดีกว่าตั้ง threshold จากความรู้สึก

2. State: Controller ต้องรู้ว่าข้อมูลยังเชื่อถือได้หรือไม่

Automation ที่อ่าน Sensor ได้ไม่ได้แปลว่าค่านั้นพร้อมใช้ควบคุมทันที State layer ควรตรวจอย่างน้อย:

• Sensor ล่าสุดเมื่อไร
• sign convention ของ Grid Import/Export ถูกหรือไม่
• Charger online หรือไม่
• รถเสียบอยู่หรือไม่ ถ้า interface บอกได้
• ค่ากำลังอยู่ในช่วงสมเหตุผลหรือไม่
• tariff/calendar state มาจากแหล่งที่ถูกต้องหรือไม่
• Controller เพิ่ง restart หรือยังไม่มีข้อมูลสะสมพอสำหรับ moving average หรือไม่

ถ้า Sensor stale การเลือกพฤติกรรม fail-safe ต้องถูกออกแบบให้เหมาะกับไซต์และ Charger เช่น หยุด dynamic control, กลับไป fixed safe schedule หรือจำกัดตามค่าที่ผู้ติดตั้งกำหนดไว้ ไม่ควรกำหนด universal fallback current จากบทความหนึ่งไปใช้กับทุกบ้าน

3. Policy: Smart Charging ต้องรู้ว่ากำลัง Optimize อะไร

ระบบหนึ่งอาจต้องการหลาย objective พร้อมกัน แต่ควรเรียง priority ชัดเจน

ลำดับเชิงแนวคิดที่ใช้ได้กับหลายระบบคือ:

1. ข้อมูลและ communication ต้อง valid
2. ห้ามเกิน equipment/circuit limit
3. ห้ามเกิน site/main-service capacity หลังเผื่อ reserve margin
4. ต้องมีพลังงานพอสำหรับ departure deadline
5. ใช้ Solar surplus เมื่อมี
6. ย้าย Grid charging ไป TOU Off-Peak เมื่อทำได้
7. ใช้ preference/fallback ของผู้ใช้เมื่อไม่มีเงื่อนไขข้างบน

ลำดับข้อ 4–6 อาจปรับตามเป้าหมาย เช่นบางบ้านให้ “Solar first” มากกว่า “charge by deadline” ถ้ารถไม่จำเป็นต้องเต็ม แต่ ข้อจำกัดด้านไฟฟ้าและ capacity ไม่ควรถูกทำให้ optional

4. Dynamic Load Management: จำกัด EV ตาม Capacity ที่เหลือของบ้าน

โจทย์พื้นฐานคือหา power budget ที่ EV ใช้ได้โดยไม่ทำให้โหลดรวมเกิน limit ที่ออกแบบไว้

available_site_power
= configured_site_limit
- measured_non_ev_load
- reserve_margin

ตัวอย่าง:

Configured site limit  12.0 kW
Non-EV house load       5.5 kW
Reserve margin          1.0 kW
--------------------------------
Available for EV        5.5 kW

ถ้า Charger/รถรองรับกำลังสูงกว่านี้ Policy ก็ควรจำกัด setpoint ตาม budget 5.5 kW ในขณะนั้น ไม่ใช่สั่งเต็มกำลังเพียงเพราะ EVSE รองรับ

configured_site_limit ในตัวอย่างเป็น ค่าควบคุมเชิงวิศวกรรมของไซต์ ไม่ใช่ตัวเลขที่ควรเดาจาก rating ของ Main breaker เพียงอย่างเดียว ต้องดู service, conductor, phase balance, protection และข้อกำหนดของระบบจริง

อ่านด้านงานติดตั้งที่ ติดตั้ง Wall Charger ที่บ้าน

5. Solar Surplus Charging: ใช้ Export Feedback พร้อม Reserve Margin

แนวคิด vendor-neutral ที่เรียบง่ายคือ:

solar_surplus_for_ev
= max(0, measured_export - reserve_margin)

ตัวอย่าง PCC วัดว่ากำลัง Export 3.2 kW และต้องการเหลือ margin 0.4 kW:

3.2 - 0.4 = 2.8 kW

Policy อาจพยายามให้ EV รับประมาณ 2.8 kW ถ้า Charger, รถ, circuit และ minimum charging behavior รองรับ

แต่ไม่ควรสั่งตามค่าทุก sample ทันที เพราะเมฆ, Compressor, Pump หรือโหลดบ้านสามารถเปลี่ยนเร็วมาก ระบบจึงควรใช้เครื่องมืออย่าง:

• moving average หรือ filtered value
• hysteresis
• debounce/delay
• minimum run time
• minimum stop time
• ramp limit หรือ step size
• reserve margin

หลักการนี้ช่วยลดอาการ Charger ขึ้น-ลงกำลังหรือ start/stop ถี่เมื่อ Solar แกว่ง

6. TOU Scheduled Charging: Schedule เป็น Smart Charging ขั้นแรกที่มีประโยชน์มาก

สำหรับบ้านที่รถกลับมาช่วงเย็นและอยู่ถึงเช้า การตั้งเวลาชาร์จใน Off-Peak มักเป็น automation ที่ง่ายและเสถียรกว่า dynamic Solar control

ตัวอย่าง policy:

Peak
- ไม่ชาร์จจาก Grid เว้นแต่ต้อง catch up ก่อน departure

Off-Peak
- ชาร์จตาม power budget ของบ้าน
- เติมพลังงานให้ครบ target ก่อน deadline

Solar surplus
- ถ้ารถอยู่บ้านและ surplus ถึง threshold ให้ชาร์จเพิ่มตาม available surplus

ก่อนใช้ TOU schedule ให้ดูว่าบัญชีทั้งบ้านเหมาะกับ TOU จริงหรือไม่ด้วย EV Charging Cost & TOU Calculator เพราะ EV Off-Peak อย่างเดียวไม่รับประกันว่าบิลทั้งบ้านจะลดลง

7. Departure-aware Charging: ต้องคิดจาก Energy ที่ยังขาด ไม่ใช่แค่เวลาเริ่มชาร์จ

ถ้าผู้ใช้ต้องการรถพร้อม 06:00 Controller ควรรู้หรือประมาณอย่างน้อยว่า:

• ต้องเติมพลังงานอีกกี่ kWh
• เหลือเวลากี่ชั่วโมง
• Charger/รถรับกำลังได้เท่าไร
• capacity ของบ้านช่วงนั้นเหลือเท่าไร

ตัวอย่างรถยังต้องรับพลังงานที่แบตเตอรี่ 18 kWh, charging efficiency 90% และมีเวลา 6 ชั่วโมง:

remaining source energy      = 18 / 0.90
                             = 20 kWh

average source power required = 20 / 6
                              ≈ 3.33 kW

การแยก battery-side energy ออกจาก source energy แบบนี้ตรงกับ model ที่ใช้ใน EV Smart Charging Simulator และป้องกันการมองข้าม charging loss ตอนคำนวณ deadline

ถ้าระหว่างคืนมี Off-Peak และ site capacity เหลือเพียงพอ ระบบอาจชะลอการชาร์จช่วงต้นเพื่อรอ window ที่เหมาะกว่าได้ แต่เมื่อใกล้ deadline ควรมี catch-up policy เพื่อไม่ให้ optimization เรื่อง Solar/TOU ทำให้รถมีพลังงานไม่พอใช้งาน

ถ้าไม่มีข้อมูล State of Charge จากรถ ควรใช้ข้อมูลที่ระบบมีจริง เช่น energy delivered/session, user-entered target หรือ conservative schedule แทนการสมมติว่า Controller รู้ SOC เสมอ

8. รวม Solar + TOU + Load Limit อย่างไรไม่ให้ Rule ตีกัน

ตัวอย่างสถานการณ์:

17:30 รถกลับบ้าน
17:30–18:30 ยังมี Solar surplus เล็กน้อย
18:30–22:00 ไม่มี Solar และยังเป็น Peak
22:00–06:00 Off-Peak
06:30 ต้องออกเดินทาง

Policy ที่อ่านง่ายอาจเป็น:

17:30–18:30
ใช้ Solar surplus ตาม site capacity

18:30–22:00
พัก Grid charging ถ้า deadline ยังไม่เสี่ยง

22:00 เป็นต้นไป
ชาร์จ Off-Peak ตาม power budget

ใกล้ deadline
ถ้าพลังงานยังไม่ถึง target ให้เข้าสู่ catch-up mode
แต่ยังห้ามเกิน circuit/site limit

ถ้าระหว่าง 22:00 แอร์และ Water heater ทำให้โหลดบ้านสูง Dynamic Load Management ต้องลด EV ก่อน เพื่อรักษา capacity reserve แม้ช่วงนั้นจะเป็น Off-Peak

นี่คือเหตุผลที่ Smart Charging ไม่ควรเขียนเป็น rule เดี่ยวว่า ถ้า Off-Peak → Charger ON

9. Commanded EV Power ต้องผ่านข้อจำกัดทุกชั้น

แนวคิดการ clamp command:

commanded_ev_power
= min(
    vehicle_limit,
    evse_limit,
    circuit_limit,
    available_site_power,
    policy_target
  )

policy_target อาจมาจาก Solar surplus, TOU schedule หรือ deadline requirement แต่ setpoint สุดท้ายยังต้องผ่านข้อจำกัดของรถ, EVSE, วงจรและไซต์

Minimum current, phase switching, step size และ behavior เมื่อ setpoint ต่ำกว่าขั้นต่ำ เป็นเรื่องเฉพาะ Charger/EV รุ่นนั้น จึงไม่ควร copy ค่า Ampere หรือ phase-switching logic จากระบบหนึ่งไปใช้กับอีกระบบโดยไม่ตรวจคู่มือและ firmware

10. Home Assistant / EMS ทำหน้าที่อะไร

Home Assistant, EMS หรือ Gateway เหมาะกับงานเช่น:

• รวมข้อมูลจาก Meter, Inverter, Battery และ Charger
• สร้าง state ของ Grid Import/Export
• อ่าน TOU calendar/schedule
• คำนวณ policy target
• ทำ hysteresis, timer และ fallback logic
• บันทึก history เพื่อดูว่าระบบ optimize จริงหรือไม่
• ส่ง setpoint ผ่าน interface ที่ Charger รองรับ

แต่ไม่ควรให้ Home Assistant กลายเป็น electrical protection layer

อ่านภาพรวมระบบได้ที่ Advanced Home Assistant for Makers

11. Modbus, MQTT, OCPP และ API เป็น Transport/Interface ไม่ใช่ Policy

Protocol แต่ละตัวแก้ปัญหาคนละชั้น:

• Modbus — มักใช้เข้าถึง telemetry/register ของอุปกรณ์อุตสาหกรรม/พลังงานตาม map ของรุ่นนั้น
• MQTT — ใช้กระจาย state/event/command ระหว่าง software components ได้ดี
• OCPP — เป็น protocol สำหรับ EV charging ecosystem ตาม capability ที่ charger/backend รองรับ
• Vendor API / Cloud — อาจให้ monitoring/control แต่ dependency และ latency ต่างจาก local control

การที่อุปกรณ์ “มี Modbus” หรือ “รองรับ OCPP” ไม่ได้แปลว่าเขียน charging current ได้ทุกค่า ต้องตรวจ documentation, permissions, firmware และ failure behavior ของรุ่นจริง

อ่านพื้นฐานเพิ่มที่ Modbus Protocol และ MQTT Protocol

12. Local Control vs Cloud Control

Local control

ข้อดี:

• latency ต่ำกว่าในหลาย architecture
• ทำงานต่อได้แม้ Internet มีปัญหา ถ้าระบบ local ทั้ง chain
• เหมาะกับ control loop ที่ต้องอ่าน Meter แล้วปรับ setpoint บ่อย

ข้อจำกัด:

• ต้องดูแล Gateway, integration, credentials และ compatibility เอง
• firmware/change ของอุปกรณ์อาจกระทบ integration

Cloud control

ข้อดี:

• setup อาจง่ายกว่าใน ecosystem ที่ผู้ผลิตรองรับครบ
• app/account/device provisioning อยู่ในระบบเดียวกัน

ข้อจำกัด:

• Internet/cloud availability
• API rate/latency
• region/account/permission
• behavior อาจเปลี่ยนตาม firmware/app/backend

ระบบหนึ่งสามารถใช้ Local loop สำหรับ capacity control และใช้ Cloud สำหรับ monitoring ได้ แต่ต้องออกแบบ ownership ของ command ให้ชัด ไม่ให้ Controller สองตัวสั่ง Charger แข่งกัน

13. Monitoring, Control และ Safety ต้องแยกกัน

Monitoring

อ่านค่า, เก็บประวัติ, dashboard, alert และวิเคราะห์ย้อนหลัง

Control

เปลี่ยน schedule, current/power limit, enable/disable หรือ mode ภายใน capability ที่อุปกรณ์รองรับ

Safety

ป้องกัน overcurrent, residual fault, conductor overheating, earthing fault และ hazardous electrical conditions ผ่านอุปกรณ์/การออกแบบที่เหมาะสม

Software automation สามารถ ลดโหลดเชิงปฏิบัติการ ได้ แต่ไม่ควรถูกใช้เป็นเหตุผลให้ลดขนาด cable, breaker หรือ protection จาก requirement ที่ควรมี

14. Failure Mode ที่ควรออกแบบก่อนเขียน Automation

อย่างน้อยให้ตอบคำถามเหล่านี้ก่อน:

• ถ้า Grid Meter หาย จะ Charger ทำอะไร?
• ถ้า Inverter data stale แต่ Grid Meter ยังอยู่ จะ Solar mode ทำอย่างไร?
• ถ้า Home Assistant restart ระหว่างชาร์จ จะ setpoint ค้างที่ Charger หรือ reset?
• ถ้า MQTT broker unavailable จะ command ล่าสุดค้างนานเท่าไร?
• ถ้า Cloud API ล่ม จะ fallback ไป schedule local ได้หรือไม่?
• ถ้า Controller สั่งลด current แต่ Charger ไม่ตอบ จะ detect อย่างไร?
• ถ้ารถไม่รับ charge แม้ Charger enabled จะ alert หรือ retry อย่างไร?

ระบบที่ดีควรมี deterministic failure behavior มากกว่าหวังว่า integration จะ online ตลอดเวลา

15. จาก Fixed Schedule ไป Dynamic Charging ควรทำเป็นขั้น

ไม่จำเป็นต้องเริ่มจาก automation ซับซ้อนที่สุด

Level 1 — Fixed schedule

ตั้ง Off-Peak charging window และตรวจว่ารถพร้อมใช้งานตามต้องการ

Level 2 — Measured load limit

เพิ่ม Smart Meter/PCC feedback เพื่อจำกัด EV เมื่อโหลดบ้านสูง

Level 3 — Solar surplus

เพิ่ม export/surplus tracking พร้อม margin, hysteresis และ minimum run behavior

Level 4 — Deadline-aware

เพิ่ม target energy/departure time เพื่อไม่ให้ optimization ทำให้รถมีพลังงานไม่พอ

Level 5 — Multi-resource EMS

ประสาน EV, Solar, Battery, TOU, backup reserve และโหลด flexible อื่นภายใต้ policy เดียวกัน

การไล่ทีละ Level ทำให้สามารถพิสูจน์ measurement และ failure behavior ก่อนเพิ่ม control loop ใหม่

16. ตัวอย่าง Implementation Layer ที่มีอยู่ในเว็บ

ถ้าต้องการดูระบบเฉพาะ ecosystem:

• Huawei Smart Charger Guide — Scheduled charging, PV Power Preferred, Dynamic Charging และ FusionSolar/SmartAssistant dependencies
• Solis S6 + Home Assistant Solar Surplus EV Charging — ตัวอย่างแยก Meter/Grid feedback, Home Assistant policy และ Charger interface

สองหน้านี้เป็น implementation examples ส่วนหน้านี้เป็น architecture กลาง เพื่อไม่ให้ register, entity หรือ behavior ของยี่ห้อหนึ่งถูกเข้าใจว่าเป็นมาตรฐานของ EV Charger ทุกตัว

Checklist ก่อนทำ EV Smart Charging

• ระบบไฟและ Wall Charger ผ่านการออกแบบ/ติดตั้งถูกต้องแล้วหรือไม่?
• มี Grid/PCC measurement ที่เชื่อถือได้หรือไม่?
• sign ของ Import/Export ถูกยืนยันแล้วหรือไม่?
• Site capacity limit และ reserve margin มาจากการประเมินจริงหรือไม่?
• รถต้องการพลังงานเท่าไรและต้องพร้อมเวลาไหน?
• บ้านใช้ Normal หรือ TOU และ Off-Peak window ถูกต้องหรือไม่?
• Solar surplus นิยามจาก PCC flow หรือจาก PV production อย่างเดียว?
• Battery มี priority อย่างไร?
• Charger รับคำสั่งอะไรได้จริงจาก interface ไหน?
• minimum current / phase behavior ของรถและ EVSE คืออะไร?
• Sensor stale แล้ว fallback ไป mode ไหน?
• Controller restart แล้ว Charger อยู่สถานะใด?
• มี history ให้ตรวจว่า Grid import ลดลงและ deadline ยังผ่านหรือไม่?

สรุป

EV Smart Charging ที่ดีควรตอบได้พร้อมกัน 4 เรื่อง: ชาร์จเมื่อไร, ชาร์จกี่ kW, เพราะอะไร และถ้าข้อมูล/ระบบควบคุมเสียจะเกิดอะไรขึ้น

แนวคิดที่ใช้งานต่อได้คือ:

Measure correctly
→ validate state
→ apply site/equipment limits
→ satisfy departure need
→ optimize Solar / TOU
→ command Charger through supported interface
→ keep electrical safety independent from software

ถ้าต้องการตัดสินใจด้านค่าไฟก่อนทำ Automation ให้เริ่มจาก EV Charging Cost & TOU Calculator และ ชาร์จ EV ด้วย TOU คุ้มไหม ก่อน ส่วนถ้าต้องการวิเคราะห์ว่าพลังงาน Solar กับรถ overlap กันจริงแค่ไหน อ่าน Solar EV Charging แล้วค่อยนำผลไปออกแบบ policy ในหน้านี้