समस्या निवारण

Door & Gate Access की सबसे आम समस्याओं के लक्षण-आधारित समाधान। प्रत्येक प्रविष्टि लक्षण → कारण → समाधान के क्रम में है। किसी भी स्थिति या अस्वीकृति कारण के अर्थ के लिए संदर्भ देखें; अंतर्निहित निर्णय तर्क के लिए एक्सेस निर्णय कैसे काम करते हैं देखें।

एक्सेस लॉग से शुरुआत करें। लगभग हर "अंदर नहीं जा सकता" रिपोर्ट के लिए एक्सेस लॉग में सटीक कारण के साथ एक अस्वीकृत इवेंट होता है। सदस्य का नाम खोजें, सबसे हाल का अस्वीकृत इवेंट देखें, और नीचे संबंधित अनुभाग पर जाएँ।

कोई दरवाज़ा ऑफलाइन दिखता है

लक्षण: डोर कार्ड ऑफलाइन दिखाता है, सदस्यों को "Door offline" दिखता है, अनलॉक नहीं भेजे जा सकते।

कारण: डोर कंट्रोलर ने 5 मिनट से अधिक समय से रिपोर्ट नहीं किया है — डिवाइस पर बिजली या नेटवर्क बंद है।

समाधान:

1. जाँचें कि कंट्रोलर को बिजली मिल रही है और उसका नेटवर्क कनेक्शन (Ethernet केबल / Wi-Fi) ठीक है — हार्डवेयर समस्या निवारण पेज साइट पर की जाने वाली जाँचों (इंडिकेटर LED, PoE स्प्लिटर, केबलिंग, 4G मॉडल पर SIM/एंटीना) को कवर करता है।
2. Status (अंतिम बार देखा गया), IP address और अपटाइम देखने के लिए दरवाज़े का पैनल → Overview टैब खोलें — हाल का "अंतिम बार देखा गया" किसी खराब डिवाइस के बजाय रुक-रुक कर चलने वाले नेटवर्क का संकेत देता है।
3. आवश्यकता हो तो कंट्रोलर को पावर-साइकिल करें।
4. गहन निदान के लिए, Open in Device Management for advanced configuration का अनुसरण करें।
5. यदि कई दरवाज़े एक साथ ऑफलाइन हो गए हों, तो डिवाइसों के बजाय साइट के नेटवर्क/इंटरनेट पर संदेह करें।

जब कोई दरवाज़ा ऑफलाइन होता है, तो सदस्यों को अपने डैशबोर्ड पर सहायता संपर्क विवरण दिखते हैं (डिफ़ॉल्ट Smart मोड में), ताकि वे आपको कॉल कर सकें।

किसी सदस्य को अस्वीकार किया गया — "You don't have access to this door"

लक्षण: no_matching_policy_or_grant कारण वाला अस्वीकृत इवेंट।

कारण: किसी भी अतिरिक्त पथ ने उन्हें अनुमति नहीं दी: किसी भी सक्षम Access Policy में Who AND Where AND When का मिलान नहीं हुआ, और किसी भी स्थायी अनुदान या सक्रिय व्यवस्थापक/इंटीग्रेशन विंडो ने दरवाज़े को कवर नहीं किया।

समाधान:

1. Users में सदस्य को खोलें और व्यक्ति के प्रकार, सदस्यता स्थिति और सिंक किए गए/कस्टम टैग की तुलना पॉलिसी के Who से करें।
2. जाँचें कि Where में दरवाज़ा सीधे, किसी Access Scope के माध्यम से, या सुविधा के सभी दरवाज़ों के माध्यम से शामिल है, और कोई अपवर्जन उसे हटाता नहीं है।
3. When जाँचें: Anytime, या कम से कम एक सक्रिय Weekly/One-time विंडो। समाप्ति समय शामिल नहीं होता।
4. याद रखें कि पॉलिसी आपस में OR होती हैं, लेकिन प्रत्येक पॉलिसी के लिए Who AND Where AND When आवश्यक है। आंशिक मिलान कभी पहुँच नहीं देता।
5. यदि उपयुक्त हो, तो एक अलग स्थायी अनुदान या व्यवस्थापक विंडो का उपयोग करें; ये अतिरिक्त बने रहते हैं।

