วิธีใช้งาน Home Assistant ในปี 2025

 (vpetersson.com)
2 คะแนน โดย GN⁺ 2025-01-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ประสบการณ์ใช้งาน Home Assistant ตลอด 7 ปีได้ขยายจากระบบอัตโนมัติขนาดเล็กที่เน้น Raspberry Pi และ SQLite ไปสู่การตั้งค่าที่มีอุปกรณ์มากกว่า 100 รายการบน VM ของโฮมเซิร์ฟเวอร์, MySQL และ InfluxDB
  • ในบ้านหลังใหม่ จำนวนห้องและไฟเพิ่มขึ้น ทำให้หลอดไฟแทบทั้งหมดเชื่อมต่อกับ Home Assistant และไฟอัจฉริยะทั้งหมดใช้ผลิตภัณฑ์ของ IKEA เป็นมาตรฐานเดียวกัน
  • ระบบอัตโนมัติของไฟย้ายจาก Flux ไปเป็น Adaptive Lighting ของ HACS เพื่อควบคุมอุณหภูมิสีและความสว่างตามช่วงเวลาได้ละเอียดขึ้น แต่ยังมีภาระในการตั้งค่าที่ต้องระบุ light entity แต่ละตัวโดยตรง
  • Cursor ช่วยสร้าง พาร์เซอร์แบบกำหนดเอง สำหรับวิเคราะห์ความสามารถของไฟจาก Home Assistant API และช่วยสร้าง YAML ทำให้ลดงานตั้งค่าซ้ำ ๆ และเวลาที่ใช้ดีบัก
  • ขั้นต่อไปคือการติดตั้ง smart TRV ที่ใช้ Zigbee กับหม้อน้ำ และใช้ข้อมูลอุณหภูมิจาก Nest เพื่อควบคุมการทำความร้อนรายห้องผ่าน Home Assistant

ขยายจากระบบอัตโนมัติในอพาร์ตเมนต์เล็ก ๆ ไปสู่ VM บนโฮมเซิร์ฟเวอร์

  • การใช้งาน Home Assistant เริ่มต้นในอพาร์ตเมนต์เล็ก ๆ ในระดับที่รวมไฟเข้ากับ IKEA Smart Hub
  • หลังคุ้นเคยกับระบบอัตโนมัติแล้ว ก็เริ่มสร้าง ฮาร์ดแวร์แบบกำหนดเอง เช่น เซ็นเซอร์อุณหภูมิและความชื้นเองด้วย
  • เมื่ออุปกรณ์และระบบอัตโนมัติเพิ่มขึ้น การรันบน Raspberry Pi ก็เริ่มใกล้ถึงขีดจำกัด
    • SQLite ซึ่งเป็นฐานข้อมูลเริ่มต้นกลายเป็นคอขวดเมื่อประมวลผลข้อมูลเซ็นเซอร์จำนวนมาก
    • ไม่ได้ประเมินฮาร์ดแวร์เฉพาะสำหรับ Home Assistant เพราะไม่เคยใช้งาน
  • การตั้งค่าปัจจุบันย้ายไปเป็น VM บนโฮมเซิร์ฟเวอร์
    • ฐานข้อมูลหลักของ Home Assistant ถูกย้ายไปใช้ MySQL
    • มีเซิร์ฟเวอร์ InfluxDB แยกต่างหากสำหรับเมตริกระยะยาวและข้อมูลย้อนหลัง
    • การตั้งค่าโฮมเซิร์ฟเวอร์สรุปไว้ใน บทความแยก

ขยายเป็นอุปกรณ์มากกว่า 100 รายการในบ้านหลังใหม่

  • หลังย้ายเข้าบ้าน จำนวนห้อง ไฟ และจำนวนอุปกรณ์ทั้งหมดเพิ่มขึ้นอย่างมาก
  • ปัจจุบันมีอุปกรณ์ มากกว่า 100 รายการ เชื่อมต่อกับ Home Assistant
  • ไฟอัจฉริยะทั้งหมดเป็นผลิตภัณฑ์ของ IKEA และหลอดไฟแทบทุกดวงในบ้านถูกรวมเข้ากับ Home Assistant แล้ว

