שלום עומר

המלכודת הקלאסית של IoT למזון

המערכת שלך תעבוד מעולה ביום הראשון. ביום העשירי תתחיל בעיה שאפילו לא תזהה — ורק שבוע אחרי זה תגלה שקרה משהו.

4 המלכודות שהורגות פרויקטי IoT למזון

1. 1היעדר heartbeat
   החיישן שולח טמפרטורה כל פעם שהיא משתנה. אם הטמפרטורה יציבה — אין הודעות. אם החיישן נתקע — גם אין הודעות. הדשבורד לא יודע להבדיל. הפתרון: heartbeat כל 30 שניות ("אני חי, הנה הטמפרטורה"), ו-alert אם חלפו 90 שניות בלי heartbeat.

   if (Date.now() - lastHeartbeat > 90000) { alert('sensor_unresponsive') }
2. 2WebSocket reconnect ללא data backfill
   ה-WebSocket מתנתק (רשת חלשה, שרת reboot, מה שיהיה). מתחבר חזרה אוטומטית — אבל לא ביקש מהשרת את הנתונים שפספסנו. יש חור בהיסטוריה. הפתרון: כל reconnect בודק "מה המזהה האחרון שקיבלתי" ומבקש delta.
3. 3Alert storms
   מקרר אחד ירד לטמפרטורה חריגה ל-30 שניות. עכשיו אתה מקבל 200 התראות פעם ב-10 שניות כל הלילה. הצוות מכבה את ההתראות. כשבאמת יש בעיה — אף אחד לא שם לב. הפתרון: debouncing (חמש דקות bucket) + escalation (SMS רק אחרי 15 דק' ברציפות).
4. 4Time zones במסמכי HACCP
   משרד הבריאות דורש לוגים של 3 שנים עם timestamps. אם החיישן שולח UTC והדשבורד מציג Asia/Jerusalem בלי DST, הרגולטור יגיד "חסרות לך שעתיים באפריל". הפתרון: שמור הכל ב-UTC, המר רק בתצוגה. תיעוד ה-timezone בכל row.

הסטאק המומלץ (React + Firebase, כמו שציינת)

Firebase מעולה ל-IoT בסקייל שלכם. כמה דגשים ספציפיים לבעיות שתיארתי:

Realtime Database > Firestore ל-heartbeat

ל-heartbeat בכל 30 שניות מ-100+ חיישנים — Firestore יקר יותר. Realtime Database מותאם בדיוק למקרה הזה (pricing on connections, לא reads).

Cloud Functions עם scheduled checks

Cron שרץ כל דקה ובודק "איזה חיישנים לא שלחו heartbeat ב-90 שניות האחרונות?". זה נוסף ל-reactive alerts שרצים על data changes.

Firestore ל-historical data + HACCP logs

שם הנתונים בטוחים לשנים, queryable לבדיקות רגולטוריות, ולא יקר כי לא כל שנייה נכתבת שם.

מערכת דומה שבניתי

לא ממש IoT, אבל עם אותו pattern של real-time data + alerts + heartbeat.