किसी सदस्य को अस्वीकार किया गया — "Your access has been suspended"

लक्षण: access_disabled कारण वाला अस्वीकृत इवेंट; उपयोगकर्ता पर Disabled बैज दिखता है।

कारण: उपयोगकर्ता की पहुँच बंद है। ऐसा मैन्युअल रूप से होता है (किसी व्यवस्थापक ने Access enabled बंद कर दिया) या स्वचालित रूप से (सदस्य को इंटीग्रेशन में हटा दिया गया और पैनल Removed by integration दिखाता है, या उन्हें सॉफ़्ट-डिलीट किया गया था)।

समाधान: उपयोगकर्ता को खोलें और Access enabled को फिर से चालू करें — या, यदि वे Removed by integration दिखाते हैं, तो उन्हें स्रोत सिस्टम में बहाल करें (या पंक्ति को डीकपल करें और मैन्युअल रूप से पहुँच सक्षम करें)।

कोई शेड्यूल की गई पॉलिसी पहुँच की अनुमति नहीं दे रही है

लक्षण: ऐप भविष्य की उपलब्धता दिखाता है या लॉग में outside_access_time_window है; कोई स्रोत विंडो Stale या Unmapped दिखती है; या पहुँच अप्रत्याशित समय पर बदलती है।

समाधान:

1. पुष्टि करें कि पॉलिसी सक्षम है।
2. उसके When शेड्यूल की जाँच करने से पहले उसी पॉलिसी के Who और Where जाँचें।
3. One-time विंडो के लिए, प्रयास की तुलना [from, to) से करें। प्रदर्शित टाइमज़ोन संग्रहीत क्षण को नहीं बदल सकता।
4. Weekly विंडो के लिए, उसका IANA टाइमज़ोन, स्थानीय सप्ताह का दिन/ब्लॉक, वैकल्पिक सक्रिय सीमाएँ और डेलाइट-सेविंग परिवर्तन जाँचें। समाप्ति समय शामिल नहीं होता और रात भर चलने वाले ब्लॉक को विभाजित करना आवश्यक है।
5. किस नामित पॉलिसी का मूल्यांकन हुआ, यह सत्यापित करने के लिए एक्सेस लॉग के policyId और policyName का उपयोग करें।
6. पुष्टि करें कि blockAllAccess, Force closed, उपयोगकर्ता का अक्षम होना, जियोफ़ेंस और कंट्रोलर की स्थिति प्राथमिकता नहीं ले रहे हैं।

किसी अलग इंटीग्रेशन विंडो के लिए, लॉजिकल स्कोप मैपिंग, स्रोत संशोधन, स्रोत की आयु और डिलीवरी की स्थिति भी सत्यापित करें। अज्ञात, अनमैप्ड या स्टेल स्रोत विंडो Access Policy या स्थायी-अनुदान पथों को हटाए बिना फ़ेल क्लोज़्ड होती हैं।

पुराने क्लाइंट Outside hours दिखा सकते हैं क्योंकि संगतता कारण outside_access_hours है; एक्सेस लॉग और नए क्लाइंट outside_access_time_window विवरण का उपयोग करते हैं।

जियोफ़ेंस अस्वीकृतियाँ — "Move closer" और इसी तरह की अन्य

लक्षण: outside_geofence, gps_too_imprecise या location_unavailable कारणों वाले अस्वीकृत इवेंट।

अस्वीकृत इवेंट का विवरण डायलॉग रिपोर्ट किए गए निर्देशांक, सटीकता और दूरी दिखाता है — यह आँकने के लिए अमूल्य है कि सदस्य वास्तव में साइट पर था या नहीं।

अनलॉक भेजा गया लेकिन दरवाज़ा नहीं खुला (Timed out / Failed)

लक्षण: इवेंट Confirmed unlocked के बजाय Timed out या Failed पर समाप्त होते हैं।

कारण: कमांड सर्वर तक पहुँच गया लेकिन कंट्रोलर ने पुष्टि नहीं की — दरवाज़े पर अस्थिर कनेक्टिविटी, या डिवाइस में खराबी।

