كيف بنينا جهاز دخول يعمل دون إنترنت
باب قاعة اجتماعات يفرض الحجوزات بنفسه — ويستمر بالعمل عندما تنقطع الشبكة. قصة الهندسة وراء جهاز الدخول الذي بنيناه لـ Business Avenue.
تفوتر Business Avenue، أكبر مزوّد للمكاتب المجهّزة في العراق، قاعات اجتماعاتها بالحجز. هذه الجملة تخفي مشكلة صعبة: إن قال الحجز إن القاعة لك من الثانية إلى الثالثة، فعلى الباب نفسه أن يوافق — يفتح لك، ويبقى مغلقًا لسواك، ويتذكر ما حدث. بنينا منصة الإدارة التي تستقبل تلك الحجوزات. ثم كان علينا إيصالها إلى الباب.
لماذا خسر الجاهز
أنظمة الدخول التجارية تفترض أحد عالمين. إما لوحة أرقام مستقلة لا تعرف شيئًا عن نظام حجوزاتك — فيكتب الجميع رمز المدير نفسه لكل اجتماع — وإما وحدة تحكم سحابية تتصل بالخادم قبل أن تقرر الفتح.
العالم الأول لا يؤدي المهمة. والثاني يؤديها إلى أن يتلعثم الإنترنت — ومن يعمل في العراق يخطط للتلعثم، لا للمسار السعيد. بابٌ يتوقف أثناء انقطاعٍ ليس نظام دخول؛ بل عميل محبوس أمام قاعة دفع ثمنها.
المطلب، بصراحة: على الباب أن يتخذ القرار الصحيح بلا شبكة، وبلا خادم، و— لفترة — بلا كهرباء من المصدر.
الجهاز
انتهينا إلى تصميم الكائن كله: Raspberry Pi 5 بشاشة لمس 7 بوصات في هيكل صممناه بأنفسنا، مثبّت عند الباب. مرحّل يقود قفلًا مغناطيسيًا. قارئ RFID عبر USB يستقبل بطاقات الأعضاء؛ والضيوف يكتبون رمز الحجز من حجزهم على شاشة الكشك. ووحدة UPS مرافقة — منا أيضًا، وبهيكل مخصّص أيضًا — تُبقي الباب حيًّا خلال انقطاع الكهرباء.
البرمجيات هي حيث يتحقق المطلب. خدمة جهاز بلغة Python (بإطار FastAPI) تملك الباب. تحتفظ بذاكرة SQLite محلية بكل ما تحتاجه — حجوزات وبطاقات وجداول — وتتخذ كل قرار فتح/رفض محليًا، على تلك الذاكرة، في أجزاء من الثانية. وواجهة الكشك تطبيق SvelteKit يقدّمه الجهاز نفسه؛ حتى واجهة المستخدم لا تحتاج الإنترنت.
"دون إنترنت أولًا" انضباطٌ، لا ميزة
حين تكون الشبكة متاحة، يدير الجهاز ثلاث حلقات هادئة مع خادم Business Avenue: مزامنة (اسحب أحدث الحجوزات والبطاقات)، وأحداث (ادفع ما حدث عند الباب)، ونبض (أخبر اللوحة أن الباب حي). وحين تسقط الشبكة لا يتغير شيء عند الباب — تستمر القرارات من الذاكرة، وتصطف الأحداث محليًا، ويتصالح كل شيء حين يعود الاتصال.
لاحظ ما الذي ليس عليه الخادم الخلفي في هذا المخطط: ليس في مسار القرار. الخادم للمزامنة والإدارة — إقران جهاز جديد باللوحة، ودفع تحديثات عبر الأثير، وجمع الأحداث. أما الصلاحية فتسكن عند الباب.
بنيناه كبرمجيات، لأنه برمجيات
جهازٌ تشحنه إلى جدار عميل لا يمكن تنقيحه من فوق كتفه، لذا بنينا كل شيء ليكون قابلًا للاختبار دون عتاد. تعمل خدمة الجهاز فوق طبقة تجريد للعتاد بتطبيقين: حقيقي (GPIO وقارئ RFID على الجهاز) ومحاكى (حاسوبك المحمول). وخادم محاكٍ يقوم مقام واجهة Business Avenue. النتيجة: المنظومة كاملة — إقرانًا ومزامنة وقرارات وواجهة كشك — تعمل على حاسوب مطوّر بلا أي عتاد، و39 اختبارًا آليًا يعمل على خدمة الجهاز مع كل تعديل.
والتهيئة شيفرة أيضًا: Ansible وsystemd يحوّلان جهازًا جديدًا إلى كشك مُحصَّن — نظام مُقفَل وخدمة تعمل تلقائيًا وحارس يُعيد التشغيل — بالطريقة نفسها كل مرة. هذا ما يجعله منتج أسطول لا قطعة يتيمة: الباب الثاني عشر يُركَّب تمامًا كالباب الأول.
ما الذي نقوله لك إن كنت تفكر بعتاد مخصّص
- ابدأ من حالة الفشل، لا من قائمة الميزات. سؤال "ماذا يحدث حين تسقط الشبكة؟" شكّل هذا الجهاز أكثر من أي طلب ميزة.
- الهيكل جزء من المنتج. تصميم حاويتنا بأنفسنا جعل العتاد يناسب الباب لا العكس.
- ما لا تستطيع اختباره على حاسوب محمول ستختبره على عميلك. طبقة المحاكاة والخادم المحاكي كلّفا أيامًا ووفّرا أسابيع.
- فكّر أسطولًا من اليوم الأول. الإقران والتهيئة والتحديثات هي الفرق بين نموذج أولي ونشرٍ حقيقي.
دراسة الحالة الكاملة — بالصور المفككة ووحدة UPS — هنا. وقد صار الجهاز اليوم منتجًا باسم PearlAccess. وإن كان لعملك بابٌ أو مكنة أو عملية تحتاج برمجياتٍ بجسد، فهذه خدمة نقدّمها.
برمجيات تحتاج جسدًا؟
نصمّم ونبني أجهزة متصلة تتكامل مع أنظمتك — وتواصل عملها حين لا تعمل الشبكة.