IAMMETER มิเตอร์พลังงาน Wi-Fi สามารถส่งข้อมูลการวัดโดยตรงไปยังเซิร์ฟเวอร์, MQTT broker หรือแพลตฟอร์มข้อมูลที่ลูกค้าควบคุมเอง ช่วยให้นักพัฒนาและนักรวมระบบสามารถสร้าง EMS, BMS, บริการ IoT, ฐานข้อมูล หรือแดชบอร์ดตรวจสอบของตนเองได้โดยไม่ต้องใช้ IAMMETER-Cloud เป็นปลายทางข้อมูล
คู่มือนี้แนะนำการรวมระบบจากฝั่งเซิร์ฟเวอร์ที่รับข้อมูล:
IAMMETER meter
│
│ HTTP/HTTPS, MQTT/MQTTS or TCP/TLS
▼
Customer ingestion service
│
├── Raw-payload log
├── Time-series or relational database
├── EMS / BMS / ERP
└── Dashboard, report and alarm services
สำหรับความสามารถของเฟิร์มแวร์ฝั่งมิเตอร์และรูปแบบที่อยู่ โปรดดู IAMMETER Local API and Open Interface Guide สำหรับการเลือกสถาปัตยกรรม ดู Develop Your Own Energy Monitoring System
มิเตอร์สามารถส่งข้อมูลการวัดโดยใช้โปรโตคอลหลายรูปแบบ ระบบรับควรเลือกเส้นทางหลักหนึ่งเส้นทาง
| Transport | คอมโพเนนต์ของเครื่องรับ | จุดเริ่มต้นที่ดีสำหรับ |
|---|---|---|
| HTTP / HTTPS | Web endpoint | REST backends และการรวมระบบครั้งแรกที่ง่ายที่สุด |
| MQTT / MQTTS | MQTT broker และ subscriber | แพลตฟอร์ม IoT และไปป์ไลน์ข้อความที่มีอยู่ |
| TCP / TLS | Socket listener | ตัวรวบรวมเฉพาะและบริการโปรโตคอลแบบกำหนดเอง |
HTTP เป็นวิธีที่ง่ายที่สุดในการตรวจสอบ payload แรก เนื่องจากเครื่องรับทดสอบอย่างเป็นทางการสามารถเริ่มต้นได้ด้วยตัวอย่าง Node.js ขนาดเล็ก MQTT เป็นตัวเลือกที่ดีเมื่อมี broker อยู่ในระบบอยู่แล้ว TCP/TLS ให้การรวมระบบซ็อกเก็ตระดับต่ำกว่าแต่ต้องใช้การออกแบบฝั่งรับมากกว่า
รูปแบบการส่งข้อมูลแบบปลอดภัยและพอร์ตแบบกำหนดเองอยู่ใน คู่มือเฟิร์มแวร์ปัจจุบัน แทนที่จะกล่าวซ้ำที่นี่
IAMMETER มีตัวอย่าง Node.js HTTP receiver อย่างเป็นทางการสำหรับการทดสอบการรวมระบบ
ดาวน์โหลดตัวอย่างจาก:
รัน:
node Server.js
ตัวอย่างจะฟังบนพอร์ต 8000 เมื่อมีคำขอเข้ามา มันจะ:
200 พร้อมการตอบสนอง JSON ขนาดเล็กตัวอย่างนี้ตั้งใจให้เรียบง่ายที่สุด ไม่มีการรับรองความถูกต้อง, การจัดเก็บถาวร, การตรวจสอบ, การจำกัดอัตราหรือความปลอดภัยสำหรับการใช้งานจริง
ก่อนกำหนดค่ามิเตอร์ ให้ยืนยันว่า:
สำหรับการทดสอบใน LAN มิเตอร์และเครื่องรับสามารถใช้เครือข่ายท้องถิ่นเดียวกันได้โดยไม่ต้องเชื่อมต่ออินเทอร์เน็ต สำหรับเครื่องรับระยะไกล ไซต์ต้องมีเส้นทางไปยังเซิร์ฟเวอร์
ใน WebUI ของมิเตอร์ปัจจุบัน ให้เลือกโหมดการทำงาน HTTP และป้อนปลายทางเช่น:
{server-address}:8000/upload
HTTPS endpoints สามารถใช้พอร์ตเริ่มต้นหรือพอร์ตที่กำหนดเอง กฎที่อยู่ปัจจุบัน รวมถึง https://host:port มีอยู่ใน ส่วน HTTP/HTTPS ของเฟิร์มแวร์
หลังจากบันทึกการตั้งค่า ให้ตรวจสอบคอนโซลของเครื่องรับเพื่อดูเส้นทางคำขอและ JSON ที่อัปโหลด เก็บ payload ดิบแรกนี้ไว้เป็น fixture ทดสอบสำหรับการทดสอบ parser และฐานข้อมูลในภายหลัง
IAMMETER ใช้โครงสร้าง JSON การวัดหลักที่สอดคล้องกันในทุกรูปแบบการส่งข้อมูลที่รองรับ Transport เป็นตัวกำหนดวิธีการส่ง payload แต่รูปแบบการวัดยังคงสอดคล้องกัน
Payload โดยปกติประกอบด้วยฟิลด์ระดับอุปกรณ์ เช่น:
SN — หมายเลขซีเรียลของมิเตอร์ใช้ระบุอุปกรณ์version — เวอร์ชันเฟิร์มแวร์ของมิเตอร์method — ประเภทข้อความหรือ payload methodData หรือ Datas — อาร์เรย์การวัดData ใช้สำหรับช่องการวัดเดียว Datas ประกอบด้วยอาร์เรย์การวัดหลายชุดสำหรับมิเตอร์หลายช่องหรือสามเฟส
ตัวอย่างโครงสร้างช่องเดียว:
{
"method": "uploadsn",
"mac": "B0F8932A295C",
"version": "i.75.98.71y",
"server": "em",
"SN": "12345678",
"Data": [228.91, 1.61, 225, 15066.47, 0]
}
อย่า hard-code จำนวนอาร์เรย์เดียวสำหรับทุกมิเตอร์ จำนวนช่องและฟิลด์ที่มีอยู่ขึ้นอยู่กับรุ่นมิเตอร์และฟีเจอร์การวัดที่เปิดใช้งาน
ใช้คำจำกัดความที่ authoritative เมื่อ implement parser:
แยกการประมวลผลเฉพาะรุ่นออกจากตัวรับสัญญาณ
ตัวอย่างเช่น WEM3046T และ WEM3046TE วัดเอาต์พุตรอง 5 A ของ CT ภายนอก ค่าที่วัดได้ต้องแปลงด้วยอัตราส่วน CT ที่เกี่ยวข้องเพื่อให้ได้ค่าด้านปฐมภูมิ นี่คือคุณลักษณะของมิเตอร์และ CT ไม่ใช่ความแตกต่างของ HTTP, MQTT หรือ TCP
ไปป์ไลน์การรับข้อมูลในทางปฏิบัติจึงแยก:
เก็บข้อมูลให้เพียงพอที่จะสร้างและวินิจฉัยการอ่านค่าดั้งเดิม
โมเดลขั้นต่ำที่มีประโยชน์ประกอบด้วย:
| ฟิลด์ | วัตถุประสงค์ |
|---|---|
| Meter SN | จับคู่ payload กับอุปกรณ์ที่ลงทะเบียน |
| Channel or phase index | แยกข้อมูลเฟสเดียว, split-phase และสามเฟส |
| Server receive time | ให้ timestamp การรับที่สอดคล้องกัน |
| Voltage | การวัดทางไฟฟ้า |
| Current | การวัดทางไฟฟ้า |
| Active power | กำลังไฟฟ้าจริงที่นำเข้า/ส่งออก หรือ input สำหรับการคำนวณโหลด |
| Import kWh | พลังงานสะสมที่นำเข้า |
| Export kWh | พลังงานสะสมที่ส่งออก |
| Firmware version | รองรับการแก้ปัญหาและความเข้ากันได้ของ parser |
| Raw payload | รองรับการ replay, การตรวจสอบและการแก้ไข parser |
ฟิลด์เพิ่มเติมเช่นความถี่, ตัวประกอบกำลัง และการวัดรีแอกทีฟควรจัดเก็บเมื่อรุ่นที่เลือกและการกำหนดค่าให้ข้อมูลเหล่านั้น
สำหรับระบบการผลิต พิจารณาเก็บ:
วิธีนี้ทำให้แก้ไขตรรกะการแยกวิเคราะห์หรืออัตราส่วน CT ได้ง่ายขึ้นโดยไม่สูญเสีย payload ดั้งเดิม
บันทึกเวลาที่เซิร์ฟเวอร์ยอมรับ payload หากระบบธุรกิจใช้ timestamp ของอุปกรณ์หรือแหล่งที่มาด้วย ให้เก็บทั้งสองค่าแยกกันแทนที่จะแทนที่ค่าหนึ่งด้วยอีกค่าหนึ่ง
ความล่าช้าของเครือข่าย, การเชื่อมต่อใหม่ และการประมวลผลในคิวอาจทำให้เวลาในการรับแตกต่างจากเวลาที่วัด กำหนด timestamp ที่ใช้โดยกราฟ, การเรียกเก็บเงิน และการแจ้งเตือนก่อนการปรับใช้ในระบบการผลิต
สำหรับการรับข้อมูลผ่าน MQTT ระบบของลูกค้าต้องจัดเตรียม:
IAMMETER เผยแพร่ข้อมูลแบบ real-time ภายใต้หัวข้ออุปกรณ์เช่น:
device/{SN}/realtime
ใช้คู่มือเฉพาะสำหรับการกำหนดค่า broker, ข้อมูลรับรอง, หัวข้อ และข้อควรพิจารณา MQTTS:
Home Assistant MQTT Discovery ไม่จำเป็นสำหรับการรวมระบบกับเซิร์ฟเวอร์ของลูกค้าทั่วไป
IAMMETER มีตัวอย่าง TCP listener ขนาดเล็กใน Node.js:
ตัวอย่างฟังบนพอร์ต 8000 และแสดงข้อมูลที่ได้รับ เครื่องรับ TCP สำหรับการผลิตต้องเพิ่ม:
อย่าสมมติว่าเหตุการณ์ data หนึ่งครั้งจากซ็อกเก็ตเท่ากับหนึ่งข้อความแอปพลิเคชันที่สมบูรณ์เสมอ
ตัวอย่าง TLS อย่างเป็นทางการสาธิต TLS listener พร้อมคีย์และใบรับรองเซิร์ฟเวอร์:
ก่อนใช้งานจริง ให้แทนที่ใบรับรองและการตั้งค่าตัวอย่างด้วยใบรับรอง, การจัดการคีย์ และการกำหนดค่าความปลอดภัยที่องค์กรอนุมัติ เครื่องรับควรบันทึกความล้มเหลว TLS แยกจากความล้มเหลวของการตรวจสอบ payload
รูปแบบที่อยู่ฝั่งมิเตอร์สำหรับ TCP และ TLS อยู่ใน คู่มืออินเทอร์เฟซเฟิร์มแวร์
เฟิร์มแวร์ปัจจุบันรองรับช่วงเวลาอัปโหลดไปยังเซิร์ฟเวอร์บุคคลที่สามต่ำสุดที่ 2 วินาที ช่วงเวลาสั้นมีประโยชน์เฉพาะเมื่อระบบรับ, ที่จัดเก็บ และแอปพลิเคชันต้องการความละเอียดเพิ่มเติม
ประมาณการบันทึกที่สร้างต่อมิเตอร์:
| ช่วงเวลาอัปโหลด | บันทึกต่อมิเตอร์ต่อวัน | 100 มิเตอร์ต่อวัน | 1,000 มิเตอร์ต่อวัน |
|---|---|---|---|
| 60 วินาที | 1,440 | 144,000 | 1,440,000 |
| 10 วินาที | 8,640 | 864,000 | 8,640,000 |
| 2 วินาที | 43,200 | 4,320,000 | 43,200,000 |
ตัวเลขเหล่านี้แสดงถึงเหตุการณ์อัปโหลด ไม่จำเป็นต้องเป็นแถวในฐานข้อมูล Payload สามเฟสอาจถูกทำให้เป็นมาตรฐานเป็นบันทึกหลายช่อง และดัชนี, การเก็บรักษา payload ดิบ หรือพื้นที่จัดเก็บแบบจำลองจะเพิ่มปริมาณฐานข้อมูลจริง
การวางแผนความจุควรรวมถึง:
สำหรับการควบคุมหรืออัตโนมัติแบบหนึ่งวินาทีบน LAN เดียวกัน พิจารณา Modbus TCP แทนการใช้ไปป์ไลน์อัปโหลดระยะไกล
เครื่องรับในระบบการผลิตควรคาดหวังความล้มเหลวของเครือข่ายและแอปพลิเคชัน
ตรวจสอบอย่างน้อย:
เก็บ payload ที่ผิดรูปแบบในเส้นทางการวินิจฉัยที่ควบคุมโดยไม่ให้ขัดขวางอุปกรณ์ที่ถูกต้อง
อย่าสมมติว่าทุกช่วงเวลาจะสร้างบันทึกที่จัดเก็บถาวรหนึ่งรายการเสมอ การขัดจังหวะเครือข่าย, พฤติกรรมการเชื่อมต่อใหม่, การลองใหม่ของเซิร์ฟเวอร์ หรือการประมวลผลแอปพลิเคชันอาจทำให้เกิดเหตุการณ์การรับที่ขาดหายหรือซ้ำ
กำหนดว่าระบบธุรกิจจะ:
ตรวจสอบมากกว่าแค่กระบวนการเว็บหรือซ็อกเก็ต สัญญาณที่มีประโยชน์รวมถึง:
สำหรับเครื่องรับที่เชื่อมต่ออินเทอร์เน็ต:
ตรวจสอบพฤติกรรมเฟิร์มแวร์ MQTTS, TLS และ HTTPS ปัจจุบันใน คู่มือเฟิร์มแวร์และอินเทอร์เฟซเปิด ก่อนเลือกรูปแบบความปลอดภัย
เอกสารต้นฉบับของหน้านี้เน้นการกำหนดค่าเฟิร์มแวร์มิเตอร์รุ่นเก่า ภาพหน้าจอเหล่านี้ถูกเก็บไว้สำหรับผู้ใช้ที่ระบุการติดตั้งที่มีอยู่เท่านั้น สำหรับการรวมระบบใหม่ ให้ใช้ WebUI ปัจจุบันและ เฟิร์มแวร์ล่าสุด
เอกสารเฟิร์มแวร์รุ่นก่อนหน้านี้ยังใช้วิธีการกำหนดค่า /api/uploadinterval ในเครื่องและอธิบายขั้นต่ำหกวินาที เฟิร์มแวร์ปัจจุบันแสดงช่วงเวลาใน WebUI และรองรับขั้นต่ำที่ 2 วินาที
อัปเดตล่าสุด: 16 กรกฎาคม 2026
มิเตอร์พลังงาน Wi-Fi สามเฟส (WEM3080T)
มิเตอร์พลังงาน Wi-Fi เฟสเดียว (WEM3080)
มิเตอร์พลังงาน Wi-Fi สามเฟส (WEM3046T)
มิเตอร์พลังงาน Wi-Fi สามเฟส (WEM3050T)