פיתוח אפליקציית מובייל לבית חכם (וילונות/תריסים)

פיתוח אפליקציית מובייל לבית חכם: היכן נשברת השליטה

המשתמש גורר את הסליידר ל-30% — ולא קורה כלום. כעבור כמה שניות הווילונות נוסעים עד הסוף, ובמסך כל הזמן הזה תלוי "מבוצע". השהיית תגובה של האפליקציה בכמה שניות שוברת את עצם המשמעות של שליטה בווילונות מהסמארטפון: האדם לוחץ פעם שנייה, מקבל תנועה הפוכה ומפסיק לסמוך על המערכת.

הפקודה עוברת ארבעה מפרקים: אפליקציה, ענן, בקר מקומי, מנוע. בכל אחד — תור משלו, פסק זמן משלו וניסיון חוזר משלו, ולכן פקודה אחת מגיעה למנוע פעמיים או לא מגיעה כלל.

בעת אובדן קשר עם הבקר האפליקציה מציגה "פתוח" אופטימי, אף שהמנוע לא זז: המצב נלקח מהאישור האחרון ולא מהמציאות.

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

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

מה משתנה לאחר ההטמעה: תגובה, תרחישים, כשלים

לאחר ההטמעה משתנים שלושה דברים מדידים: שיעור הפקודות המגיעות למנוע בניסיון הראשון, זמן התגובה של הממשק למחווה והתנהגות התרחישים בעת ניתוק קשר. בעבר בדקו זאת "בעין" — כעת יש יומן פקודות וגבול ברור בין תקין לפגם.

מהירות תגובת הממשק וצפיות המחווה

סליידר המיקום והמחווה "משוך את הווילון" מעובדים באופן אופטימי: הממשק מציג את המיקום החדש מיד, והפקודה יוצאת לתור עם אישור מהמנוע. אם אין אישור בתוך החלון שהוקצה, המצב מתגלגל חזרה למציאותי — המשתמש רואה אמת ולא חצי תקוע.

שיעור הפקודות המגיעות בניסיון הראשון נשמר מעל 99%: לחיצות חוזרות ו"רעד" של המחווה נבלמים בצד האפליקציה.

תרחישים ששורדים ניתוק קשר

לוחות זמנים ותגובות לחיישני אור, נוכחות וטמפרטורה נשמרים מקומית על השער, ולא רק בענן: בנפילת הערוץ הווילונות ממשיכים להיסגר לפי זמן ורמת תאורה. כשהקשר חוזר, האפליקציה משווה את המיקום הממשי של כל קבוצה עם הצפוי ומשלימה את השלבים שהוחמצו. כך נעלם סוג הכשל "התרחיש פעל למחצה", כשאחד הווילונות נסע והשני נשאר בפתח.

אינטגרציה עם אקוסיסטמות חיצוניות עוברת דרך Apple Home: תרחישים וקבוצות וילונות נראים מבחוץ, והתהליך ולוחות הזמנים נשארים באפליקציה.

מצבי שליטה: ענן, מקומי והיברידי

מצב השליטה קובע מה יקרה לווילונות כשהאינטרנט ייעלם או כשהענן יענה בהשהיה. הבחירה בין שליטה מלאה בענן, שליטה מקומית דרך בקר באתר ומצב היברידי — אינה עניין של נוחות הממשק, אלא של אילו תרחישים שורדים במצב חירום.

מתי הענן בלתי נמנע

מעגל הענן נדרש היכן שהתרחישים תלויים בנתונים חיצוניים: עוזרים קוליים, מיקום גאוגרפי, לוחות זמנים לפי זריחת השמש, גישה לאורחים. אם אין בקר באתר, והמנועים מתחברים ישירות, הענן נשאר נקודת ההרכבה היחידה של המצב.

היברידי: מה נפתר באתר ומה ברשת

באתר נפתר כל מה שדורש תגובה מיידית: פקודות מהשלט ומהאפליקציה באותה רשת, קבוצות וילונות, מצבי קצה. לרשת מוציאים לוחות זמנים, תרחישים לפי אור וטמפרטורה, היסטוריית אירועים ושליטה מרחוק. בעת אובדן הערוץ האפליקציה עוברת לכתובת מקומית וממשיכה לעבוד.

שלבי ההטמעה: מביקורת האתר ועד מסירה

אפליקציית מובייל לווילונות ותריסים שולטת לא במסך אלא במנועים דרך הבקר: שגיאה בתרחיש מתבטאת בפיזיקה — הכנף לא הגיעה, קבוצת מנועים יצאה לא מתואמת. לכן את מסלול העבודה בונים מהאתר, ולא מהדמיית הממשק.

