سرانجام آزاردهنده‌ترین مشکل داشبورد هوم اسیستنت را حل کردم

هوم اسیستنت یکی از بهترین نرم‌افزارهایی است که تاکنون به کار گرفته‌ام؛ اما مثل هر نرم‌افزار دیگری، دیر یا زود یک به‌روزرسانی چیزی را از کار می‌اندازد. برای من، این اتفاق با انتشار نسخهٔ ۲۰۲۵.۱۲ هوم اسیستنت رخ داد؛ نسخه‌ای که داشبوردهای پیش‌فرض سراسری و کاربرمحور را معرفی کرد. این به‌روزرسانی برای کسی با یک راه‌اندازی ساده و تک‌کاربره عالی بود، اما برای فردی مانند من که روی چند دستگاه از چند داشبورد استفاده می‌کند، به کابوسی تمام‌عیار بدل شد.

این به‌روزرسانی امکان تعیین داشبورد پیش‌فرض جداگانه برای هر دستگاه را از بین برد. ساختن حساب‌های کاربری متفاوت برای دستگاه‌های گوناگون هم برای من چندان منطقی نبود؛ پس شروع به جست‌وجو کردم. و حالا سرانجام آزاردهنده‌ترین مشکل داشبورد هوم اسیستنت را برطرف کرده‌ام.

اسکریپتی از جامعهٔ کاربران که روی کاغذ بی‌نقص به نظر می‌رسید

حافظهٔ محلی تمام راز کار بود؛ تا وقتی که دیگر نبود

نخستین بار در انجمن کاربران هوم اسیستنت به یک راه‌حل موقت برخوردم که روی کاغذ امیدوارکننده به نظر می‌رسید. این راه‌حل یک پنل سفارشی در نوار کناری بود: فایل جاوااسکریپتی که در مسیر config/www/dashboard/device-default-dashboard.js قرار می‌گرفت و از طریق panel_custom در پیکربندی هوم اسیستنت ثبت می‌شد.

این پنل، ورودی‌ای در نوار کناری همراه با فهرست کشوییِ همهٔ داشبوردهایتان اضافه می‌کند. یکی را انتخاب می‌کنید و اسکریپت آن انتخاب را در حافظهٔ محلی مرورگر ذخیره می‌کند؛ هم‌زمان تنظیمات پیش‌فرض جدیدترِ سمت سرور را نیز پاک می‌کند تا HA به روش قدیمی‌ترِ به‌خاطر سپردن نمای پیش‌فرض برای هر مرورگر بازگردد. سازوکار جایگزینِ قدیمیِ حافظهٔ محلی هنوز در نسخهٔ کنونی HA فعال است و به همین دلیل این روش اساساً می‌تواند کار کند. ایده ساده است: به‌جای درافتادن با پیش‌فرض تازه و سراسری، آن را دور می‌زنید و می‌گذارید هر مرورگر ترجیح خودش را به خاطر بسپارد؛ درست همان‌گونه که HA پیش از به‌روزرسانی ۲۰۲۵.۱۲ عمل می‌کرد.

روی کاغذ عالی به نظر می‌رسد، اما راه‌حلی که پیدا کردم چهار ایراد جداگانه داشت و بدون دست‌کاری، آن‌طور که انتظار می‌رفت کار نمی‌کرد. از همین‌جا شکار باگ‌ها آغاز شد.

هر اصلاحی که انجام دادم، مشکل بعدی را پنهان کرده بود

پیش‌فرض‌های کهنه، عنصرهای غیرفعال و فهرست کشوییِ خاموش

نخستین مشکل، یک پیش‌فرض سراسریِ کهنه بود که هرگز پاک نمی‌شد. بررسی سریع داده‌های رابط کاربری HA نشان داد پنل پیش‌فرض همچنان روی داشبورد پیش‌فرض حساب کاربری‌ام، از پیش از آن‌که حتی اسکریپت را دست بزنم، تنظیم شده است. HA پیش از آن‌که سراغ روش جایگزینِ حافظهٔ محلی برای هر دستگاه برود، این مقدار سطح سیستم را بررسی می‌کند؛ بنابراین مهم نبود پنل در رابط کاربری چه می‌کند، آن تنظیم باقی‌مانده همیشه برنده می‌شد.

دومین ایراد در کد راه‌اندازی پنل بود. اسکریپت با خواندن نمونه‌وارِ customElements.get("ha-panel-lovelace")، LitElement را به دست می‌آورد؛ اما این عنصر فقط زمانی ثبت می‌شود که واقعاً یک داشبورد لاولیس را در همان نشست مرورگر باز کرده باشید. اگر از یک زبانهٔ تازه مستقیماً به پنل سفارشی بروید، آن عنصر هنوز وجود ندارد. نتیجه، صفحه‌ای خالی و کنسول مرورگری پر از خطاهای TypeError جاوااسکریپت بود.

مشکل بعدی، که موذیانه‌تر هم بود، این بود که ha-select دیگر مانند گذشته کار نمی‌کند. HA این مؤلفه را بازنویسی کرده تا فقط گزینه‌های کشوییِ خودکارِ خودش را بشناسد؛ گزینه‌هایی که اکنون به‌جای عنصرهای قدیمی و دست‌سازی که اسکریپت استفاده می‌کرد، رویداد wa-select را از طریق مؤلفهٔ جدید Web Awesome در لایه‌های زیرین اجرا می‌کنند. فهرست کشویی کاملاً عادی به نظر می‌رسید، گزینه‌ها نمایش داده می‌شدند و ظاهر آن هم درست بود، اما با کلیک روی هر داشبورد در فهرست هیچ اتفاقی نمی‌افتاد. نه خطایی، نه بازخوردی؛ فقط سکوت.