समाधान:

1. दरवाज़े की ऑनलाइन स्थिति और डिवाइस जानकारी (Overview टैब) जाँचें। एक ही दरवाज़े पर बार-बार टाइमआउट उसके नेटवर्क की ओर इशारा करते हैं।
2. दरवाज़े को देखते हुए पैनल से व्यवस्थापक के रूप में Unlock door आज़माएँ।
3. यह पुष्टि करने के लिए कि आप भौतिक रूप से सही कंट्रोलर पर हैं, Identify device (तीन बीप) का उपयोग करें।
4. यदि रिले क्लिक करता है लेकिन दरवाज़ा नहीं खुलता, तो खराबी लॉक सर्किट में है — हार्डवेयर समस्या निवारण में जंपर और मल्टीमीटर परीक्षण चलाएँ।
5. यदि डिवाइस ऑनलाइन है लेकिन सक्रिय नहीं हो रहा, तो डिवाइस प्रबंधन निदान के माध्यम से एस्केलेट करें।

Maintenance mode भी जाँचें — Force closed पर सेट दरवाज़ा डिज़ाइन के अनुसार सदस्यों के लिए लॉक रहता है। Block all access at this door स्पष्ट blockAllAccess सेट करता है और हर सदस्य पॉलिसी, स्थायी अनुदान और Access Time Window को अस्वीकार करता है।

यदि कंट्रोलर ऑनलाइन है लेकिन सामान्य रूप से प्रतिक्रिया देना बंद कर देता है, तो Remotely reboot device (दरवाज़े का पैनल → Configuration → Advanced) उसे पुनः आरंभ करता है। दरवाज़ा अपनी वर्तमान लॉक स्थिति बनाए रखता है और बूट होते समय एक-दो मिनट के लिए ऑफलाइन रहता है।

सदस्य ऐप में साइन इन नहीं कर पा रहा

लक्षण: Send code चरण पर "No record found"।

कारण: उनके द्वारा टाइप किया गया फ़ोन/ईमेल किसी भी Users रिकॉर्ड से मेल नहीं खाता।

समाधान: Users में उनकी पंक्ति खोजें और पहचानकर्ताओं की सटीक तुलना करें — अलग नंबर प्रारूप, पुराना ईमेल, या अनुपलब्ध पहचानकर्ता इसके सामान्य कारण होते हैं। पंक्ति अपडेट करें (या सदस्य से रिकॉर्ड में दर्ज पहचानकर्ता का उपयोग करवाएँ)। याद रखें कि प्रत्येक पंक्ति में फ़ोन/ईमेल में से कम से कम एक आवश्यक है।

लक्षण: "Too many attempts."

कारण: दर सीमा — प्रति संपर्क प्रति घंटे 5 कोड अनुरोध, साथ ही एक नेटवर्क-स्तरीय सीमा।

समाधान: प्रतीक्षा करें; प्रति-संपर्क सीमा एक सुरक्षा उपाय है और इसे हटाया नहीं जा सकता।

आमंत्रण संबंधी समस्याएँ

आमंत्रण → समस्या निवारण में समर्पित तालिका देखें। त्वरित बिंदु: Send failed → पता जाँचें और फिर से भेजें; बल्क भेजने में शामिल नहीं → उन्हें पहले ही आमंत्रित किया जा चुका है, वे ऐप का उपयोग कर चुके हैं, उनके पास ईमेल नहीं है, या उनके पास पहुँच नहीं है।

सिंक किए गए उपयोगकर्ता अनुपलब्ध या पुराने हैं

लक्षण: कोई व्यक्ति आपके सदस्य सिस्टम में मौजूद है लेकिन Users में नहीं; या उसका विवरण पुराना है।

समाधान:

