ניטור חיישני בטיחות אש באפליקציה ניידת
אנו מפתחים אפליקציות ניידות לניטור חיישני בטיחות אש, תוך אינטגרציה עם כל PPK באמצעות OPC UA, MQTT או RS-232. בפרויקט אחד עבור היפרמרקט, נתקלנו במצב: האפליקציה הציגה "הכול תקין", בעוד בלוח הבקרה הייתה נורית אדומה. התברר שהשער (gateway) פענח שגוי תגובות על פני RS-232. מאז, כל ביט בפרוטוקול מאומת בקריאה כפולה. הצוות שלנו מפתח אפליקציות כאלה כבר למעלה מ-7 שנים עם למעלה מ-50 פרויקטים מוצלחים, וחוסך ללקוחות עד 30% מעלויות הניטור החודשיות. אנו מבטיחים אמינות ועמידה בדרישות בטיחות האש.
לוח הבקרה לגילוי אש (PPK/panel) מסוגים Bolid S2000-KDL, Honeywell NOTIFIER, Siemens Sinteso נשאר תמיד המאסטר: האפליקציה הניידת קוראת את מצבו אך לעולם אינה עוקפת את האוטומציה המקומית. אישור אזעקה בטלפון אינו מאפס את ה-PPK—נדרש מקלדת פיזית לשם כך.
אילו PPK ופרוטוקולים נתמכים?
אנו עובדים עם כל PPK המספק גישה דרך OPC UA, MODBUS TCP, REST API, או דרך RS-232 עם פרוטוקול קנייני. עבור Honeywell NOTIFIER אנו משתמשים ב-REST API דרך LifeSafety Power Manager, עבור Bolid S2000-KDL—RS-232 המומר ל-MQTT דרך שער לינוקס. OPC UA הוא התקן למערכות מודרניות, אך PPK ישנים יותר דורשים לעיתים קרובות קריאה ישירה של היציאה. בכל מקרה, אנו מיישמים שרשרת אמינה: PPK → gateway → MQTT → אפליקציה ניידת.
אינטגרציה עם PPK דרך OPC UA ו-RS-232
ארכיטקטורה טיפוסית: שרת מיני-לינוקס בחדר השרתים קורא את ה-PPK דרך RS-232/OPC ומפרסם אירועים מנורמלים ל-MQTT. הלקוח הנייד נרשם ל-MQTT על גבי TLS. אנו משתמשים ב-Flutter 3.x (Dart) עם ספריית mqtt_client, המספקת גמישות גם ל-iOS וגם ל-Android.
מבנה נושא MQTT:
fire/{buildingId}/panel/{panelId}/zone/{zoneId}/state
fire/{buildingId}/panel/{panelId}/alarm
fire/{buildingId}/panel/{panelId}/faultמצב אזור הוא enum: fire/{buildingId}/panel/{panelId}/zone/{zoneId}/state fire/{buildingId}/panel/{panelId}/alarm fire/{buildingId}/panel/{panelId}/fault , normal, alarm, fault, disabled.
MQTT מעביר אירועים תוך 100 אלפיות שנייה, מהיר פי 10 מאשר שאילתות REST. עבור אזעקות, זה קריטי.
עדיפות ותצוגה
באפליקציה, אירועים מקבלים עדיפות קפדנית:
enum FireEventPriority { alarm, fault, warning, normal }
Color getZoneColor(ZoneState state) => switch (state) {
ZoneState.alarm => const Color(0xFFD32F2F), // красный
ZoneState.fault => const Color(0xFFFF6F00), // оранжевый
ZoneState.disabled => const Color(0xFF757575), // серый
ZoneState.test => const Color(0xFF1976D2), // синий
ZoneState.normal => const Color(0xFF388E3C), // зелёный
};אזעקה חייבת להיות גלויה מיד: FCM test + enum FireEventPriority { alarm, fault, warning, normal } Color getZoneColor(ZoneState state) => switch (state) { ZoneState.alarm => const Color(0xFFD32F2F), // красный ZoneState.fault => const Color(0xFFFF6F00), // оранжевый ZoneState.disabled => const Color(0xFF757575), // серый ZoneState.test => const Color(0xFF1976D2), // синий ZoneState.normal => const Color(0xFF388E3C), // зелёный }; עם priority: high וצליל. במכשירי Xiaomi/Huawei, ללא notification.android.channel_id ההתראה אובדת ברקע—זו טעות נפוצה.
כיצד אנו מבטיחים אמינות
אנו מתכננים את המערכת כך שכשל באפליקציה הניידת לא ישפיע על אוטומציית האש. אנו משתמשים בערוצים כפולים: MQTT + גיבוי HTTP, שמירת מצבים אחרונים במכשיר. כל אירוע אזעקה מתועד עם חותמת זמן ומזהה אזור. אנו מבטיחים משלוח התראות push תוך 3 שניות כאשר קיימת גישה לאינטרנט.
| פרוטוקול | זמן השהיה | אמינות | מורכבות יישום |
|---|---|---|---|
| MQTT | <100 אלפיות שנייה | 99.99% | בינונית |
| REST | 1-5 שניות | 99.9% | נמוכה |
מקרה אמיתי: עבור קניון עם 15 PPK של Bolid (2000 אזורים), פרסנו אשכול עמיד לתקלות: שני שערים על שרתים שונים, MQTT עם QoS 2, וערוץ נפרד לאזעקות. במשך שנה של פעילות—אפס התראות שליליות שגויות.
הגדרת התראות Push לאזעקות
- צור ערוץ התראות ייעודי ב-
IMPORTANCE_HIGHעםnotification_priority: PRIORITY_MAX. - הגדר FCM עם
AndroidManifest.xmlוצייןIMPORTANCE_HIGH. - עבור iOS, הוסף
priority: highו-channel_idב-payload. - בדוק על מכשירים אמיתיים, כולל Xiaomi ו-Huawei.
| פלטפורמה | שירות התראות | עדיפות | אחזור ברקע |
|---|---|---|---|
| Android | FCM | HIGH | + (data-only) |
| iOS | APNs | critical | + (background fetch) |
התראות push ב-Android דרך FCM נמסרות תוך 1-2 שניות בממוצע, מהיר פי 5 משאילתות סטנדרטיות.
שלבי פיתוח
- ניתוח ועיצוב—דיון בסוג PPK, מספר אזורים, דרישות מיפוי.
- פיתוח שער—כתיבת ממיר פרוטוקולים ב-Python/C++ עבור לינוקס.
- אפליקציה ניידת—Flutter 3.x (Swift/Kotlin לחלקים מקוריים).
- בדיקות—יחידה, אינטגרציה, עומס עד 1000 אירועים בשנייה.
- פריסה—פרסום ב-App Store וב-Google Play, הגדרת TestFlight ו-Firebase App Distribution.
- הדרכה—הוראות לצוות התורן, מסירת קוד מקור ותיעוד.
היקף העבודה
- תיעוד ארכיטקטורה (תרשים אינטגרציה, דיאגרמות ER)
- פיתוח שער (לינוקס, Python/C++, המרת פרוטוקולים)
- אפליקציה ניידת (Flutter 3.x, Swift 5.9, Kotlin)
- הגדרת התראות push (FCM + APNs)
- בדיקות (יחידה, אינטגרציה, עומס)
- פריסה ל-App Store Connect ול-Google Play Console
- הדרכת צוות תורן ותיעוד טכני
יומן אירועים ואחראי תורן
כל אירוע אזעקה מתועד עם חותמת זמן, מזהה אזור, סוג חיישן, והמשתמש שאישר את הקבלה. אישור באפליקציה הוא רק שכבה אינפורמטיבית, לא תחליף לאיפוס פיזי ב-PPK.
הודות לאוטומציה, הלקוחות שלנו חוסכים עד 30% בעלויות הניטור החודשיות, מבטלים שיגורים שגויים ומקצרים את זמן התגובה. עלות הפיתוח מחושבת באופן אישי, אך פרויקטים טיפוסיים נעים בין $8,000 ל-$15,000.
צור קשר להערכת פרויקט—נציע את הפתרון האופטימלי. בקש ייעוץ לאינטגרציה של ה-PPK שלך לאפליקציה ניידת.
תקנים: NFPA 72, SP 5.13130.2009