เปลี่ยนจาก Flux ไปเป็น Adaptive Lighting

  • ฟังก์ชันหลักของระบบอัตโนมัติด้านไฟคือ Adaptive Lighting
  • ก่อนหน้านี้ใช้ Flux ซึ่งเป็นวิธีแบบเก่าสำหรับซิงก์ไฟให้เข้ากับช่วงเวลา
  • ปัจจุบันย้ายมาใช้การผสานรวม Adaptive Lighting ที่ให้บริการผ่าน HACS(Home Assistant Community Store)
  • การผสานรวมใหม่นี้ควบคุมอุณหภูมิสีและความสว่างตลอดวันได้ละเอียดกว่า
  • จุดที่ยุ่งยากที่สุดในการตั้งค่าคือทั้ง Flux และ Adaptive Lighting ไม่สามารถกำหนดเป้าหมายเป็น light group ได้
    • แม้จะมีไฟหลายสิบดวงที่ต้องการจัดการร่วมกัน ก็ต้องระบุ light entity แต่ละตัวในไฟล์ตั้งค่า
    • หากกำหนดกลุ่มเดียวแล้วให้ระบบจัดการไฟภายในกลุ่มโดยอัตโนมัติได้ น่าจะสะดวกกว่า
  • แม้หลอดไฟทั้งหมดจะเป็นผลิตภัณฑ์ของ IKEA แต่ความสามารถที่รองรับก็แตกต่างกัน
    • เพื่อให้ Adaptive Lighting ทำงานได้ถูกต้อง จำเป็นต้องตั้งค่าแยกตามหมวดหมู่ของหลอดไฟ
  • เป้าหมายคือ การสลับอุณหภูมิสีอัตโนมัติ ที่ค่อย ๆ เปลี่ยนเป็นสีเหลืองอุ่นในตอนเช้าและตอนเย็น และเป็นสีขาวที่เย็นกว่า/โทนฟ้ามากขึ้นในช่วงกลางวัน

ลดงานตั้งค่า YAML ด้วย Cursor

  • การเปลี่ยนแปลงครั้งใหญ่ในปีนี้คือการใช้ Cursor เพื่อจัดการงานซ้ำ ๆ และยุ่งยากในไฟล์ตั้งค่า YAML ของ Home Assistant
  • เนื่องจากไม่มีเวลาพอจะเรียนรู้ DSL และรายละเอียดไฟล์ตั้งค่าของ Home Assistant ทั้งหมด จึงใช้ เครื่องมือช่วยเขียนโค้ดด้วย AI กับงานตั้งค่า
  • สิ่งแรกที่สร้างขึ้นคือ สคริปต์แบบกำหนดเอง ที่พาร์เซไฟทั้งหมด วิเคราะห์ชนิดหลอดไฟและความสามารถ และแสดงข้อมูลสำหรับดีบัก
  • สคริปต์นี้เชื่อมต่อกับ Home Assistant API และจัดประเภทไฟตามความสามารถ
    • รวบรวม entity ที่ขึ้นต้นด้วย light.
    • ตรวจสอบสถานะปัจจุบัน ความสว่าง อุณหภูมิสี โหมดสีที่รองรับ และความสามารถที่รองรับ
    • แสดงคำเตือนเมื่อการตั้งค่า Adaptive Lighting ไม่ตรงกับความสามารถของไฟ
    • แสดงความสว่างต่ำสุด สูงสุด และเฉลี่ยของไฟที่เปิดอยู่ รวมถึงรายการตามประเภทไฟ
  • เวิร์กโฟลว์สรุปได้เป็นสามขั้นตอน
    • รันพาร์เซอร์แบบกำหนดเองในสภาพแวดล้อม Home Assistant เพื่อสร้างรายการหลอดไฟและความสามารถ
    • ป้อนผลลัพธ์และการตั้งค่าเดิมเข้าไปใน agent mode ของ Cursor หรือโหมดที่คล้ายกัน
    • ให้ Cursor สร้าง YAML สำหรับระบบ Adaptive Lighting ใหม่
  • หากเกิดปัญหา ก็ช่วยดีบักด้วยการใส่ log ของ Home Assistant เข้าไปใน Cursor แล้วขอให้แก้ข้อผิดพลาด

การตั้งค่า Adaptive Lighting แยกตามหลอดไฟ IKEA

  • หลังจากทดสอบอย่างกว้างขวาง ได้ปรับแต่งการตั้งค่า Adaptive Lighting ให้เหมาะกับหลอดไฟ IKEA แต่ละประเภท

  • Dimmable white spectrum

    • เป้าหมายคือหลอดไฟ LED bulb GU10 345 lumen, smart/wireless dimmable white spectrum
    • ตัวอย่างการตั้งค่าใช้ min_brightness: 50, max_brightness: 100, min_color_temp: 2202, max_color_temp: 4000
    • รวมถึง sleep_brightness: 1, sleep_color_temp: 2202, transition: 45, interval: 90, initial_transition: 1, prefer_rgb_color: false

  • Dimmable color and white spectrum

    • เป้าหมายคือหลอดไฟ LED bulb E27 806 lumen, wireless dimmable color and white spectrum/globe opal white
    • ตัวอย่างการตั้งค่าใช้ min_brightness: 70, max_brightness: 100, min_color_temp: 2000, max_color_temp: 6535
    • รวมถึง sleep_brightness: 1, sleep_color_temp: 2000, transition: 45, interval: 90, initial_transition: 1, prefer_rgb_color: false

  • Dimmable warm white

    • เป้าหมายคือหลอดไฟรุ่นพื้นฐาน LED bulb GU10 345 lumen, smart/wireless dimmable warm white
    • ใช้การตั้งค่าที่เน้นความสว่างโดยไม่มีการตั้งค่าอุณหภูมิสี ได้แก่ min_brightness: 50, max_brightness: 100, sleep_brightness: 1
    • รวมถึง transition: 45, interval: 90, initial_transition: 1