1. Settings → Sync settings जाँचें — क्या स्रोत सक्षम है? क्या विशिष्ट इंटीग्रेशन सक्षम है? यदि कार्ड N removals held back for review दिखाता है, तो एक बड़ा हटाना व्यवस्थापक की समीक्षा की प्रतीक्षा कर रहा है।
2. Sync activity & troubleshooting का विस्तार करें और व्यक्ति को खोजें — छोड़े जाने का कारण आपको ठीक-ठीक बताता है कि क्यों (अनुपलब्ध पहचानकर्ता, डीकपल्ड, इंटीग्रेशन बंद, आदि)। छोड़े जाने के कारणों की तालिका देखें।
3. उपयोगकर्ता का Track source updates टॉगल जाँचें — डीकपल्ड पंक्ति कभी स्रोत से अपडेट नहीं होती।
4. यदि पंक्ति Not synced – duplicate दिखाती है, तो कोई अन्य रिकॉर्ड वही ईमेल या फ़ोन साझा करता है। डुप्लिकेट समाधान देखें।
5. दैनिक पूर्ण सिंक की प्रतीक्षा करने के बजाय पास को ज़बरदस्ती चलाने के लिए Sync now का उपयोग करें।
6. Access Time Windows के लिए, स्रोत की आयु, संशोधन परिणाम (updated/idempotent/stale/conflict) और scope_key मैपिंग भी जाँचें। विफल फ़ेच को पिछले स्नैपशॉट को साफ़ करने के बजाय अपरिवर्तित छोड़ना चाहिए।

ऑटो-अनलॉक शेड्यूल दरवाज़ा नहीं खोल रहा

लक्षण: दरवाज़ा अपनी शेड्यूल की गई अवधि के दौरान खुला नहीं रहता।

समाधान:

1. दरवाज़े का Schedule टैब खोलें और पुष्टि करें कि Auto-unlock चालू है। दरवाज़ा कब अनलॉक होना चाहिए, यह देखने के लिए Next 14 days पूर्वावलोकन जाँचें।
2. सुविधा में स्टाफ़ उपस्थिति के घंटे के साथ, सुविधा और सिस्टम कॉन्फ़िगरेशन में सुविधा के स्टाफ़ उपस्थिति और अवकाश के घंटे जाँचें। सार्वजनिक अवकाश पर, On public holidays तय करता है कि दरवाज़ा अवकाश के घंटों का पालन करे, लॉक रहे या अवकाश को अनदेखा करे।
3. Custom schedule के साथ, जाँचें कि उस दिन वास्तव में कोई समय ब्लॉक है।
4. जाँचें कि क्या स्टाफ़ ने Lock now का उपयोग किया: कार्ड Locked by staff until HH:MM दिखाता है। Resume schedule शेड्यूल को वापस लागू करता है।
5. याद रखें कि शेड्यूल में बदलाव केवल सहेजने के बाद लागू होते हैं, जिससे कंट्रोलर फिर से लोड होता है (आमतौर पर 10–15 सेकंड)।
6. Maintenance mode को प्राथमिकता मिलती है — Force closed पर सेट दरवाज़ा अपने आप नहीं खुलेगा।
7. समय सुविधा के टाइमज़ोन में होते हैं — यदि विंडो अजीब समय पर सक्रिय होती हैं, तो सुविधा की टाइमज़ोन सेटिंग सत्यापित करें।

किसी व्यवस्थापक ने सेटिंग्स बदलीं लेकिन कुछ नहीं हुआ

लक्षण: पॉलिसी/जियोफ़ेंस/संदेश संपादित किए गए लेकिन कोई प्रभाव नहीं पड़ा।

कारण: Settings-टैब के बदलाव तब तक लागू नहीं होते जब तक सेव बार में Save changes पर क्लिक न किया जाए; पेज से हटने पर उन्हें त्यागने का विकल्प दिया जाता है।

समाधान: फिर से लागू करें और सहेजें। पॉलिसी और जियोफ़ेंस बदलाव बाद के प्राधिकरण प्रयासों में उपयोग किए जाते हैं; ऐप-साइड सेटिंग्स तब दिखती हैं जब सदस्यों के ऐप अगली बार रीफ़्रेश होते हैं।

संबंधित पेज

• हार्डवेयर समस्या निवारण — बिजली, रिले और लॉक वायरिंग निदान
• एक्सेस लॉग
• Access Policy शेड्यूल
• संदर्भ — सभी अस्वीकृति कारण और डिफ़ॉल्ट
• सामान्य प्रश्न