โซลูชันนี้ประกอบด้วยThingy:91 โดย Nordic Semiconductor ที่มีเฟิร์มแวร์ที่กำหนดเองโดยอิงตามตัวอย่างnRF Connect SDK (ncs) อุปกรณ์นี้มีส่วนประกอบฮาร์ดแวร์ที่จำเป็นทั้งหมดอยู่แล้ว ดังนั้นจึงเป็นฮาร์ดแวร์สำเร็จรูปอย่างแท้จริง อุปกรณ์จะส่งข้อมูลความถี่สูงไปยังค ลาวด์ ThingsBoard ผ่าน CoAP และสตรีมข้อมูลความถี่ต่ำไปยังnRF Cloud ผ่าน MQTT

นี่เป็นโครงการ DIY เนื่องจากมีความเหมาะสมระหว่างทักษะที่มีอยู่ ฮาร์ดแวร์ที่มีอยู่ และสิ่งที่จำเป็นสำหรับงาน ส่วนวิธีอื่นๆ ในการบรรลุเป้าหมายเดียวกัน

เช่นเดียวกับโครงการใดๆ ก็ตาม เราต้องเริ่มต้นด้วยข้อกำหนดของโครงการ

ความต้องการ

ฉันกำลังมองหาการสร้างโซลูชั่นที่มีคุณสมบัติต่อไปนี้:

• อุปกรณ์ที่ประกอบด้วย:
  • เซ็นเซอร์ที่สามารถวัดการสั่นสะเทือน
  • โมเด็มเซลลูล่าร์
  • ราคาไม่แพง.
  • ใช้พลังงานจากแบตเตอรี่ (สามารถใช้งานได้หลายวันโดยไม่ต้องชาร์จ)
  • เป็นอิสระ
• สามารถเก็บผลการวัด (ตัวอย่าง) และอัพโหลดไปยังเซิร์ฟเวอร์ (คลาวด์) ได้
• การเก็บตัวอย่างมีความถี่ 1 ตัวอย่างทุก ๆ 1-20 วินาที
• ความหน่วงน้อยกว่า 10 นาที โดยควรน้อยกว่า 1 นาที
• อินเทอร์เฟซเว็บที่ผลลัพธ์สามารถดูเป็นกราฟได้เกือบเรียลไทม์
• แบ็คเอนด์ที่สามารถเก็บข้อมูลได้อย่างน้อยหนึ่งสัปดาห์
• ปริมาณงานน้อยที่สุด
• ปริมาณการนำกลับมาใช้ซ้ำสูงสุด (ซอฟต์แวร์ ฮาร์ดแวร์ ชิ้นส่วน ฯลฯ)
• ครั้งเดียว

กรณีการใช้งานจะเป็น:

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

การออกแบบทางเทคนิค

ตามความต้องการจะมีส่วนประกอบที่เชื่อมต่อกันหลายส่วน:

• อุปกรณ์ทางกายภาพ
• โปรโตคอลการสื่อสาร
• เซิร์ฟเวอร์แบ็คเอนด์
• ยูไอ

อุปกรณ์

สำหรับอุปกรณ์นี้ ฉันเลือก Thingy:91 ซึ่งเป็นแพลตฟอร์มการสร้างต้นแบบสำหรับNordic nRF9160 SiP (ระบบในแพ็คเกจ) nRF91 เป็นไมโครโปรเซสเซอร์ที่มีโมเด็มเซลลูลาร์ที่ออกแบบมาสำหรับแอพพลิเคชั่นพลังงานต่ำและ IoT Thingy เพิ่มเซ็นเซอร์ แบตเตอรี่ และกล่องใส่ให้กับ nRF91 เพื่อสร้างอุปกรณ์ที่มีความสามารถซึ่งสามารถตั้งโปรแกรมให้ทำสิ่งต่างๆ ได้มากมาย ทั้งนี้ ควรกล่าวถึงว่ายังมีอุปกรณ์อื่นๆ ในกลุ่ม Thingy เช่น Thingy:52 และ Thingy:53 ซึ่งเน้นที่ Bluetooth, Zigbee และ Matter ทุกครั้งที่กล่าวถึง Thingy ในบทความนี้ ฉันหมายถึง Thingy:91 เซลลูลาร์

