An automatic-door integration can request opening, report a physical position or provide a technician's configuration connection. Those are different functions. Define the equipment, signal direction, operating conditions and feedback source before calling a connection compatible. A platform acknowledgement is not evidence that the door has opened.
Start with the requested function
An office may want credential-based entry, a facilities team may need closed-position information, and a home-automation scene may respond to a door opening. A single requirement called “smart integration” does not define all three.
For example, an application may show success while the door remains stationary. Success might mean that the request was accepted or an intermediary module acted. Unless the source and meaning of the response are defined, the application should not label that event as the door being physically open.
Record the request, receipt, movement and feedback as separate events, connected by entrance ID and time. State who may initiate a request and which party is responsible for each piece of equipment. These are specification questions, not assumptions about a particular installed control.
| Function or information | Definition needed | Common misunderstanding |
|---|---|---|
| Opening request | Source, destination and meaning of the request | A sent request displayed as an open door |
| Physical position | Identified source and the state it represents | Platform connectivity treated as door position |
| Operating mode | Actual equipment mode and evidence source | A platform label treated as a confirmed door mode |
| Fault or protection status | Device, indication, origin and update time | Network loss confused with an equipment fault |
| Technician configuration | Tool, personnel, supported equipment and version | A service connection treated as daily remote control |
Define direction before discussing terminals or protocols
The interface record needs the complete equipment and module identities, versions, signal direction, input conditions, output meaning, timing and applicable drawings. Describe direction relative to the named equipment. A label such as relay or digital interface does not identify an opening input, a status output or a different function.
A capability on one platform does not establish the corresponding capability at the door. Similar connectors or transmission arrangements do not prove a shared protocol. Communication integration needs the actual control and gateway documents, supported functions, versions and error-handling agreement. Do not invent register addresses or serial settings to fill a documentation gap.
Qualified technical personnel should confirm and implement the connection from both sides' applicable documents. This guide provides no terminal, grounding, bypass or trial-wiring instructions, and claims no universal consumer-platform compatibility for Record doors.
The same request needs its operating conditions
Equipment mode, locking and configuration can affect behaviour. The official System 20 manual 102-020110469, V2.7, sections 6.7–6.8 on PDF page 30, expressly distinguishes conditions for optional emergency functions and battery arrangements. It supplies a specific reason to preserve mode and configuration when describing a function.
That source does not apply automatically to Leo II, every swing door or another installed system. It is cited here to demonstrate why state conditions belong in a requirement, not to prescribe a universal control priority. Obtain the actual equipment and project response for normal management, alarms, loss of power and restoration separately.
Software integration does not replace physical protective devices or site emergency arrangements. Repeated remote requests are not a way to overcome a protection fault or a system awaiting inspection. Manage the entrance under site procedures and keep people out of hazardous movement areas.
i-Record and WiDI address a technician's task
The official i-Record product page describes configuration, commissioning and diagnostics by authorised technicians using a Bluetooth adapter called WiDI. It lists supported equipment and software conditions, including a version condition for DFA 127. A phone connection therefore has a defined purpose, hardware and equipment scope.
It does not establish a consumer smart-home gateway, an open cloud interface or unrestricted long-term remote operation. If a technician's phone connects while a building platform cannot, first determine whether the two connections are intended to perform the same function.
The System 20 brochure dated 11/2016, number 102–099.926, lists FEM as a functionality-extension option on page 16. That historical category entry does not identify the current supplied module, network protocol or platform compatibility. The proposed equipment and function need their own confirmation.
Specify stale information, communication loss and recovery
An integration drawing often shows only normal communications. The project also needs a definition for unavailable feedback, old values, unresolved requests and restoration. There is no single response prescribed here for every door or platform.
Show the source time and validity of a displayed state. A previous closed-position record should not silently remain a claim about the present position after its agreed validity expires. Distinguish communication loss, information not updated and an identified equipment fault. The project determines the time limits and management response.
Where remote requests are permitted, define permissions, maintenance responsibility and how the business function is withdrawn or handed over. Keep credentials and access keys out of public articles, equipment photographs and ordinary handover worksheets. The original worksheet provided here does not collect them.
Record evidence by condition
Agree the expected result before responsible personnel organise verification under the applicable plan. A useful record can say not tested, awaiting coordination or not conforming. A platform going live cannot close every equipment and site condition.
| Condition to define | Parties confirming the expectation | Evidence to retain |
|---|---|---|
| Normal authorised request | Equipment, platform and site management | Request, receipt, actual movement and feedback |
| Locked or other operating mode | Equipment and project representatives | Actual mode, applicable documents and required response |
| Missing or stale state source | Platform and site management | Source time, displayed meaning and handling |
| Network loss and recovery | Both technical teams and management | Unresolved requests, restoration conditions and results |
| Maintenance or protection fault | Site and equipment representatives | Management arrangements and conditions for use |
| Alarm or power transition | Responsible project disciplines | Applicable requirements, plan and corresponding records |
This is a record framework, not a live test, unlocking or safety-function procedure. Relevant site work requires the appropriate personnel, coordination and equipment documents.
Preserve the boundary during retrofit and fault diagnosis
For an existing entrance, identify the equipment, controls, locks, activation and protective devices, then list what will change and what is to remain. A gateway change can affect a signal path or operating logic; identify the affected condition and the checks required.
If the integration does not work, collect the request time, entrance ID, platform response, intermediary information, actual mode and observed door behaviour. Separate what is known at the platform, gateway, equipment reception, movement and feedback stages. Do not diagnose a failed board or sensor from one success message, or use another model's wiring and code table by trial and error.
Download the original interface requirements and verification worksheet (CSV). It is a blank communication aid, not an official protocol, wiring diagram or compatibility certificate. Itemise equipment, modules, platform work, cabling, verification, documents and subsequent support. Identify responsibility for a later equipment or platform change.
General component identity, door safety evidence and international enquiry responsibilities have separate guides.
Source scope and business contact
Reviewed on 2026-11-02: the official Record i-Record product page; System 20 user manual 102-020110469 V2.7, sections 6.7–6.8; and System 20 brochure 11/2016, 102–099.926, functionality-extension option. Each has a particular equipment, version and purpose scope. None supplies complete compatibility evidence for an unspecified consumer platform and installed door.
Business enquiries: 河南联同创智能科技有限公司, Mr Wang, +86 13271597000. Confirmed business address: 河南省郑州市新郑市龙湖镇华南城11A1-16号. The authorisation image on the Chinese homepage states 2026-06-01 to 2026-12-31; confirm the actual product, interface, territory and supply or site-work scope for the enquiry. It does not establish overseas infrastructure or a project compatibility result.
Frequently asked questions
Does an opening acknowledgement prove that the door is open?
No. Identify which stage acknowledged the request. Request transmission, intermediary action, equipment receipt and actual door position need separate definitions, with a source and time for the feedback.
Does a relay or dry contact prove compatibility with any platform?
No. Match the actual equipment and versions, signal direction, conditions and meaning against both parties' documents. Qualified personnel must confirm and implement the connection rather than trying similar terminals.
Can a generic register map control any communication-capable door?
No. Obtain the actual control, gateway and function documentation, including protocol, supported operations, versions and errors. Leave compatibility unconfirmed when that evidence is missing.
Does i-Record prove consumer smart-home remote-control support?
No. Record describes i-Record with WiDI as a technician's configuration and diagnostic tool with equipment and version conditions. It does not replace evidence for an everyday business interface or consumer platform.
Can the display keep the last known state during network loss?
The display must make the source time and validity clear so that an old record is not mistaken for the present physical position. Define and verify unavailable data, faults and recovery handling for the project.
Should a door that ignores a platform request receive a new control board?
First record the request, platform and intermediary responses, equipment mode and physical observations, then investigate the relevant stages. Do not infer a failed part from one message or repeatedly request movement to overcome a fault.
For reference only. Refer to the manufacturer's official information for product data.
内容仅供参考，以官网数据为准