Local Energy History API สำหรับค่าที่อ่านได้หน่วย kWh

title: Local Energy History API สำหรับค่าที่อ่านได้หน่วย kWh

abstract: อ่านประวัติ kWh รายครึ่งชั่วโมงจากภายในเครื่องเพื่อการวิเคราะห์แบบออฟไลน์

language: th

author: Jessica

บทนำ

สำหรับผู้ใช้ที่สร้างแดชบอร์ด ระบบอัตโนมัติ หรือเครื่องมือวิเคราะห์แบบออฟไลน์ด้วยตนเอง ข้อมูลพลังงานจริงจะมีประโยชน์มากขึ้นเมื่อเข้าถึงได้ในช่วงเวลาที่สม่ำเสมอ ค่ากำลังไฟฟ้าแบบเรียลไทม์เพียงค่าเดียวบอกได้ว่าเกิดอะไรขึ้นในขณะนี้ แต่ประวัติ kWh รายครึ่งชั่วโมงช่วยให้ผู้ใช้เข้าใจว่าการนำเข้าและการส่งออกไฟฟ้าเปลี่ยนแปลงไปตามเวลาอย่างไร

เริ่มตั้งแต่เฟิร์มแวร์เวอร์ชัน i.91.063TS8.bin ซึ่งเปิดตัวเมื่อวันที่ 2 มิถุนายน 2026 IAMMETER รองรับ local API ตัวใหม่: GET /api/energyhistory API นี้คืนค่าที่อ่านได้หน่วย kWh ซึ่งแคชไว้ในเครื่อง โดยสุ่มเก็บรอบขอบเขตครึ่งชั่วโมงตามเวลา UTC ทำให้วิเคราะห์การใช้พลังงานล่าสุดได้ง่ายขึ้นโดยไม่ต้องพึ่งประวัติจากฝั่งคลาวด์เพียงอย่างเดียว

สิ่งนี้มีประโยชน์เป็นพิเศษสำหรับการมอนิเตอร์โซลาร์ การมอนิเตอร์พลังงานในบ้าน และเวิร์กโฟลว์การจัดการพลังงานแบบกำหนดเองที่ผู้ใช้ต้องการเปรียบเทียบข้อมูลพลังงานในระดับเฟส การนำเข้า และการส่งออก IAMMETER ไม่ได้เป็นเพียงอุปกรณ์มอนิเตอร์เท่านั้น จุดประสงค์ของการเก็บข้อมูลนี้คือช่วยให้ผู้ใช้เพิ่มประสิทธิภาพการใช้พลังงาน ใช้ไฟฟ้าที่ผลิตจากโซลาร์ด้วยตนเองได้ดีขึ้น และลดค่าไฟฟ้า

Energy History API ให้ข้อมูลอะไรบ้าง

ปลายทางใหม่คือ:

GET /api/energyhistory

โดยคืนค่าที่อ่านได้หน่วยพลังงานใน kWh ซึ่งสุ่มเก็บรอบขอบเขตครึ่งชั่วโมงตามเวลา UTC ดังนี้:

00:00
00:30
01:00
01:30
และต่อไปเรื่อยๆ

เฟิร์มแวร์เก็บข้อมูลได้สูงสุด 96 รายการ เทียบเท่าประวัติ 48 ชั่วโมงที่ช่วงเวลา 30 นาที ระเบียนเหล่านี้ถูกเก็บไว้ใน RAM ของโมดูล Wi-Fi ดังนั้นข้อมูลจะหายไปเมื่ออุปกรณ์รีบูต

การตอบกลับโดยทั่วไปประกอบด้วย:

utc: เวลาปัจจุบันของโมดูลในรูปแบบ UTC timestamp
timeSynced: ว่าโมดูลมีเวลาตาม UTC ที่ถูกต้องหรือไม่
interval: ช่วงเวลาการสุ่มเก็บข้อมูล ปัจจุบันคือ 1800 วินาที
count: จำนวนระเบียนประวัติที่มีอยู่
order: ปัจจุบันคือ newest_first
unit: ปัจจุบันคือ kWh
channels: ชื่อช่องสัญญาณที่ตรงกับแต่ละค่า
Datas: ระเบียนประวัติรายครึ่งชั่วโมง