ขั้นต่อไป: smart TRV แบบ Zigbee

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-26
ความคิดเห็นจาก Hacker News

  • เป็นผู้ก่อตั้ง Home Assistant เอง ถ้ามีอะไรสงสัยเกี่ยวกับโปรเจกต์หรือ Open Home Foundation ก็ถามมาได้
    ตอนนี้ Open Home Foundation เป็นเจ้าของ Home Assistant, ESPHome และอื่น ๆ

    • ใช้ Home Assistant มานานกว่า 10 ปีแล้ว และสงสัยว่าเคยพิจารณาเปลี่ยน กติกาการออกรีลีส บ้างไหม
      การออกรายเดือนก็ดี แต่ถ้ามีการเปลี่ยนแปลงที่ทำให้พังทุกครั้ง ภาระก็สูงมาก ถ้าจำกัดการเปลี่ยนแปลงแบบนี้ไว้ปีละครั้งหรือสองครั้ง ผู้ใช้น่าจะตามได้ง่ายกว่า
      พยายามอ่านรายการการเปลี่ยนแปลงที่ทำให้พังทุกครั้ง แต่บางทีก็ไม่ได้แตะ HA อยู่หลายเดือน พอกลับมาเข้าอีกทีก็มีรายการที่ต้องทบทวนสะสมเยอะ ทำให้ยิ่งเลื่อนการอัปเกรดออกไปและปัญหาก็ยิ่งใหญ่ขึ้น ถ้ามีการอัปเกรดที่ชัดเจนว่าไม่มี breaking changes ก็น่าจะช่วยให้ตามเวอร์ชันล่าสุดได้ง่ายขึ้น
    • มองว่า Home Assistant เป็นตัวอย่างที่ยอดเยี่ยมของการได้ อำนาจควบคุมอุปกรณ์อิเล็กทรอนิกส์ กลับมาอยู่ในมือเราเอง แทนที่จะต้องจ่ายเงินให้บริษัทเก็บข้อมูล
      บริษัทเก็บข้อมูลยักษ์ใหญ่เหล่านั้นคงไม่ชอบเทคโนโลยีนี้นัก เลยอยากรู้ว่าในความเป็นจริงเคยเจอแรงกดดันอย่างคำสั่งให้ยุติหรือกรณีที่ต้องตั้งรับมากแค่ไหน
    • การจัดระเบียบอุปกรณ์และสร้างระบบอัตโนมัติยังค่อนข้างยุ่งยากอยู่
      ถ้าเพิ่มอุปกรณ์ใหม่แล้วอธิบายตำแหน่งกับบทบาทของมันให้ HA ฟัง จากนั้น HA สามารถรวมมันเข้าไปในระบบอัตโนมัติเดิมโดยอัตโนมัติ หรือจับคู่กับเซนเซอร์อื่น ๆ ได้ก็คงดี น่าจะใช้ LLM กับเรื่องนี้ได้เหมือนกัน
      ตัวอย่างเช่น ถ้าบอกว่าเพิ่งติดตั้งเซนเซอร์ตรวจน้ำรั่วใหม่ในห้องซักล้าง ก็น่าจะสร้างระบบอัตโนมัติแจ้งเตือนเมื่อน้ำรั่วให้เลย หรือถ้าเพิ่มเซนเซอร์อุณหภูมิในห้องนั่งเล่น ก็น่าจะรวมกับเซนเซอร์ตัวอื่นเพื่ออัปเดตอุณหภูมิเฉลี่ยของห้องนั่งเล่นให้ได้
    • อยากรู้ว่าใช้ หลอดไฟอัจฉริยะ ยี่ห้อไหน
    • อยากรู้ว่ามีแผนทำระบบอัตโนมัติที่อิงกับคนและ Areas ไหม หมายถึง Areas ไม่ใช่ zones
      มีโปรเจกต์ชื่อ Bermuda[0] ที่สร้าง event เมื่อคนเข้าออกแต่ละพื้นที่โดยอิงจากอุปกรณ์ Bluetooth ซึ่งจากการทดสอบกับโทรศัพท์มือถือที่ติดตามด้วยสวิตช์ Shelly มันทำงานได้ดีทีเดียว แต่ยังหาวิธีใช้ event นั้นให้เกิดการทำงานจริง ๆ ได้ยาก
      ถ้าสามารถพูดได้ว่า “หลังพระอาทิตย์ตก ถ้ามีใครเข้ามา ให้เปิดไฟของพื้นที่นั้นที่ 20%” โดยไม่ต้องสร้างระบบอัตโนมัติแยกตามแต่ละพื้นที่ก็น่าจะดีกว่า
      [0] https://github.com/agittins/bermuda

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

    • สงสัยว่าเซนเซอร์ตรวจการเคลื่อนไหวเพิ่ม คุณค่าในทางปฏิบัติ มากน้อยแค่ไหนเมื่อเทียบกับเซนเซอร์ตรวจการเคลื่อนไหวแบบสแตนด์อโลนหรือเซนเซอร์ความชื้น
      รู้สึกว่าแค่มีเซนเซอร์ตรวจการเคลื่อนไหวแบบเรียบง่ายแยกเดี่ยว ก็น่าจะทำสมาร์ตโฮมได้ไปมากพอสมควรแล้ว โดยมีต้นทุนต่ำกว่าและไม่ต้องพึ่ง Wi‑Fi
    • จริง ๆ แล้วยุงไม่ได้ถูกดึงดูดด้วยแสง แต่แมลงชนิดอื่นต่างหากที่ถูกดึงดูดด้วยแสง เท่าที่รู้ยุงถูกดึงดูดด้วย CO2, ลมหายใจ เลือด และเหงื่อ

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

    • ใช้ Home Assistant มาตั้งแต่ก่อนมี Lovelace UI และมันพัฒนาไปมาก แต่ก็ยังต้องมี การดูแลต่อเนื่อง อยู่ ถึงจะน้อยลงกว่าเดิมมาก แต่ก็ไม่ใช่ศูนย์
      มองว่าเป้าหมายที่แท้จริงของ HA และระบบนิเวศของมันคือการผลักดันแพลตฟอร์มการจัดการแบบเปิด คล้ายกับที่ Matter ผลักดันการยอมรับ IPv6 ฝั่งไมโครคอนโทรลเลอร์
      ทุกปลายปีจะซื้ออุปกรณ์ราคาถูกจาก AliExpress มารื้อดู และในปี 2024 ก็เป็นครั้งแรกที่เห็นผู้ผลิตแทบจะอวดกันเลยว่ามีป้ายกำกับขา GPIO และเปิดเผยอินเทอร์เฟซสำหรับโปรแกรมไว้ให้ ถ้าอยากก็แฟลชเฟิร์มแวร์เองได้ และยังโฆษณาด้วยว่ารองรับ WLED โดยตรง นับว่าเป็นเรื่องใหม่ที่ผู้ผลิตเริ่มปรับตัวเข้าหาขบวนการซอฟต์แวร์เสรี โอเพนซอร์ส DIY และแนวคิด “ไม่ใช้คลาวด์ของคุณ เพราะในบ้านฉันมีคลาวด์ของตัวเอง” จริง ๆ
    • ตั้งแต่เริ่มใช้ HA เมื่อราว 10 ปีก่อน กฎข้อแรกของระบบอัตโนมัติในบ้านคือ ออฟไลน์
      ตอนนี้มีอุปกรณ์เชื่อมต่ออยู่หลายร้อยชิ้นแล้ว แต่คลาวด์อินทิเกรชันที่ใช้อยู่มีแค่ Spotify ด้วยเหตุผลที่ชัดเจน เวลาซื้ออุปกรณ์อัจฉริยะก็จะดูให้ดีว่าออฟไลน์ได้เต็มรูปแบบไหม และถ้าฉลาดแต่ไม่ได้ออกแบบมาให้ใช้ออฟไลน์อย่างเดียว ก็จะจำกัดมันให้เป็นแค่เครื่องใช้ไฟฟ้า “ธรรมดา”
      เช่น เครื่องล้างจานเครื่องใหม่มีฟังก์ชันอัจฉริยะเมื่อเชื่อมต่อ Wi‑Fi แต่ก็เข้าเมนูซ่อมบำรุงแล้วปิดอินเทอร์เฟซเครือข่ายทิ้งไปเลย ตอนนี้ก็ใช้มันเป็นแค่เครื่องล้างจานธรรมดา ซึ่งชอบแบบนั้น
    • แก้ปัญหาโดยเอาเอนทิตี HA ส่วนใหญ่ไปเปิดให้ HomeKit เห็นผ่าน HomeKit Bridge ที่มีมาในตัว
      ทำให้มันรวมกับ Siri ได้อย่างเป็นธรรมชาติ คนที่ไม่ใช่สายเทคนิคก็เลยควบคุมได้ง่าย และขณะเดียวกันก็ยังใช้ระบบอัตโนมัติที่ทรงพลังมากขึ้นได้
      ตัวอย่างเช่น ฟังก์ชันตรวจจับว่าอยู่บ้านไหมนั้น จริง ๆ แล้วทำงานด้วยระบบอัตโนมัติของ HomeKit ที่คอยกลับค่าของไบนารีเซนเซอร์ที่ HA เปิดให้เห็น

  • หลักการสำคัญที่สุดคือให้ "ความฉลาด" เป็นเพียงฟังก์ชันเสริม และไม่เปลี่ยนวิธีปกติที่ใช้โต้ตอบกับบ้าน
    เพื่อไม่ให้คู่สมรสยอมรับได้ยาก และไม่ทำให้แขก โดยเฉพาะผู้สูงอายุอย่างพ่อแม่ สับสน
    พูดให้ชัดคือ สวิตช์ไฟต้องทำงานตามที่คาดไว้, ต้องปรับอุณหภูมิจาก TRV ได้ และถึงแม้ HA instance จะล่ม ฟังก์ชันพื้นฐานก็ต้องยังใช้งานต่อได้
    เพราะอย่างนั้นในบางห้องจึงติดเซ็นเซอร์ตรวจจับการเคลื่อนไหวไว้ เพื่อให้หลังเที่ยงคืนเปิดไฟหลักหรือโคมไฟเล็กได้ แต่สวิตช์ไฟก็ยังคงมีหน้าที่เปิดและปิดไฟหลักเสมอ หากไม่มีการเคลื่อนไหวนาน X นาที ไฟทั้งหมดจะดับ
    ถ้าแม่รู้สึกหนาวในตอนเย็น ก็แค่หมุนปุ่มเหมือนที่ทำมาตลอดชีวิต ไม่ต้องมีแอป, ไม่ต้องมีปุ่มสัมผัสบน TRV, ไม่ต้องพูดว่า “hey Google… เอ๊ะ sori? Siri? ลูกมาช่วยหน่อย!” ความฉลาดอยู่ที่ตารางเวลารวม และเซ็นเซอร์ตรวจจับการเคลื่อนไหวที่จะพา TRV กลับไปใช้ตารางเดิมเมื่อไม่มีการเคลื่อนไหวเป็นเวลา 15 นาทีหลังจากปรับด้วยมือ
    ดังนั้นจึงใส่รีเลย์ไว้ในสวิตช์ไฟแทนหลอดไฟอัจฉริยะ และไม่ได้ใช้แบบแยกโหมด ส่วน TRV มีปุ่มหมุนอยู่แล้ว วิธีนี้จึงทำได้ตามธรรมชาติ

    • ส่วนตัวฉันมองว่าเทอร์โมสตัท DIY ที่ไม่มีปุ่มเปลี่ยนอุณหภูมิเป็น ฟีเจอร์ แต่ความรู้สึกว่าใครควรจะปรับเทอร์โมสตัทได้บ้างนั้นต่างกันไปในแต่ละคน จึงดีที่มีตัวเลือก
    • หลอดไฟอัจฉริยะดี ๆ จำนวนมากมีตัวเลือกให้ ทำงานเหมือนหลอดไฟธรรมดา เมื่อใช้กับสวิตช์ไฟปกติ
      บางรุ่นเมื่อไฟกลับมาจะคืนสู่สถานะล่าสุด บางรุ่นจะเปิดในสถานะไฟปกติพื้นฐาน และเพราะสามารถเปลี่ยนตัวเลือกเหล่านี้รวมถึงการตั้งค่าให้คงสถานะปิดไว้เมื่อไฟกลับมาได้ง่าย จึงยังยอมซื้อหลอดไฟอัจฉริยะที่แพงกว่าอยู่ เช่น เพื่อหลีกเลี่ยงไม่ให้ไฟห้องนอน “วาบ” ติดขึ้นมากลางดึกหลังไฟดับแล้วปลุกคนตื่น
      ต่อให้ตัวหลอดไม่รองรับดีนัก หากฮับตรวจจับได้ว่าไฟหายจากเครือข่ายแล้วกลับมา ก็ยังพอจำลองสถานะตั้งต้นที่มีประโยชน์ด้วยซอฟต์แวร์ได้ระดับหนึ่ง
    • TRV คือ Thermostatic Radiator Valve หรือ วาล์วหม้อน้ำควบคุมอุณหภูมิ

  • ตอนนี้กำลังลดระดับการทำอัตโนมัติในบ้านลงจากประมาณนี้
    มากสุดก็คิดไว้แค่สมาร์ตพาเนลสำหรับเปิด ปิด และหรี่ไฟของหลอด LED ธรรมดาที่ไม่ใช่สมาร์ตในพื้นที่อยู่อาศัยหลักทั้งหมด
    ตอนนี้มีหลอด GU10 LIFX อยู่ 14 ดวงซึ่งตอนนั้นราคาแพงและเดี๋ยวนี้หาซื้อยากแล้ว หลังจากตั้งค่า Wi‑Fi เปลี่ยนไป มันก็ใช้งานแบบเปิดปิดด้วยสวิตช์ผนังได้ไม่ดีอีกต่อไป เพราะขี้เกียจรีเซ็ตหลอดด้วยมือ ถอดออก แล้วค่อย ๆ ลงทะเบียนเข้า Wi‑Fi ใหม่อย่างช้า ๆ และทรมาน จริง ๆ ถ้าใช้ SSID ที่ไม่เปลี่ยนสำหรับโครงสร้างพื้นฐานนี้ตั้งแต่แรกก็คงพอได้ จึงเป็นความทรมานที่สร้างขึ้นเองไม่น้อย
    ระหว่างที่หลอดอัจฉริยะกลายเป็นหลอดโง่ ๆ ก็แทบไม่เคยจำเป็นต้องหรี่ไฟ เปลี่ยนสี หรือใช้ฟังก์ชันอัจฉริยะเลย สุดท้ายมันดูเหมือนเป็นไอเดียที่ดี แต่ก็คงคิดมากเกินไปกับเรื่องง่าย ๆ อย่าง “การเปิดไฟ”

    • เทคโนโลยีสมาร์ตโฮมส่วนใหญ่ขายได้ไม่ใช่เพราะช่วยจริง แต่เพราะมันดูเท่หรือฟังดูเข้าท่า
      ตัวอย่างเช่น หลอดไฟอัจฉริยะนั้นงี่เง่าเพราะมันทำลาย สวิตช์ไฟ ซึ่งเป็นวิธีควบคุมที่ชัดเจนและถูกต้องที่สุดในบ้าน ส่วนสวิตช์อัจฉริยะเป็นแนวคิดที่ดีกว่ามาก และยอมรับความจริงว่าช่วงเวลาที่ดีที่สุดในการเปิดไฟคือการกดสวิตช์ตอนเดินเข้าห้องสำหรับห้องส่วนใหญ่
      การมอนิเตอร์อาจมีประโยชน์มากจริง ๆ และการควบคุมด้วยตารางแบบแนบเนียนก็ดี แต่ผู้คนมักทำกันเกินเลยแบบโง่ ๆ
    • สำหรับความต้องการที่เชิงรุกกว่านี้ กำลังสร้าง LLM sensor array แบบโลคัล โดยให้แต่ละชุดเซ็นเซอร์มี thread แยกของตัวเอง
      ฉันไม่ต้องการเงื่อนไข else และก็ไม่ต้องการให้ไฟติดเพียงเพราะฉันทำ x หรือ y เซ็นเซอร์หาซื้อจาก AliExpress ได้ถูกและมีเยอะ แค่มี esp32-s3 อะไรทำนองนั้นก็พอ
      สมาร์ตโฮมควรคาดเดาความต้องการของฉันแบบไดนามิก แทนที่จะทำงานตามเงื่อนไขที่กำหนดไว้ล่วงหน้า และควรไปไกลกว่าการสั่งว่า “เปลี่ยนห้องนั่งเล่นเป็นสีแดง”
    • ถ้าตอนนั้นใช้ SSID แยกเฉพาะสำหรับโครงสร้างพื้นฐานนี้ได้ ก็แค่ย้ายมือถือกับโน้ตบุ๊กไปอยู่บน 5GHz SSID ใหม่
      แล้ว 2.4GHz เดิมก็จะกลายเป็นของสำหรับ IoT
    • การใช้งานหลักของหลอดไฟอัจฉริยะดูเหมือนจะเป็นการตั้ง ตัวตั้งเวลา ให้กับโคมไฟที่มีสวิตช์ผนัง แต่ถึงอย่างนั้นก็ทำด้วยสมาร์ตดิมเมอร์ได้
      น่าเสียดายที่มีอุปกรณ์ “อัจฉริยะ” มากเกินไปที่บังคับว่าการจะเปิดไฟได้ต้องสื่อสารกับเซิร์ฟเวอร์ในจีนหรือเซิร์ฟเวอร์ที่ไหนสักแห่งนอก LAN ของฉัน

  • ฮาร์ดแวร์ราคา $99 ของ Home Assistant ทำงานได้ดีมาก
    บางอุปกรณ์ส่งข้อมูลจุกจิกมากไปหน่อย แต่ส่วนใหญ่กรองออกได้ด้วยการตั้งค่าเริ่มต้นเพียงสองบรรทัดโดยไม่เสียความสามารถที่มีประโยชน์
    ถ้าข้อมูลที่เกิดขึ้นในห้องนั่งเล่นจะมากพอจนทำให้ SQLite บน eMMC รับไม่ไหว ก็น่าจะเป็นเรื่องน่าตกใจ
    Home Assistant เป็นหนึ่งในไม่กี่ผลิตภัณฑ์ช่วงหลังที่ทำให้ขั้นตอนการตั้งค่าน่ารื่นรมย์ จำนวนอุปกรณ์ประหลาดสารพัดที่มันค้นพบได้บนเครือข่ายนั้นน่าประทับใจ และยิ่งน่าประทับใจกว่าคือจำนวนที่หายไปเพราะผู้ขายคลาวด์หลายรายเริ่มล็อกระบบ สิ่งนี้มีผลชัดเจนต่อการตัดสินใจซื้อครั้งต่อ ๆ ไป และทำให้หันไปทางความเรียบง่ายมากขึ้น

    • แต่ก่อนเคยมีปัญหา ฐานข้อมูล SQLite พังตอนปิดระบบ หลังจากย้ายไปใช้ฐานข้อมูล PostgreSQL บน VM เดียวกันก็ไม่เจอปัญหาอีก
    • ทุกครั้งที่มีการพูดถึง HA คู่กับ Raspberry Pi ข้อร้องเรียนที่ใหญ่ที่สุดก็มักเป็นเรื่อง SD card พัง

  • สงสัยว่า SQLite รับไม่ไหวจริงหรือเปล่า ปัญหาดูเหมือนจะอยู่ที่ ฝั่งการตั้งค่าหรือโค้ด มากกว่าตัวฐานข้อมูลเอง
    แม้แต่บน Raspberry รุ่นเก่าก็น่าจะรับการเขียนระดับหลายพันครั้งต่อวินาทีได้
    สำหรับการใช้งานแบบนี้ มีโอกาสสูงว่าการทำคิวเขียนแยกตามประเภทเซ็นเซอร์และใช้การ insert แบบเป็นชุดก็เพียงพอแล้ว

    • อยากรู้รายละเอียดส่วนนี้มากกว่านี้ ดูไม่น่าใช่ว่า SQLite เองเป็นคอขวด แต่น่าจะมีสาเหตุอื่น
      ยากจะนึกภาพว่าบ้านเดี่ยวหนึ่งหลังจะสร้างภาระให้ SQLite[0] หนักขนาดนั้น เว้นแต่ว่าจะมีอุปกรณ์หลายพันตัวพยายามเขียนพร้อมกันและไม่สามารถรอคิวได้
      [0] https://sqlite.org/whentouse.html
    • ผู้เขียนต้นฉบับเอง พอเริ่มมีเซ็นเซอร์มากขึ้น SQLite ก็กลายเป็นปัญหา
      ตอนนั้นใช้ Pi 3 และตอนนี้อาจดีขึ้นแล้ว รวมถึงรู้ว่ามีการปรับปรุงประสิทธิภาพของ SQLite ด้วย แต่ในกรณีของฉัน พอย้ายข้อมูลอนุกรมเวลาไป Influx และย้ายฐานข้อมูลไป MySQL ก็แก้ปัญหาได้
      และไม่ว่า SD card จะดีแค่ไหน หากเขียนหนักระดับนี้สุดท้ายก็พังอยู่ดี
    • ยังสงสัยกับข้ออ้างนี้อยู่ ไม่ค่อยเข้าใจว่าหลายเซ็นเซอร์จะสร้างข้อมูลมากพอจน Raspberry Pi รับไม่ไหวได้อย่างไร
      ปัญหาอาจเป็นเพราะฐานข้อมูลอยู่บน microSD card ที่ช้ามากก็ได้

  • ต่อให้ Home Assistant ดีมากและดีขึ้นเรื่อย ๆ สุดท้ายก็ต้องมาจัดการอุปกรณ์ 10, 20, 50 ชิ้นขึ้นไปที่รับอัปเดตได้และเชื่อมต่ออยู่กับเครือข่าย
    ไม่ว่าจะเป็น Wi‑Fi หรือ Zigbee ต่างก็มีปัญหาในแบบของตัวเอง ทั้งรบกวนกันเองหรือไม่ก็พังไปเฉย ๆ
    ผมชอบศักยภาพของมัน บางครั้งก็ช่วยให้สบายใจและเอาไว้โชว์ได้ดี แต่เหมือนกับโครงสร้างพื้นฐานส่วนตัวทุกอย่าง มันค่อย ๆ สร้าง ต้นทุนจม พร้อมกับความคลื่นไส้และความเสียดายที่มากขึ้น

    • ผมรัน HA มาประมาณ 1 ปีแล้วและมันเสถียรมาก ตรงกันข้าม สิ่งที่สร้างงานเพิ่มจริง ๆ คือฝั่ง อุปกรณ์ที่มีบั๊ก
    • ถ้าเราไม่ได้โปรโตคอลมาตรฐานจริง ๆ ที่ทุกคนใช้ร่วมกัน สิ่งที่ต้องการจริง ๆ น่าจะเป็น integrations แบบ containerized ไม่แน่ใจว่า Matter จะครองตลาดได้ไหม
      WebAssembly ดูเป็นความเป็นไปได้ที่สมเหตุสมผลพอสมควรสำหรับการทำปลั๊กอินที่ไม่ต้องบำรุงรักษาต่อเนื่อง
    • สงสัยว่านี่เป็นประสบการณ์ที่พบได้บ่อยในหมู่ผู้ใช้ HA หรือเปล่า
      ผมสนใจ HA แต่ตอนนี้ใช้ HomeKit กับ Homebridge อยู่ และแทบไม่ต้องไปแตะมันเลยนอกจากตอนเพิ่มอุปกรณ์หรือปรับโครงสร้างใหม่

  • ดีใจที่เห็นว่าผมผ่านขั้นตอนเกือบเหมือนกับผู้เขียนต้นฉบับเมื่อหลายปีก่อน และลงเอยด้วยข้อสรุปเดียวกัน
    ผมซื้อ ฮาร์ดแวร์เฉพาะทาง แทนวิธีแบบ VM เพราะอยากให้มันแยกขาดจากโฮมเซิร์ฟเวอร์ที่ใช้รันงานไม่สำคัญโดยสิ้นเชิง ผมซื้อ Minisforum mini PC มา ซึ่งสำหรับ HA แล้วทั้งประสิทธิภาพ RAM และพื้นที่เก็บข้อมูลถือว่าเหลือเฟือเกินจำเป็น แต่ปกติผมก็ทำแบบนี้อยู่แล้ว
    ตอนใช้อุปกรณ์เกิน 100 ชิ้น ผมก็เปลี่ยนไปใช้ MariaDB กับ Influx และแก้เรื่องระบบทำความร้อนไปตั้งแต่หลายปีก่อนแล้ว ผมวางเซ็นเซอร์อุณหภูมิ BLE รุ่น Switchbot Meter Plus ไว้ทุกห้องในบ้าน และติด Z-Wave TRV ไว้ที่หม้อน้ำทุกตัว ผูกค่าตามเกณฑ์กลางวัน/กลางคืนแยกชั้นบนกับชั้นล่าง พร้อมข้อยกเว้นสำหรับโฮมออฟฟิศ แล้วคำนวณเป็นอุณหภูมิเฉลี่ยแบบหนึ่ง
    ด้วยสคริปต์ที่สร้าง hysteresis ถ้าอุณหภูมิเฉลี่ยต่ำกว่าค่าที่ตั้งไว้ -0.2°C ก็จะเปิดระบบทำความร้อนทั้งบ้าน และถ้าสูงกว่าค่าที่ตั้งไว้ +0.3°C ก็จะปิด แต่ละห้องมีค่าอุณหภูมิเป้าหมายของตัวเอง และถ้าอุณหภูมิห้องเกินค่าที่ตั้งไว้ก็จะปิด TRV แล้วเปิดใหม่เมื่ออุณหภูมิลดลง ตรงนี้ก็มี hysteresis แบบอ่อน ๆ เช่นกัน
    ยังมีระบบอัตโนมัติสำหรับโหมดกลางวัน/กลางคืน/ไม่อยู่บ้าน ที่ใช้ค่าอุณหภูมิเป้าหมายต่างกันและสั่งเปิด/ปิดรายห้องตามสถานการณ์
    เรื่องแสงสว่างผมใช้ Circadian Lighting ซึ่งรองรับกลุ่มไฟ ดังนั้นแค่ระบุกลุ่มไว้ใน yaml ก็จัดการทั้งกลุ่มได้เลย ฟังก์ชันบางอย่างอาจน้อยกว่าปลั๊กอิน Adaptive Lighting แต่ผมไม่ต้องกังวลเรื่องความแตกต่างของชนิดหลอดไฟ โดย 80% เป็น Hue และที่เหลือเป็นหลอดขาว/สีของ IKEA ปนกัน

    • ผมคือผู้เขียนต้นฉบับ ใน Flux หรือ Adaptive Lighting ผมทำให้กลุ่มทำงานไม่ได้
      ไม่รู้ว่าทำไม และเอาจริง ๆ ก็ไม่ได้ใช้เวลาลองมากนัก ไอเดียเรื่องระบบทำความร้อนดูดี เดี๋ยวจะลองศึกษา
    • ถ้าเป็นแบบเปิดเมื่ออุณหภูมิเฉลี่ยต่ำกว่าค่าที่ตั้งไว้ -0.2°C และปิดเมื่อสูงกว่า +0.3°C นั่นคือวิธีที่ผมใช้ก่อนจะไปเจอ generic thermostat helper

  • เดิมทีผมตั้งใจจะใช้ HA แค่เพื่อหลุดพ้นจากแอปสมาร์ตโฮมที่จำกัดหรือแย่ ๆ แต่พอลองใช้กับบางอย่างในบ้านราว 6 เดือนแล้ว กลับชอบมันมาก
    ปีนี้คงจะขยายจริงจังด้วยสวิตช์ เซ็นเซอร์ และอย่างอื่น
    โปรเจกต์ที่น่าจะลงลึกที่สุดคือการเดินสาย พัดลม PWM ที่ตอบสนองต่ออุณหภูมิไว้ในตู้เก็บของ IKEA ซึ่งภายในมีอุปกรณ์เทคโนโลยีอย่างเกมคอนโซล ตัวแปลงแรงดัน โมเด็ม เราเตอร์ เครื่อง HA และเครื่องพิมพ์เลเซอร์ เพื่อป้องกันความร้อนสูงเกินไป ผมตื่นเต้นที่จะได้เริ่ม
    นอกจากนี้ก็มีแผนเรื่องเซ็นเซอร์วัดน้ำในกระถางต้นไม้แบบไร้สาย การจัดการมู่ลี่และม่าน และการจัดการระบายอากาศตามค่าฝุ่นละเอียด, VOC และ CO2
    ผมไม่ค่อยดึงดูดใจกับสมาร์ตล็อกหรือกล้องกริ่งประตู รวมถึงกล้องทั่วไป มันแอบน่าขนลุกนิดหน่อย แต่ก็เข้าใจว่าทำไมถึงน่าสนใจ

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