ฉันเลือก Thingy เพราะมีชิ้นส่วนที่จำเป็นสำหรับโครงการนี้ครบถ้วนแล้ว และฉันไม่จำเป็นต้องเชื่อมต่อโมดูลแยกกันหรือบัดกรีอะไรเลย Thingy มีเครื่องวัดความเร่งสองตัว คือ ADXL362 และ ADXL372 แต่ 372 เป็นเครื่องวัดแรงกระแทกสูง ฉันจึงใช้เครื่องวัด 362 ซึ่งมีความไวต่อแรงกระแทกมากกว่า Thingy ยังมีกล่องหุ้ม แบตเตอรี่ ไฟ LED และตัวอย่างโค้ดโอเพนซอร์สมากมาย Thingy มีราคาประมาณ 120 เหรียญ แต่ฉันมีเครื่องนี้จากโครงการอื่นที่ทำให้ตัดสินใจได้ง่ายขึ้น หากคุณยังไม่มี Thingy นี่อาจเป็นการลงทุนที่ดี เนื่องจากเป็นอุปกรณ์เอนกประสงค์ คุณจึงใช้เป็นเซ็นเซอร์วัดการสั่นสะเทือนได้ในวันนี้ และเป็นอย่างอื่นในวันพรุ่งนี้ได้

โปรโตคอลการสื่อสาร

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

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

โปรโตคอลที่ฉันพิจารณาคือ:

• เอ็มคิวทีที
• MQTT-SN‍
• CoAP
• เอชทีพี

โดยที่เพย์โหลดจะเป็น JSON, Protobuf หรือการเข้ารหัสไบนารีแบบกำหนดเอง

เนื่องจากข้อมูลหลักเป็นชุดข้อมูลแบบต่อเนื่องและไม่ใช่สตรีมข้อมูลที่ส่งคำสั่งหรือเหตุการณ์ ฉันจึงตัดสินใจว่าไม่จำเป็นต้องมีการส่งข้อมูลที่เชื่อถือได้ นอกจากนี้ ฉันยังตัดสินใจไม่ต้องการการเข้ารหัสด้วยเหตุผลเดียวกัน นอกจากนี้ ยังเป็นวิธีการแบบ DIY ไม่ใช่ผลิตภัณฑ์เชิงพาณิชย์ ทั้งหมดนี้ช่วยลดค่าใช้จ่ายและเราสามารถละเลย HTTPS, MQTT แทน TLS และ CoAP แทน DTLS ซึ่งเราจะต้องใช้ในกรณีอื่น

แบนด์วิธ

หากเรารายงานตัวอย่างหนึ่งทุกๆ 10 วินาที หลังจากหนึ่งเดือนจะได้ตัวอย่าง 260,000 ตัวอย่าง โอเวอร์เฮดของแต่ละตัวอย่างสร้างความแตกต่างอย่างมากในกรณีนี้ หากตัวอย่างหนึ่งต้องการ 50 ไบต์ ก็จะรวมเป็น 13MB/เดือน อย่างไรก็ตาม หากตัวอย่างหนึ่งต้องการ 1,000 ไบต์ ก็จะรวมเป็น 260MB/เดือน ซึ่งอาจมีต้นทุนที่สำคัญ ขึ้นอยู่กับแผนข้อมูลของคุณ การส่งไบต์มากขึ้นยังทำให้แบตเตอรี่มีอายุใช้งานสั้นลงและทำให้ใช้งานในพื้นที่ที่มีสัญญาณต่ำได้ยากขึ้น

การแบ่งแบตช์และความหน่วงเวลา

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

แบ็คเอนด์และ UI

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

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

ฉันได้พิจารณาแนวทางแก้ปัญหาต่อไปนี้:

• AWS – บริการที่ให้มาอยู่ในระดับต่ำเกินไปสำหรับโปรเจ็กต์นี้ แต่ถือเป็นโซลูชันที่ดีสำหรับผลิตภัณฑ์เชิงพาณิชย์ที่จำเป็นต้องมีการปรับแต่งในระดับสูง
• InfluxDB + Grafana – โปรโตคอลเฉพาะ โปรโตคอลที่ซับซ้อน และอิงตามการเชื่อมต่อ
• Home Assistant – จำเป็นต้องพัฒนาอะแดปเตอร์/ตัวนำเข้าบางประเภทเพื่อส่งต่อข้อมูลจากอินเทอร์เน็ตไปยังเครือข่ายท้องถิ่น เนื่องจากนี่คืออินสแตนซ์ท้องถิ่น
• ThingsBoard – ด้านหลังและด้านหน้าในหนึ่งเดียว, แดชบอร์ดที่ดี, รองรับ CoAP, ฟังก์ชันการสาธิตที่เหมาะสม
• nRF Cloud – ตัวอย่างพร้อมใช้งานจำนวนมาก กราฟมีจำกัด เน้นที่ตำแหน่งและ FOTA แผนฟรีมีจำกัดมาก

