EWG · Smart Water · v2 · ต.ค. 2026
Smart Water Re-implementation
SCADA Enhancement + AI for Demand & Supply Optimization — 6 โมดูลตั้งแต่ระบบควบคุม Real-time ถึง AI วางแผนสูบจ่ายน้ำ · ไฟล์ต้นฉบับ: AngelaVault/angela-docs/EWG/Smart_Water_Reimplement-v2-noBG.pdf
M1 SCADAM2 Datalogger 100 จุดM2.1 LoRaWANM3 PMEM4 AQUISM5 Data WarehouseM6 AI Optimization
Original slides · 11 pages
Timeline & Milestones
ภาพรวม 6 โมดูล จาก Q4 2026 ถึง Q3 2027 และต่อเนื่องปีที่ 2–3
| Module | ช่วงเวลา | Scope | Target |
|---|---|---|---|
| M1: System Platform (SCADA) | ต.ค. 2026 – ก.ย. 2027 | พัฒนา System Platform ใหม่ ทดแทน Citect (EOL) | SCADA Monitor & Control ครอบคลุม Water Grid ทั้งหมด |
| M2: Datalogger (100 Points) | ม.ค. – ก.ย. 2027 | ติดตั้ง Flow & Pressure Sensor + Data Logger 100 จุด | มีข้อมูลแรงดันในระบบท่อ ครอบคลุมจุดสำคัญ |
| M3: PME (Power Monitoring) | ต.ค. 2026 – ก.ย. 2027 | ระบบบริหารพลังงาน + มิเตอร์ไฟฟ้าที่สถานีสูบน้ำและ Substation | Monitor ต้นทุนไฟฟ้าตลอดเวลา ปรับแผนการสูบล่วงหน้า |
| M6: AI for Demand & Supply Optimization | ต.ค. 2026 – ก.ย. 2027 | AI Platform วางแผนและตัดสินใจสูบจ่ายน้ำ รองรับ EPANET | ทางเลือกแผนสูบจ่าย: ต้นทุนต่ำ แรงดันเสถียร/ปลอดภัย ปริมาณน้ำเพียงพอ |
| M4: AQUIS Hydraulic Model | Year 2 | พัฒนาโครงข่ายท่อให้ครบถ้วน | Online Simulation Model |
| M5: Data Warehouse | ต.ค. 2026 – มี.ค. 2027 · เม.ย. – ก.ย. 2027 · Year 2 | ออกแบบ Data Platform ของ EWG → Implement DW: Financial, Operational & Water Grid → ขยาย Asset & Maintenance, Customer & Commercial | Data Blueprint + TOR ที่จะ Implement |
M1: System Platform (New SCADA)
ยกระดับจาก Citect SCADA 7.4 สู่ AVEVA System Platform 2026 — ฐานควบคุมและข้อมูล Real-time ของระบบท่อทั้งหมด · การยกระดับ AVEVA System Platform เดิมให้รองรับทั้ง Monitoring และ Control สำหรับ 16 สถานีสูบน้ำ และ 12 สถานีที่เกี่ยวข้อง
| งาน | รายละเอียด |
|---|---|
| Upgrade Platform | อัปเกรด AVEVA System Platform เป็นเวอร์ชันปัจจุบัน |
| MMI Standard Design | กราฟิก P&ID-based, Reusable symbols, Faceplates, Trend และ Configuration screens |
| Control & Data Modification | ปรับระบบแสดงผล, Data storage, อ่านค่า Power meter, สร้าง Historian tag ใหม่ และส่ง Notify แจ้งเตือน |
| PLC Gateway & Validation | เขียนโปรแกรม PLC Gateway และทำ FAT/SAT ตรวจฟังก์ชันการทำงานทั้งหมด |
- •ปัญหา: Citect 7.4 SP1 หมดอายุการสนับสนุน (End-of-Life) เสี่ยงด้านความปลอดภัยและเสถียรภาพ
- •ปัญหา: ติดตั้งอุปกรณ์ใหม่ต้องใช้เวลานานแก้ Tag / Graphic / Alarm จำนวนมาก มีโอกาสผิดพลาด
- •ปัญหา: ไม่รองรับ Dashboard และรายงานผู้บริหาร ข้อมูลยังจัดทำแบบ Manual · ขาดผู้เชี่ยวชาญดูแลระบบเก่า ต้นทุนดูแลสูงขึ้นเรื่อย ๆ
- •แนวทาง: สถาปัตยกรรม Object-Based ใช้แม่แบบอุปกรณ์ (ปั๊ม วาล์ว มิเตอร์) แก้ไขจากส่วนกลาง
- •แนวทาง: รวมศูนย์ข้อมูลทุกสถานีสูบเข้าแพลตฟอร์มเดียว เชื่อมต่อ PME ผ่าน OPC UA และ Historian
- •ประโยชน์: ลดเวลาและต้นทุนงานวิศวกรรม 50–80% จากประสบการณ์โครงการจริง · ลด Downtime
- •ประโยชน์: เป็นฐานข้อมูล Reliable ให้ทุกโมดูล — ถ้าไม่ทำ โมดูลอื่นจะขาดข้อมูลที่เชื่อถือได้ · รองรับ IoT, Analytics และการบำรุงรักษาเชิงคาดการณ์
- •แผน: ~7 เดือน (28 สัปดาห์) ตามแผน MMI SCADA Phase 2 · ติดตั้งสถานีสูบน้ำ 13 แห่ง + Head Tank / Sub Station 20 แห่ง · Migrate Historian Tag / Report → ทดสอบระบบ → Commissioning & Standby
- •งบประมาณ: X — ค่า Implementation โดยใช้ Software License, Server, Infrastructure ที่จัดซื้อไว้แล้ว
- •บุคลากร: วิศวกร SCADA / ผู้ดูแลระบบประจำ · ต้องอบรมทีมปฏิบัติการก่อน Go-live
M2: Datalogger 100-point (Pressure)
ตรวจวัดแรงดันในเส้นท่อแบบ Real-time ตลอดแนวท่อหลัก
- •ปัญหา: ข้อมูลแรงดันไม่ต่อเนื่อง ตรวจพบความผิดปกติล่าช้า
- •แนวทาง: ติดตั้ง Datalogger 100 จุด ครอบคลุมแนวท่อหลัก เก็บค่าทุก 15 นาที
- •แนวทาง: ส่งข้อมูลผ่าน 4G → MQTT → Historian → Dashboard / SCADA · มากกว่า 3.5 ล้าน Records/ปี ป้อนเข้า Hydraulic Model
- •ประโยชน์: เฝ้าระวังปัญหาแรงดันสูง/ต่ำผิดปกติ
- •แผน: รวม 9 เดือน — ออกแบบและจัดซื้อ / ทดสอบ FAT → ติดตั้งจริง / เชื่อมระบบ → Commissioning และอบรม
- •งบประมาณ: X — CAPEX: อุปกรณ์+ติดตั้ง 2.5 · Platform 1.0 · Commissioning 0.5 · OPEX 1.0 ลบ./ปี (SIM · Maintenance · Support)
- •บุคลากร: ผู้ดูแลระบบ Monitoring / วิเคราะห์ข้อมูล · ใช้ทีมปฏิบัติการเดิมร่วมกับระบบแจ้งเตือนอัตโนมัติ
ทางเลือกการสื่อสารที่ถูกกว่า 4G: ดูหัวข้อ "M2.1 LoRaWAN แทน 4G?" ถัดไป
M2.1 ทางเลือกการสื่อสาร — LoRaWAN แทน 4G?
LoRaWAN คือเครือข่ายวิทยุไร้สายแบบกินไฟต่ำ ส่งได้ไกล (LPWAN) ออกแบบมาให้เซนเซอร์จำนวนมากส่งข้อมูลชิ้นเล็กไม่กี่ครั้งต่อชั่วโมง — ตรงกับลักษณะ Datalogger แรงดันของ M2 ที่เก็บค่าทุก 15 นาที · หมายเหตุ: MQTT เป็นแค่รูปแบบการส่งข้อความ ไม่ใช่สายส่ง ตัวที่ LoRaWAN มาแทนคือ "4G" ส่วน MQTT ยังใช้ต่อได้ที่ปลายทาง (Network Server ส่งข้อมูลเข้า Historian ผ่าน MQTT ได้)
| หัวข้อ | 4G (แผนในสไลด์) | LoRaWAN | NB-IoT |
|---|---|---|---|
| ค่าใช้คลื่น / รายเดือน | ค่าซิมทุกจุด | ไม่มี (ย่านไม่ต้องขอใบอนุญาต) — ลงทุน Gateway เอง | ค่าซิมทุกจุด (ถูกกว่า 4G) |
| ไฟเลี้ยงที่จุดวัด | มักต้องมีไฟเลี้ยง / โซลาร์ | แบตเตอรี่หลายปี | แบตเตอรี่ได้ แต่กินไฟมากกว่า LoRaWAN |
| ระยะ / โครงข่าย | ตามเสาผู้ให้บริการ | 2–5 กม. ในเมือง ไกลกว่าในที่โล่ง ต่อ Gateway | ตามเสาผู้ให้บริการ |
| ขนาด / ความถี่ข้อมูล | ไม่จำกัดในทางปฏิบัติ | เล็ก ส่งไม่ถี่ | เล็กถึงปานกลาง |
| ควบคุม Real-time | ได้ | ไม่เหมาะ | จำกัด |
| เหมาะกับ | สถานีสูบ จุดควบคุม | Datalogger แรงดัน / มิเตอร์ จำนวนมาก | Datalogger ที่อยู่ในพื้นที่สัญญาณดี ไม่อยากตั้ง Gateway |
- •เส้นทางข้อมูล: Datalogger → (วิทยุ LoRa) → Gateway → Network Server → MQTT → Historian / SCADA — ส่วนท้ายเหมือนแผนเดิม เปลี่ยนแค่ช่วงแรก
- •ไม่ต้องมีซิมทุกจุด: 4G ต้องจ่ายค่าซิมรายเดือนทุก Datalogger ส่วน LoRaWAN ใช้ย่านความถี่ที่ไม่ต้องขอใบอนุญาตใช้คลื่น (ไทยใช้ 920–925 MHz แผน AS923) ต้นทุนย้ายไปอยู่ที่ Gateway ที่ EWG เป็นเจ้าของเอง
- •Gateway เดียวคุมได้หลายจุด: ระยะราว 2–5 กม. ในเมือง ไกลกว่านั้นในพื้นที่โล่ง และรับอุปกรณ์ได้หลักพันต่อ Gateway
- •แบตเตอรี่อยู่ได้หลายปี: วิทยุกินไฟน้อยมาก ไม่ต้องเดินสายไฟไปที่จุดวัด — 4G กินไฟมากกว่าจนมักต้องมีไฟเลี้ยงหรือแผงโซลาร์ ค่าแรงภาคสนามจึงเป็นต้นทุนที่ลดได้มากที่สุด
- •ข้อจำกัด: ส่งได้ครั้งละหลักสิบถึงร้อยไบต์ อัตราส่งต่ำ และสั่งงานกลับไปยังอุปกรณ์ (Downlink) ได้จำกัด — ไม่เหมาะกับการควบคุมปั๊มหรือ SCADA ที่ต้องเห็นค่าทันที และไม่เหมาะกับการจับคลื่นแรงดันกระชาก (Transient / Water hammer) ซึ่งต้องบันทึกถี่ระดับวินาทีที่ตัว Logger
- •ข้อควรระวังสำหรับ EWG: M2 มีแค่ 100 จุด และกระจายตามแนวท่อหลักระยะไกล — ค่าซิม 100 ใบเป็นส่วนเล็กของ OPEX 1.0 ลบ./ปี ส่วนจำนวน Gateway ที่ต้องตั้งตามแนวท่ออาจมาก ต้องทำ Coverage survey ก่อนสรุปว่าถูกกว่าจริง
- •NB-IoT เป็นทางเลือกที่สูสี: กินไฟต่ำเหมือนกันและไม่ต้องตั้ง Gateway เอง (ใช้เสาของผู้ให้บริการ) แต่ยังมีค่ารายเดือนต่อซิม และต้องเช็ก Coverage ตามแนวท่อเช่นกัน
ข้อเสนอ: ใช้แบบผสม — LoRaWAN (หรือ NB-IoT) กับจุดวัดแรงดัน/น้ำรั่วที่มีจำนวนมาก ส่งทุก 15 นาที – 1 ชม. ก็พอ · 4G / ไฟเบอร์ กับสถานีสูบและจุดที่ต้องควบคุม Real-time · ตัดสินด้วยตัวเลข TCO 5 ปี (อุปกรณ์ + Gateway + ค่าซิม + ค่าเปลี่ยนแบต/ไฟเลี้ยง) หลัง Coverage survey ตามแนวท่อจริง
M3: PME — Power Monitoring Expert
ระบบบริหารจัดการพลังงานไฟฟ้าให้ครอบคลุมสถานีสูบน้ำในโครงข่ายท่อ · 19 สถานีในขอบเขต (5 New + 14 Existing) · 64 Power Meters · 6 VSDs · 120 OPC Tags
| ขอบเขตงาน | รายละเอียด |
|---|---|
| PME New Station Service | ติดตั้ง 64 Power Meters และ 6 VSDs พร้อม Software setup, Configuration, Display/Report, Testing และ Documentation |
| PME Update & Maintenance | ตรวจ Dashboard/Report 14 สถานีเดิม, Verify communication, จัดการ Database (SQL/Fragment), Archive และตรวจ Server resource |
| OPC Configuration | ติดตั้ง Data Exchange Module และตั้งค่า OPC Slave 120 Tags พร้อม Testing และเอกสารประกอบ |
- •ปัญหา: สถานีสูบน้ำ 5 แห่งยังไม่เชื่อมเข้าระบบ PME · ไม่เห็นต้นทุนไฟฟ้าต่อหน่วยน้ำ (kWh/m³) แบบทันที ทั้งที่ค่าไฟคือต้นทุนหลัก · วิเคราะห์ประสิทธิภาพปั๊มย้อนหลังได้ยาก
- •แนวทาง: พัฒนาโปรแกรม PME เดิม ดึงข้อมูลจาก Power Meter ที่ติดตั้งอยู่แล้ว ไม่ต้องซื้อ Hardware ใหม่ ไม่ต้องหยุดจ่ายไฟเพื่อติดตั้ง · ข้อมูลพลังงานไหลเข้าฐานเดียวกับ SCADA / Data Warehouse
- •ประโยชน์: เห็นต้นทุนพลังงานทันที นำไปปรับแผนเดินเครื่อง · ลงทุนต่ำ คืนผลเร็ว · เป็นข้อมูลตั้งต้นให้ Optimization คำนวณแผนสูบจ่ายต้นทุนต่ำสุด
- •แผน: 12 เดือน ดำเนินการได้ทันทีโดยไม่กระทบการสูบจ่ายน้ำ
- •งบประมาณ: X — พัฒนาโปรแกรมและเชื่อมต่อข้อมูลรวม 19 สถานี ไม่มีค่าใช้จ่าย Hardware
- •บุคลากร: ใช้ทีมไฟฟ้า/SCADA
M4: AQUIS — Hydraulic Model
สร้าง Digital Twin ของโครงข่ายน้ำ เพื่อจำลอง วิเคราะห์ และวางแผนการสูบจ่ายอย่างแม่นยำ
- •ปัญหา: ข้อมูลโครงข่าย GIS / ท่อ / ปั๊ม ไม่ตรงกับหน้างาน ผลคำนวณไม่น่าเชื่อถือ · ทีมใช้เวลา 70–80% เตรียมข้อมูลใน Excel เหลือเวลาวิเคราะห์เพียง 20%
- •ปัญหา: การตั้งค่าโมเดลพึ่งพาผู้เชี่ยวชาญเฉพาะบุคคล/ผู้รับจ้าง · SCADA / GIS / Billing / Model ไม่เชื่อมโยงกัน
- •แนวทาง: ปรับปรุงข้อมูลโครงข่ายให้ครบถ้วน สร้าง Hydraulic Model ที่ Calibrate แล้ว · เชื่อม GIS + SCADA + Historian เป็น Smart Water Platform / Digital Twin
- •แนวทาง: วิเคราะห์ 3 มิติ Pressure · Flow · Energy พร้อมแจ้งเตือนล่วงหน้า · ต่อยอดเป็น Online Model + AI Optimization
- •ประโยชน์: วางแผนแรงดัน ลดน้ำสูญเสีย (NRW) และลดพลังงานสูบน้ำ · ทดสอบ Scenario ก่อนลงมือจริง ลดความเสี่ยงการลงทุนท่อ/ปั๊ม · ลดการพึ่งพาตัวบุคคล
- •แผน: 12 เดือน 5 ขั้นตอน — ด.1–3 เตรียมข้อมูล+สำรวจ · ด.3–5 สร้างโมเดล · ด.5–7 เชื่อม Smart Water · ด.6–8 Calibrate · ด.8–12 Optimization นำร่อง + Go-live
- •งบประมาณ: X — เตรียมข้อมูล / สร้างโมเดล / เชื่อมระบบจาก M1, M2, M3, M4 · Calibrate Model / Optimization / Training
- •บุคลากร: วิศวกรแบบจำลอง · มี Knowledge Transfer จากที่ปรึกษา
M5: Data Warehouse
รวมข้อมูลการเงิน ปฏิบัติการ และลูกค้า เป็นฐานข้อมูลเดียว พร้อมธรรมาภิบาลข้อมูล เพื่อให้ AI ทำงานได้แม่นยำ
- •ปัญหา: รับรู้ข้อมูลล่าช้า การทำงานขาดประสิทธิภาพ · เสี่ยงจากการพึ่งพาตัวบุคคล · ข้อจำกัดในการกำหนดราคาและส่วนลด ขาดความเชื่อมั่นข้อมูลทุกระดับ · ปรับตัวรองรับธุรกิจใหม่และวางแผนระยะยาวได้ยาก
- •แนวทาง: ออกแบบ Data Architecture + Data Governance รองรับการเทรน AI · Implement รายโดเมน Financial & Accounting → Operational & Water Grid → Customer · เชื่อมข้อมูลกับ SCADA / PME / AQUIS / AI
- •ประโยชน์: ข้อมูลชุดเดียวทั้งองค์กร ตัดสินใจเร็วและเชื่อถือได้ · พยากรณ์ความต้องการใช้น้ำ คำนวณต้นทุน ใช้ทำ Optimization · รองรับการกำหนดราคา ส่วนลด และธุรกิจใหม่
- •แผน: ปีที่ 1 ออกแบบสถาปัตยกรรม + Governance และ Implement DW ส่วนการเงิน/ปฏิบัติการ/ลูกค้า · ปีที่ 2 ขยายโดเมน Asset / Customer และเชื่อม AI Optimization · สอดคล้อง Roadmap ภาพรวม 3–5 ปี
- •งบประมาณ: X — ประมาณการงบลงทุนรวมโครงการ Data Warehouse
- •บุคลากร: Data Engineer / Data Steward ประจำ · ทีมที่ปรึกษา CU
M6: AI for Demand & Supply Optimization
ระบบวางแผน Demand & Supply และตัดสินใจสูบจ่ายน้ำร่วมกับ EPANET — ขับเคลื่อนด้วย Business Constraints & Risks หาทางเลือกที่คุ้มค่าที่สุดด้วยหลักคณิตศาสตร์
| ขั้น | สิ่งที่อยู่ในขั้นนี้ |
|---|---|
| Data Source | แหล่งน้ำในพื้นที่ · ทิศทางการจ่ายน้ำ · การเลือกแหล่งจ่ายตามเงื่อนไข · น้ำสูญเสียในเส้นท่อ · ต้นทุนคงที่/ผันแปร · อัตราการสูบรายวันกับปริมาณจ่าย · การสูบผันน้ำ/น้ำฝาก · แผนจ่ายน้ำตามต้นทุนรวมและแผนสำรองน้ำ · การบริหารต้นทุนน้ำในพื้นที่ |
| Demand Forecast | ความต้องการใช้น้ำล่วงหน้าของลูกค้าแต่ละราย · แยกตามพื้นที่ / แนวท่อ · ความต้องการของโครงการใหม่ที่กำลังจะเกิดขึ้น |
| Cost per unit | Cost Allocation · คำนวณต้นทุนต่อหน่วย · แยกรายพื้นที่ · แยกรายลูกค้า |
| Optimization (ผลลัพธ์) | เลือกแผนสูบจ่ายเส้นทางน้ำที่ "เหมาะสมที่สุด": ต้นทุนค่าไฟต่อ ลบ.ม. ต่ำ/คุ้มค่าที่สุด · แนะนำตารางเดินเครื่องสูบน้ำ · รักษาแรงดันเสถียรและปลอดภัย · ความเสี่ยงในการดำเนินงานต่ำ |
- •ปัญหา: วางแผนสูบจ่ายน้ำด้วยประสบการณ์ ไม่มีระบบช่วยตัดสินใจ · แผนไม่ถูกตรวจสอบกับข้อจำกัดจริงของระบบ · ผู้บริหารและผู้ปฏิบัติการเห็นข้อมูลคนละชุด
- •แนวทาง: AI Forecast ร่วมกับ EPANET ระหว่างรอ AQUIS · คาดการณ์ → ตรวจข้อจำกัด → จัดลำดับทางเลือก → ติดตาม
- •แนวทาง: Track A พยากรณ์ + Optimization · Track B EPANET + WNTR · Explanation Layer แยก Dashboard ตามบทบาท
- •ประโยชน์: ป้องกันแผนที่ทำไม่ได้จริงและการหยุดจ่ายน้ำ · เลือกแผนคุ้มค่าที่สุดภายใต้ข้อจำกัดจริง · ตัดสินใจจากหลายวัน/สัปดาห์ เหลือไม่กี่ชั่วโมง · ทุกคำแนะนำอ้างอิงข้อมูลและสมมติฐานที่ใช้
- •แผน: พัฒนา Optimization Model · สร้าง EPANET Surrogate Model · ส่งมอบ Dashboard ผู้บริหารและผู้ปฏิบัติการ
- •งบประมาณ: X — AI Platform หาทางเลือกแหล่งน้ำ เส้นทาง และแผนสูบจ่าย · เชื่อมต่อ EPANET ยืนยันแผนในมิติ Hydraulic
- •บุคลากร: วิศวกรแบบจำลอง / Data Scientist · ใช้ทีมเดียวกับ AQUIS เพื่อถ่ายทอดองค์ความรู้ต่อเนื่อง
อธิบายเต็ม + research: หน้า "M6 · AI Demand & Supply" ใน EWG (consult.angelora.net/ewg/m6-ai-optimization)
Open questions
- 1.งบประมาณทุกโมดูลในสไลด์ยังเป็น "X" — ตัวเลขจริงจะมาเมื่อไร และใครเป็นคนกรอก
- 2.M1 จำนวนสถานีไม่ตรงกันระหว่างสไลด์ 3 (สถานีสูบน้ำ 13 แห่ง + Head Tank / Sub Station 20 แห่ง) กับสไลด์ 4 (16 สถานีสูบน้ำ + 12 สถานีที่เกี่ยวข้อง) — ตัวไหนคือขอบเขตจริง
- 3.M4 AQUIS: Timeline วางไว้ Year 2 แต่สไลด์ 8 ระบุแผน 12 เดือน 5 ขั้นตอน และ M6 ใช้ EPANET "ระหว่างรอ AQUIS" — ยืนยันลำดับ M6 ก่อน M4
- 4.M5 Data Warehouse ในสไลด์นี้ (ออกแบบ Q4 2026–Q1 2027 แล้ว Implement Q2–Q3 2027) ต้องตรงกับหน้า Data Warehouse เดิมใน Consult (18 เดือน 2 ขั้นตอน)
- 5.สไลด์ 9 เขียน "รองรับการเทรน A" — น่าจะหมายถึง "AI"
- 6.M2: ทำ Coverage survey ตามแนวท่อหลักได้เมื่อไร — ต้องใช้ Gateway LoRaWAN กี่ตัว และเสา NB-IoT ครอบคลุมจุดวัดทั้ง 100 จุดหรือไม่
- 7.M2: OPEX 1.0 ลบ./ปี เป็นค่าซิมเท่าไร — ใช้เทียบ TCO 5 ปีของ 4G กับ LoRaWAN / NB-IoT
- 8.M2: ต้องจับแรงดันกระชาก (Transient) ด้วยหรือไม่ — ถ้าต้อง Logger ต้องบันทึกถี่ในตัวเครื่องไม่ว่าจะส่งข้อมูลทางไหน
Sources
- The Things Network — LoRaWAN frequency plans (AS923 และความต่างของแต่ละประเทศในเอเชีย)· accessed 14 ต.ค. 2026
- arXiv 2503.11162 — Reliable and Cost-Efficient IoT Connectivity: LPWAN, 5G and Hybrid (พลังงาน LoRaWAN vs NB-IoT vs 4G)· accessed 14 ต.ค. 2026
- IJET (2023) — เปรียบเทียบ Wireless M-Bus, LoRaWAN, Sigfox, NB-IoT สำหรับมิเตอร์น้ำใช้แบตเตอรี่· accessed 14 ต.ค. 2026
- Enlit — How do you choose the suitable communication technology for your smart water meters (มุมผู้ผลิตมิเตอร์)· accessed 14 ต.ค. 2026
- Jooby (2026) — NB-IoT vs LoRaWAN: which technology to choose for smart metering· accessed 14 ต.ค. 2026