TWB2BWebsite Design Case Demo

ISO 9001ULRoHS

+886-2-2907-1129 [email protected]

TWB2B 智慧鎖具 DemoSiteRequest for Quote
jintay-locks industrial-cabinet-2

What interfaces are available for integrating smart locks with access control systems?

The interfaces for integrating smart locks with access control systems are mainly divided into three layers: at the hardware layer, Wiegand, OSDP, and dry contact/relay are the primary options, with the lock sending card read results or door-open signals to the access control panel; at the communication layer, RS-485 and Ethernet form the backbone, with OSDP gradually replacing Wiegand as the mainstream for new projects; at the software layer, RESTful API, MQTT, or Webhook are used to exchange events and authorizations with cloud-based access control platforms. Before purchasing, you should first inventory the protocols supported by your existing access control panel, then decide which interface the lock should provide.

Key Takeaways

  • Three-Layer Integration Interface

    Smart lock and access control system integration is divided into three layers: hardware, communication, and software. The hardware layer primarily uses Wiegand, OSDP, and dry contacts; the communication layer uses RS-485 and Ethernet as the backbone; and the software layer exchanges data via RESTful API, MQTT, or Webhook.

  • OSDP Becoming Mainstream for New Projects

    OSDP runs over RS-485 and supports two-way communication and AES-128 encryption, gradually replacing Wiegand, which can be sniffed and cloned, and becoming the mainstream choice for new projects in Europe and the US.

  • Offline Fallback is Critical

    When the network is disconnected, the lock must use locally cached whitelists, NFC, RFID, or PIN codes as offline fallback. Events are stored locally and batch-uploaded once the network is restored, to avoid impacting operations.

  • Integration Testing in Three Phases

    Integration testing is recommended to be conducted in three phases: laboratory integration testing, field pilot, and pre-production acceptance. Test items should be clearly listed in the RFP to avoid additional requests later.

What outputs should the lock-side hardware interface provide?

What outputs should the lock-side hardware interface provide? This is the first question to clarify before integration, because access control panels only recognize a few standard signals, and if the lock does not match them, it cannot be read. The most common is Wiegand 26/34-bit output, used to transmit card or NFC identifiers to the panel; next is OSDP (Open Supervised Device Protocol) over RS-485, which supports two-way communication and encryption and is more commonly adopted in new projects in Europe and the US. For small doors such as cabinets and electrical distribution boxes, many integration projects still rely on dry contact or relay output, converting an "authorized" signal into a door-open pulse. When purchasing, you should confirm with the supplier the pin definitions for each output, cable length limits, and whether an external power module is required, and request wiring diagrams and signal timing diagrams to avoid discovering electrical specification mismatches during on-site installation.

How does a cloud-based access control platform communicate with the lock?

How does a cloud-based access control platform communicate with the lock? This determines whether remote card issuance, audit logs, and real-time alerts can be implemented. In practice, after the lock is equipped with a built-in cellular or Ethernet module, it pushes unlock events, status changes, and low-battery alerts to the cloud via MQTT or HTTPS; the access control platform then issues temporary authorizations, revokes blacklisted credentials, or queries historical records through RESTful APIs. If the access control system itself is already a SaaS architecture (for example, cloud versions from several international access control vendors), the integration focus shifts to API field mapping and permission levels rather than the underlying communication. Jintai Industrial's IoT smart lock platform supports Bluetooth, NFC, RFID, and cloud connectivity, and offers flexibility for integration with third-party access control platforms, but the specific API specifications, authentication methods, and data formats must be confirmed based on the actual integration project. Buyers should request API documentation, Postman examples, and a sandbox environment during evaluation, and agree on event field naming and timestamp formats.

industrial cabinet scene 1

How should the lock fall back when offline or disconnected?

How should the lock fall back when offline or disconnected? This is the most overlooked yet most critical issue in cabinet and distribution box scenarios. Network connectivity in server rooms or outdoor electrical boxes is not always stable, and if the cloud connection is interrupted, a lock that relies entirely on online authorization will fail to open, affecting maintenance operations. A well-designed smart lock will cache the most recently downloaded whitelist or time-based authorizations locally, and use NFC, RFID, or PIN codes as offline fallback; events are stored locally and batch-uploaded once the network is restored. Buyers should ask the supplier during the inquiry stage to explain: how many authorizations can be stored locally, the maximum tolerable disconnection time, the mechanism for backfilling data, and whether offline unlocking via mobile phone (through BLE preloaded authorizations) is supported. These details often determine whether the integration project can pass the owner's acceptance.

What security and compliance requirements must the integration interface meet?

What security and compliance requirements must the integration interface meet? This question directly affects the risk of data leakage and whether the project can pass security audits. The difference between OSDP and Wiegand is not just the number of wires; it also involves encryption: Wiegand signals can be intercepted and cloned, while OSDP v2 supports an AES-128 encrypted channel. Cloud APIs should adopt OAuth 2.0 or mTLS mutual authentication to avoid keys being hardcoded in firmware. For cabinet and distribution box projects targeting European and American markets, buyers also need to confirm whether the integration interface affects existing certifications (e.g., UL, CE, EN 50155), because adding a communication module may change EMC and electrical safety test results. Jintai Industrial's IoT platform offers Bluetooth, NFC, RFID, and cloud connectivity capabilities, but the specific certification scope and certificate numbers must be confirmed based on the actual product line and test reports, and cannot be inferred from claims alone. Buyers should request test reports for the corresponding product line from the supplier and ask them to clarify whether the integration interface falls within the certification scope.