ฉันเลือก ThingsBoard สำหรับการสตรีมข้อมูลหลัก (ความถี่สูง) เนื่องจากสามารถใช้ CoAP แบบไม่ต้องเชื่อมต่อและเนื่องจากมี UI ที่ปรับแต่งได้ดี โปรดส่งข้อความส่วนตัวหากคุณต้องการแนะนำบริการอื่นๆ สำหรับจุดประสงค์นี้

ตัวอย่างแผงควบคุม ThingsBoard

ผลข้างเคียงที่เราจะอธิบายในหัวข้อถัดไปคือ โซลูชันยังรายงานข้อมูลความถี่ต่ำ (ประมาณทุกๆ 15 นาที) ไปยัง nRF Cloud นอกจากข้อมูลการสั่นสะเทือนแล้ว การรวบรวมสถานะแบตเตอรี่ ตำแหน่งอุปกรณ์ และพารามิเตอร์อื่นๆ ที่ไม่เปลี่ยนแปลงมากนักยังมีประโยชน์อีกด้วย การรวม nRF Cloud จะส่งผ่านช่อง MQTT ที่ปลอดภัย และ (ทางเลือก) อนุญาตให้ส่งคำสั่ง "AT" ของโมเด็มจากเซิร์ฟเวอร์ไปยังอุปกรณ์

การนำไปปฏิบัติ

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

เฟิร์มแวร์

เฟิร์มแวร์สำหรับ nRF91 ซึ่งเป็นแกนหลักของ Thingy ได้รับการพัฒนาโดยใช้ “ nRF Connect SDK ” ซึ่งเป็นชุดพัฒนาซอฟต์แวร์จาก Nordic Semiconductor NCS มีพื้นฐานมาจากZephyr ซึ่งเป็นระบบปฏิบัติการโอเพ่นซอร์สแบบเรียลไทม์ (RTOS) การสืบทอดฟังก์ชัน nRF Cloud จากซอร์สโค้ดพื้นฐานทำให้ฉันสามารถพัฒนาส่วนการตรวจจับแยกจากส่วนการสื่อสารได้ ในตอนแรก ฉันเพิ่มการรองรับการสุ่มตัวอย่างเซ็นเซอร์และการคำนวณเมตริกการสั่นสะเทือน เมตริกการสั่นสะเทือนเป็นเพียงผลรวมของความแตกต่างในแกน 3 แกนของค่ามาตรความเร่งระหว่างตัวอย่างที่ต่อเนื่องกันสองตัวอย่าง เมื่อคำนวณค่าดังกล่าวแล้ว ฉันสามารถอัปโหลดไปยัง nRF Cloud เพื่อยืนยันว่าใช้งานได้และเพื่อให้มี POC ขนาดเล็ก เมื่อทำเสร็จแล้ว ฉันจึงเพิ่มการรองรับสำหรับการส่งเมตริกในความถี่ที่สูงขึ้นไปยังเซิร์ฟเวอร์ ThingsBoard โดยใช้โปรโตคอล CoAP ซอร์สโค้ดสำหรับโครงการมีอยู่ในgithub

การบูรณาการเซ็นเซอร์

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

1. เปิดใช้งานและกำหนดค่าส่วนประกอบในKconfig Kconfig กำหนดตัวเลือกการกำหนดค่าสำหรับไดรเวอร์ เช่น ช่วง อัตราการสุ่มตัวอย่าง เป็นต้น ในโปรเจ็กต์ของเรา จะดำเนินการใน ไฟล์ conf เฉพาะ ของThingy
2. กำหนดส่วนประกอบใน devicetree devicetree จะกำหนดไดรเวอร์ประเภทการเชื่อมต่อทางกายภาพ พิน ฯลฯ ในโปรเจ็กต์ของเรา ส่วนประกอบนี้ถูกกำหนดไว้แล้วในไฟล์ DTS ของ Thingy สำหรับบอร์ดที่กำหนดเอง คุณจะต้องกำหนดส่วนประกอบนี้ใน DTS ที่กำหนดเองของคุณเอง
3. การเรียกใช้ฟังก์ชัน sensor_* จาก Sensors API ซึ่งคุณจะมีฟังก์ชันนี้ในโค้ด c ของโปรเจ็กต์ของคุณ หรือในกรณีของเราในvibration.c