แต่ละรายการใน Datas ประกอบด้วย UTC timestamp และอาร์เรย์ของค่า kWh โดยค่าต่างๆ เรียงลำดับตามอาร์เรย์ channels

ทำไมประวัติ kWh รายครึ่งชั่วโมงจึงสำคัญ

ข้อมูลพลังงานรายครึ่งชั่วโมงใช้ได้จริงในทางปฏิบัติ เพราะให้มุมมองที่กะทัดรัดแต่มีความหมายเกี่ยวกับพฤติกรรมการใช้พลังงาน แทนที่จะเก็บทุกจุดแบบเรียลไทม์ ผู้ใช้สามารถวิเคราะห์ค่าการนำเข้าและการส่งออกสะสมในช่วงเวลาที่กำหนดไว้ได้

ตัวอย่างเช่น ผู้ใช้สามารถใช้ข้อมูลในเครื่องเพื่อ:

ตรวจสอบพลังงานที่นำเข้าและส่งออกล่าสุดโดยไม่ต้องรอรายงานจากคลาวด์
ส่งออกค่าที่อ่านได้หน่วย kWh ใน 48 ชั่วโมงล่าสุดไปยังฐานข้อมูลภายในเครื่องหรือไฟล์ CSV
เปรียบเทียบรูปแบบการส่งออกของโซลาร์กับการใช้ไฟฟ้าในครัวเรือน
ตรวจสอบว่ากลยุทธ์ระบบอัตโนมัติเปลี่ยนการใช้ไฟฟ้าในช่วงเวลาเฉพาะหรือไม่
สร้างแดชบอร์ดในเครื่องสำหรับประวัติพลังงานล่าสุด

สำหรับสถานการณ์การมอนิเตอร์โซลาร์ในภาพรวม ดู โซลูชันการมอนิเตอร์พลังงานแสงอาทิตย์ของ IAMMETER สำหรับการมอนิเตอร์ไฟฟ้าในที่พักอาศัย ดู โซลูชันการมอนิเตอร์พลังงานในบ้านของ IAMMETER

รูปแบบช่องสัญญาณที่รองรับ

ฟิลด์ channels บอกไคลเอนต์ว่าควรตีความค่าในแต่ละระเบียนประวัติอย่างไร การตั้งค่ามิเตอร์ที่แตกต่างกันจะคืนรูปแบบช่องสัญญาณที่แตกต่างกัน

ระบบเฟสเดียว

["imp", "exp"]

ระบบแยกเฟส (Split Phase)

["a_imp", "a_exp", "b_imp", "b_exp"]

ระบบสามเฟส

["a_imp", "a_exp", "b_imp", "b_exp", "c_imp", "c_exp"]

ระบบสามเฟสเมื่อเปิดใช้งาน Net Metering

["a_imp", "a_exp", "b_imp", "b_exp", "c_imp", "c_exp", "nem_imp", "nem_exp"]

เนื่องจากชื่อช่องสัญญาณถูกส่งกลับมาในการตอบกลับ ซอฟต์แวร์ที่พัฒนาขึ้นเองจึงควรอ่านอาร์เรย์ channels ก่อน แล้วจึงจับคู่แต่ละค่าใน Datas[].values ตามลำดับนั้น

ตัวอย่างผลลัพธ์การตอบกลับของ API ต้นฉบับ

สองตัวอย่างต่อไปนี้แสดงผลลัพธ์การตอบกลับของ API ต้นฉบับสำหรับกรณีไม่มีข้อมูลและกรณีมีข้อมูล

ตัวอย่างการตอบกลับเมื่อไม่มีข้อมูล