1. ביקורת אתר האוטומציה — סוגי מנועים, הזנה, קווי מתח נמוך, איכות הקשר בקירות עבים, מה משאירים מהקיים.
2. תכנון תרחישים ותפקידים — קבוצות וילונות לפי חדרים, מצבים יומיים ותרחישיים, הרשאות דייר, אורח, שירות תפעול.
3. הגדרת בקרים ותהליך מקומי — לוחות זמנים ופקודות בסיס מבוצעים במקום, ללא רשת חיצונית.
4. מימוש האפליקציה — ממשק לפי קבוצות ספציפיות ומשוב על מיקום ממשי של היריעה, ולא "פתוח — סגור".
5. בדיקת סטנד על מנועים אמיתיים — הרצת תרחישים לפני ההתקנה: מהלך, מצבי קצה, סינכרון הקבוצה.
6. הרצת כשלים — הפסקת חשמל, אובדן קשר, נעילה, התערבות ידנית וחזרה למצב עבודה.
7. מסירה והדרכת שירות התפעול — תיעוד, נוהל תחזוקה, ניתוח תקלות אופייניות.

מה מבררים בסקר

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

איך נראית הרצת הקבלה

הולכים לפי רשימת הבדיקות: כל תרחיש במצב אוטומטי וידני, השהיות, פקודות קבוצתיות, כשל ערוץ קשר, ניתוק חשמל וחזרה. את הקבלה חותמים על מנועים אמיתיים ובנוכחות מי שיתפעל את האתר.

מה מוסרים לידיים: קונפיגורציות, תרשימים, נהלים

מוסרים לא "אפליקציה", אלא ערכה שלפיה אפשר לפתח ולתחזק את המערכת בלעדינו. להלן — מה נשאר פיזית אצל המזמין במאגר ובמחזור המסמכים שלו.

• קונפיגורציית תרחישים: תיאור כל אוטומציה לפי סכימת "אירוע → תנאי → פעולה" — השכמה בוקר, תגובה לרוח, מצב "אין איש" — עם עדיפויות ופסקי זמן.
• תרשים האוטומציה: מיקום הבקרים, המנועים והחיישנים לפי חדרים עם כתובות. המתקין מוצא את הצומת לפי התרשים, בלי הגעת המפתח.
• מטריצת תפקידים והרשאות: מי ומה יכול — דייר, מנהל, מהנדס שירות.
• הוראות לדייר: להוסיף וילון, לשנות שם חדר, מה לעשות בעת אובדן קשר עם המנוע.
• תיעוד האפליקציה: בנייה, סביבות, סדר עדכונים וחזרה לגרסה קודמת.
• נוהל תחזוקה: תדירות בדיקות, קריטריוני כשל מנוע, סדר הסלמה.
• סדר הרחבה: איך להוסיף חדר או התקן, בלי לכתוב מחדש את ליבת התרחישים.

מטריצת תפקידים והרשאות גישה

התפקידים מחולקים לפי רמת סיכון: לדייר נגישים רק החדרים והתרחישים שלו, למנהל — מצבים קבוצתיים, למהנדס השירות — אבחון צמתים ויומני אירועים. ההרשאות מתוארות דקלרטיבית ונמצאות בקונפיגורציה, ולכן עובד חדש מקבל גישה בשינוי רשומה אחת, ולא בעריכת קוד.

נוהל תחזוקה ונקודת כניסה לשירות התפעול

בנוהל נקבעים תדירות הבדיקות, סימני הדרדרות המנוע וסדר ההסלמה: מי מקבל את הפנייה, תוך כמה זמן מגיב, אילו יומנים מצרף. נקודת כניסה אחת — שירות התפעול: לו מוסרים גישות וקשר להסלמה למהנדסים שלנו.

מקרה בוחן: אפליקציה לווילונות ותריסים במתחם מגורים

מה הראו המדידות לפני השינוי

האפליקציה הציבה משימה ישירות על בקרי הדירות: הפקודה יצאה לשירות חיצוני, חיכתה לאישור ורק אז הגיעה למנוע. בקשר לא יציב בחדר המדרגות חלק מהפקודות לא הגיעו בניסיון הראשון, והווילונות נשארו פתוחים בשליש. במדידות בשלושה מבנים שיעור הפקודות שפעלו בניסיון הראשון עמד על 78%.

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

הפניות לשירות התפעול הצטברו סביב שני תרחישים: וילונות שנתקעו באמצע המהלך, ותריסים בחדרים שאיש לא גר בהם. המוקדן לא ראה איזו פקודה הגיעה אחרונה.

מה השתנה לאחר העברת התהליך לאתר

את תהליך התרחישים העבירו לבקר המקומי ולאפיק KNX שהונח בתכנון המתחם. האפליקציה שולחת כוונה, ולא רצף פקודות: לוחות זמנים, חיישני תאורה ומפסקי קצה של המנוע מעובדים במקום, ולכן הווילונות משלימים את המהלך עד הסוף גם בעת אובדן קשר עם השרת החיצוני.

התגובה למחווה נחשבת מקומית: המסך מציג את התנועה מיד, למנוע יוצאת פקודה אחת עם המיקום הסופי, והחזרות נחתכות. שיעור הפקודות בניסיון הראשון עלה ל-99.6%, והתגובה הצטמצמה משניות לעשיריות שנייה. הבקר תופס פער במיקומי הקצה, מפסיק את התרחיש וכותב ליומן את הדירה, הערוץ והמיקום האחרון. זרם הפניות על וילונות תקועים ופתוחים למחצה ירד כמעט פי שישה, והשאר מטופלות לפי היומן בלי הגעה לאתר.