سرانجام، پس از آن‌که همه‌چیز اصلاح شد، مرورگرم همچنان نسخهٔ خراب اسکریپت را اجرا می‌کرد. هوم اسیستنت همه‌چیز را در مسیر /local/ با حافظه‌سازی بسیار تهاجمی ارائه می‌کند و داده‌ها را تا ۳۱ روز نگه می‌دارد. واردسازی پویای ماژول‌های ES نیز، برخلاف یک برچسب اسکریپت معمولی، همیشه به‌درستی از بازخوانی اجباری صفحه پیروی نمی‌کند. در نتیجه، هر اصلاحی که انجام می‌دادم عملاً نامرئی بود، مگر آن‌که مستقیماً با حافظهٔ نهان سروکار پیدا می‌کردم.

چهار باگ، چهار اصلاح، یک داشبورد کارآمد

ردیابی هوم‌اسیستنت-مین و رشتهٔ پرس‌وجوی بی‌اثرکنندهٔ حافظهٔ نهان

راه انداختن این سازوکار یعنی رسیدگی جداگانه به هر باگ، نه این فرض که یک وصله خودبه‌خود باقی مشکلات را هم حل می‌کند. ابتدا مقدار باقی‌ماندهٔ default_panel را با یک فراخوانی مستقیم وب‌سوکت به frontend/set_system_data پاک کردم و سپس با خواندن دوبارهٔ داده‌های سیستم مطمئن شدم که حذف شده است.

برای حل مشکل راه‌اندازی، مرجع را تغییر دادم تا LitElement به‌جای ha-panel-lovelace از home-assistant-main گرفته شود. home-assistant-main فارغ از شیوهٔ رفتن به پنل، به‌عنوان بخشی از پوستهٔ برنامه حتماً وجود دارد؛ بنابراین اسکریپت حتی هنگام باز کردن مستقیم پنل نیز می‌تواند راه‌اندازی شود.

منوی کشویی به بازنویسی گسترده‌تری نیاز داشت. به‌جای آن‌که گزینه‌ها را دستی نمایش دهم، داشبوردهای موجود را از راه ویژگی .options خودِ ha-select به آن سپردم. به این ترتیب، مؤلفه گزینه‌های درست و آماده‌اتصال را درون خود ایجاد می‌کند. مقدار انتخاب‌شده را نیز از طریق ev.detail.value خواندم؛ همان روشی که انتخاب‌گر رسمی داشبورد در هوم اسیستنت به کار می‌گیرد.

برای حل مشکل کش، پسوند ?v=۲ را به مدخل module_url در پرونده configuration.yaml افزودم و هوم اسیستنت را دوباره راه‌اندازی کردم. این کار تضمین کرد که همه دستگاه‌های شبکه نشانی تازه‌ای درخواست کنند، نه این‌که همان ماژول کهنه‌ای را بارگذاری کنند که پیش‌تر در کش خود نگه داشته بودند.

اگر می‌خواهید این تغییرها را روی نمونه HA خود پیاده کنید، مخزنی در گیت‌هاب ساخته‌ام که جاوااسکریپت اصلاح‌شده انتخاب‌گر داشبورد، بخشی از پیکربندی و شرحی دقیق از دیگر ریزه‌کاری‌هایی را در بر دارد که شاید با آن‌ها روبه‌رو شوید. راه‌حل از آنچه به نظر می‌رسد بسیار ساده‌تر است و برای بیشتر افراد، کافی است پرونده device-default-dashboard.js را کپی کنند و بخش پیکربندی را بیفزایند. اگر ترجیح می‌دهید، می‌توانید آن را از راه HACS هم نصب کنید.

بازنویسی فرانت‌اند؛ یک قدم تا از کار افتادن دوباره

خطاهای کوچک، اما پنهان‌کننده یکدیگر

هیچ‌یک از این چهار خطا به‌ویژه دشوار نبودند. این‌ها دقیقاً از همان مشکلاتی هستند که وقتی یک فرانت‌اند متن‌بازِ پرشتاب میان انتشارها ساختار مؤلفه‌هایش را تغییر می‌دهد و اسکریپت‌های جامعه کاربری ناگزیر عقب می‌مانند، با آن‌ها روبه‌رو می‌شوید. آنچه آزاردهنده بود، پیچیدگی هیچ راه‌حل جداگانه‌ای نبود؛ بلکه این بود که هر خطا، خطای بعدی را پنهان می‌کرد و بنابراین، شکست همیشه انگار از عامل دیگری ناشی می‌شد.

حالا هر دستگاه در خانه‌ام مستقیماً با همان داشبوردی بالا می‌آید که واقعاً می‌خواهم روی آن ببینم. با این همه، این راه‌حل هنوز یک میان‌بر است، نه قابلیتی رسمی؛ و تغییرهای آینده فرانت‌اند ممکن است دوباره آن را از کار بیندازند. با وجود این، هرچند اصلاح کوچکی برای بهبود تجربه روزمره است، همان انعطاف‌پذیری ویژه هر دستگاه را بازمی‌گرداند که هوم اسیستنت را از ابتدا شخصی و دلنشین کرده بود.

منبع: این مطلب ترجمه و بومی‌سازی مقاله‌ای از MakeUseOf به قلم Yadullah Abidi است. مشاهده مقاله اصلی