หลังจากอุปกรณ์บูต อาร์เรย์ประวัติอาจว่างเปล่าจนกว่าจะมีเวลาตาม UTC ที่ถูกต้องและเฟรมข้อมูลมิเตอร์ที่ถูกต้อง ในกรณีนี้ API อาจคืนค่า count: 0 และอาร์เรย์ Datas ที่ว่างเปล่า

{
  "utc": 1780023600,
  "timeSynced": 1,
  "interval": 1800,
  "count": 0,
  "order": "newest_first",
  "unit": "kWh",
  "source": "wifi",
  "channels": ["a_imp", "a_exp", "b_imp", "b_exp", "c_imp", "c_exp"],
  "Datas": []
}

การตอบกลับนี้เป็นเรื่องปกติหลังการบูต แดชบอร์ดหรือสคริปต์ในเครื่องควรจัดการสถานะนี้และรอตัวอย่างข้อมูลครึ่งชั่วโมงใหม่

ตัวอย่างการตอบกลับเมื่อมีข้อมูล

ตัวอย่างต่อไปนี้แสดงระเบียนรายครึ่งชั่วโมงสองรายการจากมิเตอร์สามเฟส การตอบกลับเรียงลำดับจากใหม่ไปเก่า

{
  "utc": 1780023700,
  "timeSynced": 1,
  "interval": 1800,
  "count": 2,
  "order": "newest_first",
  "unit": "kWh",
  "source": "wifi",
  "channels": ["a_imp", "a_exp", "b_imp", "b_exp", "c_imp", "c_exp"],
  "Datas": [
    {
      "utc": 1780023600,
      "values": [11.337, 11.201, 11.039, 10.908, 10.975, 10.846]
    },
    {
      "utc": 1780021800,
      "values": [11.330, 11.198, 11.030, 10.900, 10.970, 10.840]
    }
  ]
}

ในระเบียนล่าสุด a_imp คือ 11.337 kWh a_exp คือ 11.201 kWh และเป็นเช่นนี้ต่อไป ความหมายของแต่ละค่าถูกกำหนดโดยอาร์เรย์ channels

การใช้ค่าที่ส่งกลับในซอฟต์แวร์

ตัวอย่างการตอบกลับต้นฉบับข้างต้นเพียงพอสำหรับสร้างตรรกะการวิเคราะห์ในเครื่องแบบง่ายๆ สิ่งสำคัญคืออ่าน channels ก่อน แล้วนำลำดับนั้นไปใช้กับแต่ละรายการใน Datas

การจับคู่ `channels` กับ `values`

เมื่อพัฒนาซอฟต์แวร์ที่ทำงานกับ API นี้ ควรหลีกเลี่ยงการกำหนดตำแหน่งแบบตายตัว เว้นแต่การตั้งค่ามิเตอร์จะคงที่ วิธีที่ปลอดภัยกว่าคือแปลงรายการช่องสัญญาณและอาร์เรย์ค่าให้เป็นออบเจ็กต์ที่มีชื่อกำกับ

const response = await fetch("http://<meter-ip>/api/energyhistory").then((res) => res.json());
const latest = response.Datas[0];

const latestByChannel = Object.fromEntries(
  response.channels.map((name, index) => [name, latest.values[index]])
);

console.log(latest.utc, latestByChannel);

สำหรับตัวอย่างการตอบกลับของระบบสามเฟสข้างต้น latestByChannel จะมีค่าเป็น:

{
  "a_imp": 11.337,
  "a_exp": 11.201,
  "b_imp": 11.039,
  "b_exp": 10.908,
  "c_imp": 10.975,
  "c_exp": 10.846
}

วิธีนี้ทำให้ข้อมูลจัดเก็บ แสดงผล หรือส่งออกไปยังเครื่องมือวิเคราะห์ในเครื่องได้ง่ายขึ้น

การคำนวณการเปลี่ยนแปลง kWh ในครึ่งชั่วโมง

