Access control systems are available in standalone and networked versions. Different manufacturers use two methods for hardware and system integration: middleware and direct connection. Direct connections commonly use HTTP and MQTT protocols, each with its own advantages and disadvantages. Cyberos access control hardware supports both methods, allowing users to choose according to their needs.
Text:
Access control all-in-one machines are generally categorized into standalone and network versions based on whether they are connected to the network. Standalone systems are used without a network connection and are typically used in small numbers (usually one or two units or a few users). The required access control functions are simple, and permission management is generally done only on the device itself.
Network versions, on the other hand, are typically used for larger numbers of devices, more users, and more complex functions. Using a network version involves an access control management system installed on a computer or server, responsible for the unified management of devices, users, and permissions.
In today's globalized world, with diverse user demands, it is extremely difficult and time-consuming for a single company to develop all its access control hardware and management systems in-house. This inevitably leads to the need for interoperability between hardware and access control management systems from different manufacturers.
The integration of hardware from different manufacturers with access control system platforms generally falls into two categories based on the connection method: using middleware and direct hardware-to-platform connection. The middleware approach typically involves the hardware manufacturer designing software (or a simplified system), with the connection structure being hardware <=====> middleware <=====> access control system platform. As the diagram, the middleware acts as a bridge between the hardware and the platform, and all data interaction relies on the middleware for data forwarding. Overall stability is affected by the middleware, and as we all know, in many systems, adding another node will decrease stability by about 10%.
Another connection method is hardware connection directly, i.e., hardware <=====> access control system platform. This method is more direct, requires fewer nodes, is more stable, and has higher security (no worries about middleware intercepting data). If like this, communication uses HTTP and MQTT between the hardware and the platform commonly.
HTTP Mode: Hypertext Transfer Protocol, it is a stateless, application-layer protocol based on a request-response model.
Working Principle: The user initiates the request, and the server responds passively. Each interaction requires the users (such as a mobile app or management system) to establish a TCP connection to the server firstly, sending a formatted request (such as GET/POST/PUT, URL, headers, and body). After processing the request, the server returns a response (including status codes such as 200/404, head, and body), and the connection is usually closed afterward.
MQTT Mode: Message Queuing Telemetry Transport, is a lightweight messaging protocol designed for the Internet of Things (IoT) based on a publish-subscribe model.
Working Principle: As it is an MQTT broker server. Devices or applications, acting as clients, first establish a long-lived connection with the broker. Publish/Subscribe: Clients do not communicate directly but through topics. Clients can subscribe to topics they are like (such as door/access/event). When another client publishes a message to that topic, the broker server is responsible for pushing the message to all clients subscribed to that topic.
Comparatively, HTTP is simpler, easier to develop and integrate, more efficient. And theoretically it is more stable due to the absence of proxy servers. But it has an inherent disadvantage: the client (access control hardware) must initiate a request and the server must respond each time. If the server needs to actively send commands to the device (access control hardware), it can only use a hardware polling method, requesting the server at regular intervals (e.g., every 3 seconds). It will be additional resource waste and increases server load if there are many devices.
In the project, how should you choose between HTTP and MQTT communication for access control with QR code? For the ticket checking, and access verifications, where the server rarely needs to actively send commands to the hardware, HTTP is generally recommended. However, if the server frequently needs to send commands to the hardware (such as frequently performing remote door openings or modifying hardware parameters), MQTT is recommended.
All Cyberoce access control hardware supports both HTTP and MQTT, the users can choose freely.