Integration Testing and Acceptance Process

  1. 1

    Laboratory Integration Testing

    The lock and access control host complete basic processes such as wiring, card issuance, revocation, and event backfill at the supplier or system integrator's site.

  2. 2

    Field Pilot

    Select one or two actual cabinets or electrical boxes for installation, simulate real network and power conditions, and verify offline fallback and alert mechanisms.

  3. 3

    Pre-Production Acceptance

    Confirm that firmware versions, API versions, and documentation are complete, and proceed to mass production after passing FAT/SAT acceptance.

industrial cabinet scene 2

How should integration testing and acceptance be arranged?

How should integration testing and acceptance be arranged? This is the final mile in determining whether the project can go live on schedule. It is recommended to clearly define three phases in the purchase contract: first, Lab Integration Test, where the lock and access control host complete basic processes such as wiring, card issuance, revocation, and event reporting at the supplier's or system integrator's site; second, Pilot, where one or two actual cabinets or distribution boxes are installed to simulate real network and power conditions and verify offline fallback and alarm mechanisms; and finally, FAT/SAT before mass production, confirming firmware version, API version, and documentation completeness. Jintai Industrial's OEM/ODM process covers DFM design review, mold development, prototype verification, testing and certification, and mass production. Integration interface testing can be included in the prototype verification phase, but the specific test items, sample quantities, and schedule must be confirmed based on actual specifications. Buyers should list integration test items in the RFP to avoid additional requests later.

What integration documents should be requested from the supplier before purchase?

What integration documents should be requested from the supplier before purchase? This list determines whether subsequent integration can start smoothly. Required documents include: hardware interface wiring diagrams and signal timing diagrams, communication protocol specifications (Wiegand/OSDP/RS-485), API reference documentation and Postman examples, firmware update procedures and version compatibility matrix, offline authorization and event reporting mechanism descriptions, security and encryption mechanism descriptions, and integration test report templates. For industrial scenarios such as cabinets and distribution boxes, EMC and environmental test data should also be requested to confirm that the integration interface will not fail under harsh conditions. Jintai Industrial can provide relevant technical documents based on buyer needs, but the specific document list, versions, and delivery methods must be confirmed based on the actual project. After receiving the documents, buyers should conduct an internal review before deciding whether to proceed to the prototyping stage.

Six key evaluation items for smart lock and access control integration interfaces

  • Hardware output interface

    Confirm the pin definitions and electrical specifications for Wiegand, OSDP, dry contact, or relay outputs on the lock, and request wiring diagrams.

  • Communication protocol compatibility

    Review the protocols supported by existing access control hosts, and prioritize OSDP for encryption and two-way communication capabilities.

  • Cloud API and data format

    Request RESTful API or MQTT documentation from the supplier, and confirm event fields, timestamps, and authentication mechanisms.

  • Offline fallback mechanism

    Confirm whether the design for local authorization caching, offline unlocking, and event buffering during network disconnection meets the site's tolerance time.

  • Security and compliance

    Confirm interface encryption (OSDP Secure Channel, API OAuth/mTLS) and its impact on existing certifications.

  • Integration testing and documentation

    Require the supplier to provide test plans, samples, API sandbox, and version compatibility matrix to accelerate project acceptance.

FAQ

What hardware interfaces should the lock provide?

The most common hardware interface on the lock side is Wiegand 26/34-bit output, used to transmit card or NFC identifiers to the host. The next is OSDP over RS-485, which supports two-way communication and encryption. For small doors such as cabinets and electrical boxes, many integration projects still rely on dry contacts or relay outputs to convert 'authorized' into an open-door pulse.

How does a cloud access control platform communicate with the lock?

After the lock is equipped with a cellular or Ethernet module, it pushes unlock events, status changes, and low-battery alerts to the cloud via MQTT or HTTPS. The access control platform issues temporary authorizations, revokes blacklists, or queries historical records through RESTful APIs. If the access control system is already SaaS-based, the integration focus will be on API field mapping and permission levels.

How should the lock fallback when offline or disconnected?

A well-designed smart lock caches the latest downloaded whitelist or time-based authorizations locally, and uses NFC, RFID, or PIN codes as offline fallback. Events are stored locally and batch-uploaded once the network is restored. Buyers should confirm how many authorizations can be stored locally, the maximum tolerable offline duration, and the data backfill mechanism.

What security and compliance requirements should the integration interface meet?

OSDP v2 supports AES-128 encrypted channels, while Wiegand signals can be sniffed and cloned. Cloud APIs should adopt OAuth 2.0 or mTLS mutual authentication to avoid hardcoding keys in firmware. For European and US markets, it is also necessary to confirm whether the integration interface affects existing certifications such as UL, CE, EN 50155, as adding communication modules may change EMC and electrical safety test results.

What integration documents should be requested from suppliers before purchase?

Essential documents include hardware interface wiring diagrams and signal timing diagrams, communication protocol specifications, API reference documentation with Postman examples, firmware update procedures and version compatibility matrices, offline authorization and event backfill mechanism descriptions, security and encryption mechanism descriptions, and integration test report templates. For industrial scenarios, EMC and environmental test data should also be requested.

Need integration interface evaluation samples or API documentation?

Please provide your access control host model, integration scenario (cabinet/power distribution box/locker), and estimated quantity. We will provide corresponding technical documentation and evaluation samples based on actual specifications.

← What special requirements do power management locks for cabinets and distribution boxes have?