หากคุณใช้ค่า kWh ที่ส่งกลับเป็นค่าพลังงานสะสม การเปลี่ยนแปลงระหว่างระเบียนสองรายการที่อยู่ติดกันสามารถคำนวณได้โดยนำค่าใหม่ลบด้วยค่าเก่าของช่องสัญญาณเดียวกัน

โดยใช้ตัวอย่างระบบสามเฟสข้างต้น:

a_imp change = 11.337 - 11.330 = 0.007 kWh
a_exp change = 11.201 - 11.198 = 0.003 kWh
b_imp change = 11.039 - 11.030 = 0.009 kWh
b_exp change = 10.908 - 10.900 = 0.008 kWh

การคำนวณแบบนี้ช่วยให้ผู้ใช้สร้างรายงานการนำเข้า/ส่งออกล่าสุด เปรียบเทียบการเปลี่ยนแปลงพลังงานในระดับเฟส หรือตรวจสอบว่ามีพลังงานถูกนำเข้าหรือส่งออกเท่าใดในช่วงครึ่งชั่วโมงที่กำหนด

พฤติกรรมการสุ่มเก็บข้อมูลที่สำคัญ

ประวัติพลังงานถูกสร้างขึ้นในเครื่องโดยโมดูล Wi-Fi พฤติกรรมการสุ่มเก็บข้อมูลมีความสำคัญเมื่อพัฒนา integration หรือเครื่องมือวิเคราะห์:

การสุ่มเก็บข้อมูลขับเคลื่อนด้วยเฟรมข้อมูลมิเตอร์ UART ที่ถูกต้อง
โมดูลจะเก็บตัวอย่างที่ใกล้ขอบเขตครึ่งชั่วโมงตามเวลา UTC มากที่สุด
เวลาตาม UTC ต้องถูกต้องก่อนจึงจะบันทึกระเบียนประวัติได้
หาก timeSynced เป็น 0 จะไม่มีการบันทึกตัวอย่างประวัติใหม่
หลังการบูต Datas อาจว่างเปล่าจนกว่าจะเก็บตัวอย่างที่ถูกต้องได้เพียงพอ
การจัดเก็บในปัจจุบันใช้ RAM ดังนั้น API นี้ออกแบบมาสำหรับประวัติในเครื่องระยะสั้น ไม่ใช่การจัดเก็บระยะยาว

ด้วยเหตุนี้ API นี้จึงเหมาะสำหรับการโพลล์ในเครื่อง การวิเคราะห์ระยะสั้น และการทดสอบ integration สำหรับรายงานพลังงานระยะยาว ผู้ใช้ยังคงต้องมีแหล่งข้อมูลที่คงทน เช่น ข้อมูลบนคลาวด์ของ IAMMETER หรือฐานข้อมูลของตนเอง

ไอเดียการทำ Integration ตัวอย่าง

นักพัฒนาและผู้ใช้ขั้นสูงสามารถใช้ /api/energyhistory เป็นแหล่งข้อมูลในเครื่องแบบง่ายๆ สำหรับประวัติ kWh ล่าสุด

แนวทางที่นิยมวิธีหนึ่งคือโพลล์ปลายทางเป็นระยะ อ่านรายการ channels และบันทึกระเบียน Datas ใหม่ลงฐานข้อมูลในเครื่อง วิธีนี้รองรับแดชบอร์ดในเครื่อง รายงานแบบกำหนดเอง หรือสคริปต์วิเคราะห์แบบออฟไลน์

สถานการณ์ที่มีประโยชน์อีกกรณีคือการวิเคราะห์การใช้ไฟฟ้าจากโซลาร์ด้วยตนเอง ด้วยการเปรียบเทียบค่า kWh ที่นำเข้าและส่งออกในแต่ละช่วงครึ่งชั่วโมง ผู้ใช้จะเข้าใจได้ดีขึ้นว่าเมื่อใดที่โหลดในครัวเรือนใช้ไฟฟ้าที่ผลิตจากโซลาร์เอง และเมื่อใดที่มีการส่งออกพลังงานส่วนเกิน ซึ่งช่วยสนับสนุนการตัดสินใจด้านระบบอัตโนมัติได้ดีขึ้น เช่น การเลื่อนโหลดที่ยืดหยุ่นได้ไปยังช่วงที่โซลาร์ผลิตไฟได้มากกว่า