แบบจำลองนี้อาจดูแปลกสำหรับคนที่เคยชินกับแบบจำลองที่เรียบง่ายและ "แบนราบ" กว่า เช่น แบบจำลองที่คุณมีในกรอบงาน Arduino ซึ่งทุกอย่างเป็นเพียงโค้ด แบบจำลอง Zephyr มีความซับซ้อนมากกว่าและทำให้ง่ายต่อการเปลี่ยนไปใช้แบบจำลอง IC เซ็นเซอร์อื่นหรือบอร์ดอื่นโดยไม่ต้องเปลี่ยนแปลงโค้ดหรือแยกสาขาในโค้ด ต้นทุนหลักของการแยกส่วนนี้คือเส้นโค้งการเรียนรู้ที่สูงชันกว่า แต่ก็มีข้อดีมากมาย โดยเฉพาะอย่างยิ่งสำหรับโปรเจ็กต์ขนาดใหญ่

การบูรณาการ CoAP

สำหรับ CoAP มี API ให้เลือกใช้งาน 2 ตัว ได้แก่CoAP API ระดับล่างที่เป็นส่วนหนึ่งของ Zephyr และCoAP utils API ระดับสูงกว่าที่ Nordic เพิ่มเข้ามาและเป็นส่วนหนึ่งของ nRF Connect SDK API ระดับสูงกว่ามีฟังก์ชันการทำงานที่จำเป็นสำหรับโปรเจ็กต์นี้และจะช่วยประหยัดเวลาทำงานของเราได้ ฉันได้นำโค้ด c มาใช้เพื่อส่งข้อมูลไปยัง ThingsBoard โดยใช้ CoAP utils API ฉันใช้ คำจำกัดความจุดสิ้นสุด การอัปโหลด CoAP สำหรับการส่งข้อมูลทางไกลของ ThingsBoard เพื่อดูรายละเอียดเกี่ยวกับวิธีจัดรูปแบบ uri และเพย์โหลด

การเชื่อมโยงทุกสิ่งเข้าด้วยกัน

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

ผลลัพธ์

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

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

ผลข้างเคียงของการใช้ตัวอย่าง nRF Cloud คือเราสามารถมีข้อมูลตำแหน่งและอุณหภูมิที่เป็นทางเลือกได้

แบตเตอรี่ขนาด 1,400 mAh สามารถใช้งานได้นานกว่า 2 วัน โดยส่งตัวอย่างการสั่นสะเทือนทุกๆ 20 วินาที แบตเตอรี่สามารถชาร์จจนเต็มได้ภายใน 3 ชั่วโมงจากแหล่งจ่ายไฟ USB โดยแต่ละแพ็กเก็ตจะมีขนาดประมาณ 60-70 ไบต์ UDP ไม่จำเป็นต้องเชื่อมต่อใดๆ

สรุป

ฉันได้อธิบายขั้นตอนการสร้างอุปกรณ์ IoT แบบเซลลูลาร์ DIY โดยเริ่มต้นด้วยชุดข้อกำหนดและสร้างโซลูชันที่ปรับแต่งให้เหมาะกับข้อกำหนดเหล่านั้น ซึ่งส่วนใหญ่ประกอบด้วยส่วนประกอบสำเร็จรูป ส่วนประกอบบางส่วนเป็นฮาร์ดแวร์ บางส่วนเป็นเฟิร์มแวร์ บางส่วนเป็นบริการออนไลน์ แต่เมื่อนำมารวมกันก็ทำให้สามารถพัฒนาโซลูชันต้นทุนต่ำได้ ต้นทุนเพียงอย่างเดียวในโครงการนี้คือเวลา และฉันประมาณว่าฉันใช้เวลา 10-20 ชั่วโมงในการค้นคว้าและนำตัวเลือกต่างๆ ไปใช้ เนื่องจากฉันเผยแพร่โครงการเป็นโอเพ่นซอร์ส ครั้งหน้าหากใครก็ตามจะลองทำอะไรที่คล้ายกัน อุปสรรคจะยิ่งน้อยลงไปอีก

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

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

‍