מה לעשות אם הבקר המקומי כבר מותקן?

בקר מותקן אינו מכשול ואינו סיבה להתחיל מאפס. תחילה מלאי: אילו קבוצות וילונות מחוברות, מה שולט בהן — ממסר בתוך הבקר הקיים או מודולים חיצוניים, היכן מאוחסנים התרחישים ולוחות הזמנים. מכך נגזר מה עובר לתהליך ומה נשאר על החומרה.

תאימות המנועים נבדקת לפי שיטת השליטה, ולא לפי המותג. מנוע עם כניסה דיסקרטית או מגע יבש נשאר במקום — השכבה החדשה שולחת את אותן פקודות כמו קודם. אפיק סגור של ספק גם אינו מבוי סתום: בינו לבין הבקר שמים גשר, והמנוע ממשיך לעבוד ברשת שלו.

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

לאחר מכן מעבירים קבוצות אחת אחת, החל מהפחות משמעותית. שבוע התבוננות לקבוצה מראה כיצד מתנהגים תרחישי הזריחה, מה קורה בעת אובדן קשר, האם מפסקי הקצה פועלים. אם ההתנהגות סוטה מהצפוי, הקבוצה חוזרת למעגל הקודם בהחלפה אחת.

הבקר הקיים נשאר מעגל שני: מפסקים ידניים ותרחישים מקומיים ממשיכים לעבוד. ההחלפה ההדרגתית מפסיקה להיות סיכון חד-פעמי — החזרה אורכת דקות ואינה פוגעת בקבוצות שכבר הועברו.

שאלות טכניות נפוצות: אינטגרציה, תפקידים, תמיכה

המזמין מגיע עם אתר עובד: בקר, מנועי וילונות ושלטים מותקנים, לוחות זמנים מוגדרים, ולא רוצים לשנותם. מכאן השאלות הראשונות — תאימות, הרשאות, עדכונים.

אנחנו בונים את האפליקציה כך שתהליך התרחישים חי בקונפיגורציה על השרת, והאפליקציה עצמה נשארת שלט. אפשר לשנות את התנהגות הווילונות בלי להוציא גרסה חדשה, והתפקידים וההרשאות אינם נכתבים מחדש בכל התקן.

איך מופרדות הרשאות המשתמשים?

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

מה קורה להגדרות לאחר עדכון האפליקציה?

תרחישים וקשרים נשמרים מחוץ לאפליקציה, ולכן העדכון אינו מוחק אותם. לפני הוצאה בודקים הגירת מבנה בין גרסאות ושומרים על אפשרות חזרה לבנייה הקודמת: אם הבדיקות לא עברו, המשתמשים נשארים בגרסה עובדת, והתמיכה באפליקציית המובייל מתנהלת לפי יומן השינויים.

נדון במשימה: מה צריך לדעת על האתר שלכם

דיוק הערכת פרויקט האוטומציה תלוי ישירות בנתוני המקור: ככל שפחות הנחות בהתחלה, כך נדירים יותר ההפתעות בשלב ההתקנה וההגדרה. להלן — מה שמסיר את רוב אי-הוודאות ומאפשר לחשב את היקף העבודות בלי "פחות-או-יותר".

• הרכב החדרים והאזורים: כמה חדרים, אילו נשלטים בנפרד, היכן כנפיים ברוחב לא סטנדרטי או משופעות.
• דגמי המנועים ושיטת השליטה — מגע יבש, אפיק או ערוץ רדיו: מכך נגזרת לוגיקת הפקודות באפליקציה.
• מה כבר מותקן באתר: בקר, שער, ספקי כוח, האם יש ממשק פתוח לאינטגרציה.
• תפקידי המשתמשים: בעלים, בני משפחה, אורחים, צוות תחזוקה — מי רואה מה ומה יכול לשנות.
• התנהגות בעת ניתוק קשר: הווילונות נשארים במקום, מגיעים למצב קצה או שומרים על הפקודה האחרונה.
• תרחישים: לוחות זמנים לפי זמן ושמש, פקודות קבוצתיות, סצנות ידניות, קישור לחיישני אור וטמפרטורה.
• מגבלות האתר: כיסוי קשר רדיו, גישה לרשת, דרישות לחיווט נסתר ונקודות התקנה.

עם הסט הזה אנחנו חוזרים עם הערכה ותוכנית עבודה: שלבים, הרכב האפליקציה, תרשים אינטגרציה עם הציוד. מסירת התיעוד — חלק ממסירת הפרויקט: תיאור פרוטוקול החלפה, הוראות למתקינים ולבעלים, סדר חיבור מנועים חדשים בלי להרכיב מחדש את האפליקציה. תארו את המשימה — נשווה את הנתונים ונציע פורמט עבודה.