หากคุณกำลังพัฒนา integration ในเครื่อง โปรดดู Local API, Modbus/TCP และ MQTT และ IAMMETER Local API Explorer ด้วย

สิ่งนี้สอดคล้องกับการจัดการพลังงานอย่างไร

คุณค่าของ API ประวัติพลังงานไม่ได้อยู่เพียงการเปิดเผยข้อมูลมากขึ้นเท่านั้น จุดสำคัญคือผู้ใช้สามารถทำอะไรได้กับข้อมูลนั้น

ด้วยประวัติ kWh รายครึ่งชั่วโมง ผู้ใช้สามารถวิเคราะห์การนำเข้าและส่งออกไฟฟ้าล่าสุด ระบุรูปแบบการใช้งาน และประเมินว่ากลยุทธ์ด้านโซลาร์หรือการควบคุมโหลดได้ผลจริงหรือไม่ สิ่งนี้สนับสนุนเป้าหมายในภาพรวมของ IAMMETER คือการเปลี่ยนข้อมูลจากการมอนิเตอร์พลังงานให้เป็นการตัดสินใจที่ใช้ได้จริง ซึ่งช่วยเพิ่มประสิทธิภาพการใช้พลังงานและลดค่าไฟฟ้า

สำหรับผู้ใช้ที่ใช้ IAMMETER ร่วมกับแพลตฟอร์มระบบอัตโนมัติ ประวัติพลังงานในเครื่องยังเป็นชั้นข้อมูลที่สะดวกสำหรับการทดสอบและตรวจสอบตรรกะการควบคุมได้ด้วย ตัวอย่างเช่น ผู้ใช้ Home Assistant ที่เพิ่มประสิทธิภาพการใช้พลังงานส่วนเกินจากโซลาร์สามารถดูการเปลี่ยนแปลง kWh ล่าสุดควบคู่กับพฤติกรรมของระบบอัตโนมัติ ดูกรณีการใช้งานที่เกี่ยวข้องได้ที่ ระบบอัตโนมัติพลังงานแสงอาทิตย์ของ Home Assistant กับ IAMMETER

คำถามที่พบบ่อย

API นี้แทนประวัติพลังงานระยะยาวได้หรือไม่

ไม่ได้ API นี้เก็บข้อมูลได้สูงสุด 96 รายการ หรือข้อมูลรายครึ่งชั่วโมง 48 ชั่วโมง ใน RAM โดยออกแบบมาสำหรับประวัติในเครื่องระยะสั้น ข้อมูลจะหายไปหลังการรีบูต

ทำไม `Datas` จึงว่างเปล่าหลังการบูต

หลังการบูต โมดูลต้องมีเวลาตาม UTC ที่ถูกต้องและเฟรมข้อมูลมิเตอร์ที่ถูกต้องก่อนจึงจะบันทึกตัวอย่างประวัติได้ จนกว่าจะเก็บตัวอย่างที่ถูกต้องได้เพียงพอ API อาจคืนอาร์เรย์ Datas ที่ว่างเปล่า

Timestamp อ้างอิงจากเวลาท้องถิ่นหรือไม่

ไม่ใช่ ช่วงเวลาที่ใช้สุ่มเก็บข้อมูลจัดเรียงตามขอบเขตครึ่งชั่วโมงของเวลา UTC

ซอฟต์แวร์ควรตีความอาร์เรย์ค่าอย่างไร

ควรอ่านฟิลด์ channels ก่อนเสมอ ค่าในแต่ละอาร์เรย์ Datas[].values เรียงลำดับตามชื่อช่องสัญญาณ