Method for distinguishing equipment docking error boundary

Abstract

The invention provides a method for distinguishing equipment docking error boundaries, and relates to the technical field of the Internet of Things, and the method comprises the steps that a client sends a call request for a specified device to a server according to a business demand, and the client presets information and parameters required by different devices; the client receives the request returned from the server, and analyzes and processes different equipment types and message protocols in the request by adopting different filtering mechanisms through a filter arranged on the client; the characteristics and requirements of the equipment types are in one-to-one correspondence with filtering mechanisms; the specification and the requirement of the message protocol are in one-to-one correspondence with the filtering mechanism; and if the client recognizes that the information and parameters of the device do not conform to the predefined information and parameters of the device, processing the request, analyzing the cause of an error, and returning a corresponding prompt, and if no error information is recognized, normally calling the device to complete the device docking operation.

Description

Technical Field

[0001] The present application belongs to the technical field of Internet of Things, and specifically relates to a method for distinguishing device docking error boundaries. Background Art

[0002] Currently, the Internet of Things is driving the transformation of human society from "informatization" to "intelligence", promoting tremendous changes in information technology and industry, and has a series of advantages such as efficient resource utilization, minimizing manpower, saving time, enhancing data collection, and improving security. In this process, device docking technology has become crucial in the application of the Internet of Things.

[0003] When connecting devices in the Internet of Things, it mainly depends on the basic application of the device's own characteristics and related protocols. For example, for different types of devices (such as card readers, barcode printers, weighing scales, cameras, etc.), the connection operation is carried out according to their respective connection methods and parameter settings; for different communication protocols (such as MQTT, WebSocket, etc.), data transmission and connection establishment are carried out according to protocol specifications.

[0004] The inventors have found that different devices have different characteristics and different docking methods. The same model of devices has different parameters and different applicable scenarios. Every time a problem occurs when calling a device, it not only takes a lot of time to troubleshoot, but also causes business interruptions and affects work efficiency. When problems occur in device docking, the existing technology lacks an effective error boundary division and prompt mechanism, making it difficult to quickly and accurately locate the problem, increasing the difficulty and time cost of troubleshooting. With the diversification of IoT applications, the compatibility requirements for different protocols are getting higher and higher. When facing the mixed use of multiple protocols or protocol upgrades, the existing technology may have compatibility issues, affecting the normal docking and data transmission of the device. Summary of the invention

[0005] The present application provides a method for distinguishing device docking error boundaries to solve the technical problems in the prior art of complex and error-prone device docking, difficulty in error location, and insufficient protocol compatibility.

[0006] The technical solution adopted in this application is:

[0007] The present application embodiment provides a method for distinguishing device docking error boundaries, including:

[0008] The client sends a call request for a specified device to the server according to business requirements, and the client pre-sets the information and parameters required by different devices;

[0009] The client receives the request returned from the server, and uses different filtering mechanisms to analyze and process different device types and message protocols in the request through filters set on the client; the characteristics and requirements of the device types correspond to the filtering mechanisms one by one; the specifications and requirements of the message protocols correspond to the filtering mechanisms one by one;

[0010] If the client identifies information and parameters that do not conform to the pre-defined device, the request is processed, the cause of the error is analyzed, and a corresponding prompt is returned. If no error information is identified, the device is called normally to complete the device docking operation.

[0011] According to an embodiment of the present application, the client receives a request returned from the server, and uses a filter set on the client to analyze and process different device types and message protocols in the request using different filtering mechanisms, specifically:

[0012] Filter analysis for different device types includes: card reader request, barcode printer request, LED request, weighbridge request, license plate recognition request, and camera image loading request;

[0013] The filtering analysis of different message protocols includes: mqtt protocol communication requests and websocket protocol communication requests.

[0014] According to an embodiment of the present application, the card reader request is specifically:

[0015] Detect the connected USB device and verify it according to the pid and vid of the device model;

[0016] If the supported device model is not detected, a prompt indicating that the supported device is not detected is returned;

[0017] If a supported device model is detected, the relevant card reader interface provided by the manufacturer is called. If the interface call sends an error, the error information is returned according to the relevant error code.

[0018] According to one embodiment of the present application, the barcode printer request is specifically:

[0019] Detect the connected USB device and verify it according to the pid and vid of the device model;

[0020] If the supported device model is not detected, a prompt indicating that the supported device is not detected is returned;

[0021] If a supported device model is detected, the device is connected. If the device cannot be connected successfully, the prompt "Failed to open the printer" is returned. Please check the device connection prompt. If the device is successfully connected, the relevant printing interface is called. If an error occurs during the interface calling process, a prompt is generated according to the relevant error code.

[0022] According to an embodiment of the present application, the LED request is specifically:

[0023] Initiate device connection based on the maintained device IP and port information. If the device cannot be successfully connected, a relevant error message will be returned.

[0024] If the device is successfully connected, the relevant device parameters in the request will be verified. If there is a problem with the parameter verification, relevant prompts will be given according to the verification error information; if no problem is found in the parameter verification, the relevant SDK interface that sends data to the LED will be called. If an error occurs during the call, a corresponding prompt will be given according to the error code.

[0025] According to an embodiment of the present application, the weighbridge request is specifically:

[0026] Check whether the scale serial port can be opened normally according to the maintained serial port number, baud rate and data bit parameters. If the opening fails, it will return a prompt that the serial port does not exist or is occupied.

[0027] If it is opened normally, the relevant serial port data will be read and analyzed. If an error occurs during the analysis, the corresponding prompt will be returned according to the error.

[0028] According to an embodiment of the present application, the license plate recognition request is specifically:

[0029] Use the configured camera username, password, and IP address to log in. If the login fails, a prompt indicating that the camera opening failed will be returned.

[0030] If the camera is successfully opened, the license plate recognition interface is called for recognition. If recognition fails, the interface returns an error code with relevant prompts.

[0031] According to an embodiment of the present application, the camera image loading request is specifically:

[0032] The return message of the preview command sent to the device is classified into: the channel is offline, please check the device status;

[0033] The preview command succeeded but the device did not respond. Please check the device or network.

[0034] Check if the streaming service starts prompting.

[0035] According to an embodiment of the present application, the MQTT protocol communication request is specifically: verifying the connection to determine whether the corresponding MQTT channel can be connected normally, and returning a prompt of related connection failure if the connection fails;

[0036] If the connection is successful, the relevant interface will be called to send a message to the device, and the time of sending the message will be recorded. If the relevant device data message is not received within the specified time, a prompt of return message timeout will be generated;

[0037] If the return message is successfully received, authentication will be performed based on the returned token. If authentication fails, it means that the identity authentication has not been passed and a prompt related to authentication failure will be returned;

[0038] If the authentication is successful, the returned message content will be classified into errors and prompts will be generated, and relevant operations will be performed according to different device types;

[0039] According to an embodiment of the present application, the websocket protocol communication request specifically includes: checking whether there is a successfully established websocket connection, and if not, generating a related prompt that the websocket does not exist;

[0040] If there is a connection, relevant device calls will be made, and specific connection error prompts will be divided and generated according to the device type and specific error information.

[0041] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows:

[0042] This application can accurately identify and process requests by pre-setting device information and parameters, and adopting corresponding filtering mechanisms, thereby improving device docking efficiency, reducing business interruption time, and ensuring smooth operation processes. When a situation does not meet the definition, the cause can be analyzed and a prompt can be returned, which helps to quickly locate the error. Whether it is a device type mismatch or a message protocol problem, it can be accurately checked, saving troubleshooting time and costs. It supports a variety of device types and message protocols to meet the needs of different business scenarios, such as card readers, barcode printers, weighing scales and other devices involved in the Internet of Things, as well as the application of mqtt and websocket protocols. Users can get error prompts in a timely manner, understand the problem, and take corresponding measures. At the same time, the smooth completion of normal docking operations also ensures the convenience and stability of device use. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0044] Figure 1A flowchart of a method for distinguishing device docking error boundaries provided in an embodiment of the present application. DETAILED DESCRIPTION

[0045] In order to more clearly illustrate the overall concept of the present application, a detailed description is given below in an illustrative manner in conjunction with the accompanying drawings.

[0046] In the following description, many specific details are set forth to facilitate a full understanding of the present application. However, the present application may also be implemented in other ways different from those described herein. Therefore, the protection scope of the present application is not limited by the specific embodiments disclosed below. It should be noted that the embodiments of the present application and the features in each embodiment may be combined with each other without conflict.

[0047] In the present application, unless otherwise clearly specified and limited, a first feature "above" or "below" a second feature may be that the first and second features are in direct contact, or the first and second features are in indirect contact through an intermediate medium. In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in an appropriate manner in any one or more embodiments or examples.

[0048] Example 1

[0049] like Figure 1 As shown, a method for distinguishing device docking error boundaries is characterized by comprising:

[0050] The client sends a call request for a specified device to the server according to business requirements, and the client pre-sets information and parameters required by different devices.

[0051] Specifically, the client sends a call request

[0052] Business demand driven: The client sends a call request for a specific device to the server based on the actual business scenario and demand. For example, in the Sinograin technical prevention and control pilot project, there may be a business demand for the card reader to read relevant data for personnel or material management, so a call request for the card reader will be sent; or if there is a business demand for loading camera images for monitoring a certain area, a corresponding camera image loading request will be sent.

[0053] For specific devices: These requests are specifically for a specific device. This includes card readers, barcode printers, LEDs, weighbridges, license plate recognition devices, cameras, and many other types of devices. Different business processes and operations require different devices to complete the corresponding functions, so the client must accurately send requests for these specific devices to the server.

[0054] The client pre-sets device information and parameters

[0055] Importance of device information and parameters: The client needs to pre-set the information and parameters required by different devices in order to correctly connect and interact with the devices in the future. These information and parameters are the key basis for the normal operation of the device and whether the device connection is correct.

[0056] Information and parameter examples for different devices

[0057] Card reader and barcode printer (USB device): You need to know the pid and vid information of the device model so that you can verify it when detecting the connected device.

[0058] Weighbridge: Maintain parameters such as serial port number, baud rate, data bit, etc. to check whether the serial port of the weighbridge can be opened normally and for subsequent data reading and parsing.

[0059] Camera-related (license plate recognition, camera image loading): User name, password, IP and other information need to be configured to log in and operate the camera device.

[0060] LED: The device IP, port and other information need to be maintained in order to initiate device connection and subsequent parameter verification operations.

[0061] For example, the client sends a call request

[0062] Card reader request: In some business scenarios that require identity authentication or data reading, such as reading employee cards or material tags in enterprise access control systems or material management systems, the client will send a call request for the card reader to the server.

[0063] Barcode printer request: In warehousing and logistics scenarios, when goods barcodes need to be printed, the client sends a call request for the barcode printer to the server based on business needs.

[0064] LED request: For example, in some intelligent lighting system control scenarios, if you need to control the switch or brightness of LED lights in a specific area, the client will send a call request for the LED.

[0065] Weighbridge request: When measuring the weight of goods in grain storage or logistics transportation, the client will send a request to call the weighbridge to the server.

[0066] License plate recognition request: In parking lot management or traffic monitoring systems, in order to obtain vehicle information, the client will send a call request for the license plate recognition device (usually involving camera-related operations) to the server according to business needs.

[0067] Camera image loading request: In a security monitoring system, when you need to view the real-time image of a certain area, the client will send a request to load the camera image to the server.

[0068] The client pre-sets device information and parameters

[0069] Card reader and barcode printer (USB device): Take the card reader used by a certain enterprise as an example. The pid of the device model may be 1234 and the vid may be 5678. The client pre-sets this information for verification when detecting the access device. For a barcode printer, its pid and vid may be 9876 and 4321 respectively. The client uses this information to identify whether the access device is correct.

[0070] Weighing scale: In the pilot project of Sinograin's technical prevention and control, the serial port number of the weighing scale may be COM1, the baud rate is 9600, and the data bit is 8. The client sets these parameters in advance to check whether the serial port of the weighing scale can be opened normally and the subsequent data reading and parsing can be carried out.

[0071] Camera-related (license plate recognition, camera image loading): In a parking management system, the camera used for license plate recognition is pre-configured by the client with the username "admin", password "123456", and IP address "192.168.1.100". Similar configuration information is also required for the device that loads the camera image to ensure that it can log in and obtain the image correctly.

[0072] LED: Assume that in a smart lighting system, the IP address of the LED device in a certain area is "192.168.2.200" and the port is 8080. The client maintains this information in advance to initiate device connection and subsequent parameter verification operations.

[0073] Furthermore, a device information database can be established to centrally manage and store various parameters of different devices for easy query and update. For example, in addition to the existing information such as the serial port number and baud rate of the scale, the user name and password of the camera, more detailed information such as the model, production date, maintenance record, etc. of the device can also be stored to better understand the status and history of the device, and provide more comprehensive data support for subsequent docking and troubleshooting.

[0074] Furthermore, you can also set a request priority queue. According to the urgency and importance of the business, set priorities for call requests of different devices. For example, for some devices involved in key business processes (such as camera devices in some real-time monitoring scenarios), their call requests can be set to high priority to ensure timely processing and improve the overall response efficiency of the system.

[0075] Furthermore, the security verification mechanism for requests can be strengthened. In addition to the existing verification of device connections (such as PID and VID verification of card readers), the legitimacy verification of the source of requests can be added, such as using digital signature technology to ensure that the request comes from a legitimate client, preventing malicious requests from interfering with and damaging the system.

[0076] Furthermore, an intelligent scheduling algorithm can be introduced to intelligently decide when to send a request based on the current usage status of the device (such as whether it is busy or in a maintenance cycle) and the network load, so as to avoid device overload and network congestion, and improve the success rate of device connection and system stability.

[0077] The client receives the request returned from the server, and analyzes and processes different device types and message protocols in the request using different filtering mechanisms through filters set on the client; the characteristics and requirements of the device type correspond one-to-one with the filtering mechanism; the specifications and requirements of the message protocol correspond one-to-one with the filtering mechanism.

[0078] Specifically, the client receives the request and the filter settings

[0079] Receive request: The client will receive the request returned from the server. During the entire device docking and information exchange process, the server will process the client's call request accordingly and return the result or further request to the client.

[0080] Filter settings: A filter is set on the client side, which is one of the core parts of the entire technical solution. Its function is to analyze and process the received requests to distinguish different device types and message protocols, and use different filtering mechanisms for targeted processing, thereby achieving the division of device docking error boundaries and error prompts.

[0081] Mapping device types to filtering mechanisms

[0082] Correspondence: Different device types have their own unique characteristics and requirements, which correspond one-to-one with specific filtering mechanisms.

[0083] Specific examples

[0084] For the card reader device, it is a USB device. Its filtering mechanism is to first detect the USB device connected to the computer and verify it according to the pid and vid of the device model. If the supported device model is not detected, it will return a prompt that the supported device is not detected; if the supported device model is detected, the relevant card reading interface provided by the manufacturer will be called. If the interface call sends an error, the error information will be returned according to the relevant error code.

[0085] The barcode printer is also a USB device. The filtering mechanism also detects the connected USB device first, verifies it based on pid and vid, and returns a corresponding prompt if no supported model is detected. If it is detected, the device is connected. There will be corresponding prompts if the connection fails or the interface call fails.

[0086] For LED devices, the filtering mechanism is to first initiate a device connection based on the maintained device IP, port and other information. If the connection fails, an error prompt is returned. After a successful connection, the device parameters are verified. If there is a problem, a prompt is given based on the verification error information. If there is no problem, the relevant SDK interface is called. If the interface reports an error, an error code is given.

[0087] The weighing device checks whether the serial port can be opened normally according to the maintained serial port number, baud rate, data bit and other parameters. If the opening fails, the serial port related prompts are returned. If it is opened normally, the data is read and parsed. If the parsing error is reported, the prompt is returned according to the error.

[0088] The license plate recognition device involves camera-related operations. First, use the configured username, password, and IP to log in. If the login fails, a prompt indicating that the camera cannot be opened is returned. After the camera is successfully opened, the license plate recognition interface is called. If the recognition fails, the interface error code is prompted.

[0089] The camera screen loading request returns a message classification based on the preview instruction sent to the device, giving different prompts, such as channel offline, device unresponsive, streaming media service not started, and other related prompts.

[0090] Correspondence between message protocol and filtering mechanism

[0091] Correspondence: Different message protocols have their own specifications and requirements, which also correspond one-to-one with specific filtering mechanisms.

[0092] Specific examples

[0093] For the MQTT protocol, the filtering mechanism first verifies the connection to determine whether the corresponding MQTT channel can be connected normally. If the connection fails, a connection failure prompt is returned. After the connection is successful, the interface is called to send a message to the device and the time is recorded. If no return message is received within the specified time, a timeout prompt is generated. After receiving the message, the token is authenticated. If the authentication fails, an authentication failure prompt is returned. If the authentication succeeds, the message content is verified, and errors are divided and prompts are generated according to different device types.

[0094] For the websocket protocol, the filtering mechanism is to first check whether there is a successfully established websocket connection. If not, a prompt is generated for the non-existence of the connection. If a connection exists, a related device call is made. The specific docking error prompt is generated according to the device type and specific error information.

[0095] For example, the device type and filtering mechanism correspondence example

[0096] Reader Request

[0097] Device type characteristics and requirements: The card reader is usually connected to the computer via a USB interface. Different models of card readers have different pid and vid.

[0098] Filtering mechanism: The client first detects the USB device connected to the computer and verifies it according to the pid and vid of the device model. If the supported device model is not detected, a prompt indicating that the supported device is not detected is returned. If a supported device model is detected, the relevant card reading interface provided by the manufacturer will be called. If the interface call sends an error, the error information will be returned according to the relevant error code.

[0099] Barcode Printer Request

[0100] Device type characteristics and requirements: It is also a USB device, and there are also different models corresponding to different pids and vids.

[0101] Filtering mechanism: First detect the USB device connected to the computer, and verify it according to the pid and vid of the device model. If the supported device model is not detected, a prompt that the supported device is not detected is returned. If a supported device model is detected, the device is connected. If the device cannot be successfully connected, a prompt such as "Failed to open the printer, please check the device connection" is returned. If the device is successfully connected, the relevant printing interface will be called. If an error occurs during the interface call process, a prompt will be generated according to the relevant error code.

[0102] LED Request

[0103] Device type characteristics and requirements: It is necessary to maintain device IP, port and other information for connection.

[0104] Filtering mechanism: First, initiate a device connection based on the maintained device IP, port and other information. If the device cannot be successfully connected, a relevant error prompt is returned. If the device is successfully connected, the relevant device parameters in the request are verified. If there is a problem with the parameter verification, a relevant prompt is given based on the verification error information. If no problem is found in the parameter verification, the relevant SDK interface for sending data to the LED is called. If an error occurs during the call, a corresponding prompt is given based on the error code.

[0105] Weighbridge Request

[0106] Device type characteristics and requirements: Serial port connection needs to be based on specific serial port number, baud rate, data bit and other parameters.

[0107] Filtering mechanism: Check whether the scale serial port can be opened normally according to the maintained serial port number, baud rate, data bit and other parameters. If the opening fails, it will return a prompt such as the serial port does not exist or is occupied. If it is opened normally, the relevant serial port data will be read and analyzed. If an error occurs during the analysis, the corresponding prompt will be returned according to the error.

[0108] Example of the correspondence between message protocol and filtering mechanism

[0109] MQTT protocol

[0110] Protocol specifications and requirements: The connection needs to be verified to ensure that the corresponding MQTT channel can be connected normally. It also involves recording the message sending time, authentication of received messages, and verification of the returned message content according to different device types.

[0111] Filtering mechanism: First, the connection will be checked to see if the corresponding mqtt channel can be connected normally. If the connection fails, a prompt indicating the connection failure will be returned. If the connection is successful, the relevant interface will be called to send a message to the device. At this time, the time of sending the message will be recorded. If the relevant device data message returned is not received within the specified time, a prompt indicating that the return message has timed out will be generated. If the return message is successfully received, authentication will be performed based on the returned token. If the authentication fails, it proves that the identity authentication has not been passed, and a prompt indicating the authentication failure will be returned. If the authentication is successful, the content of the returned message will be checked, and errors will be divided and prompts will be generated based on different device types.

[0112] WebSocket Protocol

[0113] Protocol specifications and requirements: It is necessary to check whether there is a successfully established websocket connection, and then make relevant device calls and error prompts based on the connection status.

[0114] Filtering mechanism: First check whether there is a successfully established websocket connection. If not, a prompt is generated indicating that there is no websocket connection. If there is a connection, relevant device calls are made. Specific docking error prompts are divided and generated according to the device type and specific error information.

[0115] Furthermore, when filtering and analyzing different types of devices, a real-time monitoring function of the device status can be added. For example, for a card reader device, in addition to detecting whether it is correctly connected and whether the interface call is normal, the card reader's operating temperature, power (if it is a wireless card reader) and other status information can also be monitored. When these status information exceeds the normal range, the filter returns the corresponding prompt information to the client so that timely measures can be taken, such as reminding the user to replace the battery or check the heat dissipation of the device.

[0116] Furthermore, a device compatibility database can be established to record the compatibility information of different device types and systems. When a request for a new device is received, the filter first queries the compatibility database. If incompatibility is found, prompt information is returned to the client in a timely manner, and possible solutions are provided, such as suggestions for updating the driver or system software version.

[0117] Furthermore, for message protocols, as technology evolves, protocols may be upgraded. The filter can have the ability to detect and process protocol upgrades. When it is detected that the request returned by the server uses a new protocol version, the filter can try to convert the protocol or prompt the client to perform the corresponding upgrade operation to ensure normal communication.

[0118] Furthermore, the security of the protocol can be further enhanced on the basis of meeting the protocol specifications and requirements. For example, for the MQTT protocol and the WebSocket protocol, a data encryption layer can be added to encrypt the transmitted data to prevent the data from being stolen or tampered with during transmission. At the same time, the filter can decrypt and verify the encrypted data to ensure the integrity and authenticity of the data.

[0119] If the client identifies information and parameters that do not conform to the pre-defined device, the request is processed, the cause of the error is analyzed, and a corresponding prompt is returned. If no error information is identified, the device is called normally to complete the device docking operation.

[0120] Specifically, the processing when the device information and parameters do not match

[0121] Identifying Errors

[0122] After receiving the request returned by the server, the client will compare the device information and parameters in the request with the pre-defined ones. For example, for card reader requests, the pid and vid of the device model will be compared; for scale requests, the serial port number, baud rate, data bits and other parameters will be compared; for camera-related requests, the user name, password, IP and other information will be compared. If the information is inconsistent, the situation that does not meet the pre-defined requirements will be identified.

[0123] Analyze the cause of the error

[0124] When a non-conformance is identified, the cause of the error will be analyzed based on the device type and the specific non-conformance. For example, if the card reader does not detect the supported device model, the reason may be that the device is not correctly connected to the computer's USB port, or the device is not in the pre-defined support list. If the serial port of the scale cannot be opened normally, the reason may be that the parameter settings are wrong, or the serial port is occupied by other programs, etc.

[0125] Return to corresponding prompt

[0126] According to the analyzed error cause, targeted prompt information is returned to the client. For example, if the card reader device does not detect the supported model, a prompt that the supported device is not detected will be returned; if the serial port of the scale fails to open, prompts such as the serial port does not exist or is occupied will be returned. These prompts can help users quickly understand the problem so that they can take appropriate solutions.

[0127] What to do if an error message is not recognized

[0128] Normal call device

[0129] If the client does not find any discrepancies with the predefined conditions when comparing the device information and parameters, it will call the device according to the normal process. For example, for a card reader, if a supported device model is detected, the relevant card reading interface provided by the manufacturer will be called; for a weighbridge, if the serial port can be opened normally and data can be read, subsequent data processing operations will be performed.

[0130] Complete the device docking operation

[0131] After the device is called normally, the device docking operation is completed, so that the device can work normally and realize its corresponding functions. For example, the card reader can read the card information normally, the scale can weigh and transmit data normally, etc.

[0132] For example, a card reader device

[0133] Identify error conditions

[0134] When the client sends a request to call the card reader, the filter will first detect the USB device connected to the computer and verify it according to the pid and vid of the device model. If the supported device model is not detected, the device information and parameters that do not meet the pre-defined requirements will be identified. At this time, the client will process the request, analyze the reason for the wrong device model, and return a prompt that the supported device was not detected.

[0135] No error condition identified

[0136] If a supported device model is detected, the relevant card reader interface provided by the manufacturer will be called. If the interface call is normal and no error message is identified, the device will be called normally to complete the device docking operation, and the card reader can work normally to perform card reading operations.

[0137] Barcode Printer Equipment

[0138] Identify error conditions

[0139] For barcode printer requests, the USB device connected to the computer is also detected first, and the device model is verified according to the pid and vid. If the supported device model is not detected and does not meet the pre-defined device information and parameters, the client will analyze the reason why the device is not connected correctly and return a prompt that the supported device is not detected.

[0140] If a supported device model is detected and the device cannot be successfully connected during device connection, such as the printer has hardware problems such as paper jam, ink shortage, or connection line failure, the client will identify the parameter settings that do not conform to normal device operation, analyze the cause of the connection failure, and return a prompt such as Failed to open the printer, please check the device connection.

[0141] No error condition identified

[0142] When the device is successfully connected and the related printing interface is called normally without identifying error information, the device is called normally to complete the device docking operation, and the barcode printer can perform printing tasks normally.

[0143] LED Equipment

[0144] Identify error conditions

[0145] When calling the LED request, first initiate the device connection based on the maintained device IP, port and other information. If the device cannot be successfully connected, such as due to network connection failure or hardware damage of the device itself, it does not meet the pre-defined device information and parameters. The client will analyze the reason for the connection failure and return relevant error prompts.

[0146] If the device is successfully connected, but when verifying the relevant device parameters in the request, if it is found that the parameter settings are incorrect (for example, the brightness setting exceeds the device's tolerance range, etc.), the client will identify the incorrect parameter settings, analyze the cause of the parameter verification error, and provide relevant prompts based on the verification error information.

[0147] No error condition identified

[0148] When no problem is found in parameter verification, and the relevant SDK interface for sending data to the LED is called normally without identifying error information, the device is called normally to complete the device docking operation, and the LED can work normally for display operation.

[0149] Weighbridge equipment

[0150] Identify error conditions

[0151] When calling the scale request, check whether the scale serial port can be opened normally according to the maintained serial port number, baud rate, data bit and other parameters. If the opening fails, for example, the serial port is occupied by other programs or the parameter setting is wrong, it does not meet the pre-defined device information and parameters. The client will analyze the cause of the serial port problem and return a prompt such as the serial port does not exist or is occupied.

[0152] If the serial port is opened normally but an error occurs when reading and parsing the relevant serial port data, such as data transmission error or mismatch of parsing algorithm, the client will identify the situation that does not conform to normal data processing, analyze the cause of the parsing error, and return the corresponding prompt according to the error.

[0153] No error condition identified

[0154] When the serial port is opened normally and the data is parsed normally without any error information being recognized, the device is called normally, the device docking operation is completed, and the scale can perform weighing and other operations normally.

[0155] License plate recognition equipment (camera related)

[0156] Identify error conditions

[0157] When calling the license plate recognition request, first use the configured camera username, password, and IP to log in. If the login fails, such as the username or password is incorrect, or the camera network connection problem causes the inability to log in, it does not meet the pre-defined device information and parameters. The client will analyze the reason for the login failure and return relevant prompts such as failure to open the camera.

[0158] If the camera is successfully turned on, but the license plate recognition interface cannot be successfully recognized, such as the license plate is damaged or the light is bad and affects the recognition effect, the client will identify the situation that does not meet normal recognition requirements, analyze the reasons for the recognition failure, and provide relevant prompts based on the error code returned by the interface.

[0159] No error condition identified

[0160] When the camera logs in successfully and the license plate recognition is successful, and no error message is recognized, the device is called normally, the device docking operation is completed, and the license plate recognition system can perform the license plate recognition task normally.

[0161] Camera image loading device

[0162] Identify error conditions

[0163] When loading the camera image request, the preview command sent to the device is used to return the message for classification. If the return message shows that the channel is offline, such as the camera is powered off or the network connection is interrupted, it does not meet the pre-defined device information and parameters. The client will analyze the reason for the channel being offline and prompt to check the device status.

[0164] If the preview command succeeds but the device does not respond, such as due to a device freeze or software conflict, the client will identify the situation that does not conform to the normal device response, analyze the reason for the device's unresponsiveness, and prompt you to check the device or network.

[0165] If the streaming service is not started when checking whether it is started, and the streaming service running conditions required for normal device operation are not met, the client will analyze the reason why the streaming service is not started and prompt to check whether the streaming service is started.

[0166] No error condition identified

[0167] When the device status is normal, the preview command responds normally, the streaming media service starts normally, and no error information is recognized, the device is called normally, the device docking operation is completed, and the camera image can be loaded and displayed normally.

[0168] Furthermore, the identified errors that do not conform to the pre-defined device information and parameters can be classified in more detail. For example, device access errors can be subdivided into different categories such as device model mismatch, parameter setting error, connection timeout, etc. At the same time, statistics are collected on various errors, and the frequency and time distribution of each error are recorded, so as to analyze the weak links and common problems in the device docking process and provide data support for subsequent system optimization and equipment maintenance.

[0169] Furthermore, in addition to analyzing the cause of the error, the root cause of the error can be further traced. For example, if the device parameter setting is wrong, not only should the user be prompted to set the correct parameters, but also the link that caused the parameter setting error should be found, such as the client configuration file error or the server data transmission error, so as to fundamentally solve the problem and reduce the recurrence of similar errors.

[0170] Furthermore, after the device is normally called and the docking operation is completed, the performance indicators of the device can be continuously monitored. For example, for camera devices, its frame rate, resolution, image quality and other performance parameters can be monitored; for card reader devices, its reading speed, accuracy, etc. can be monitored. If the performance of the device drops abnormally, an alarm will be issued in time and relevant data will be recorded for troubleshooting and equipment maintenance.

[0171] Furthermore, the usage of the device can be recorded, including the time of each call, usage duration, operation type, and other information. By analyzing these usage records, the frequency and mode of device usage can be understood, providing a basis for the reasonable configuration of the device and resource optimization. For example, if a device is found to have not been used for a long time, you can consider adjusting its deployment location or reallocating its usage permissions.

[0172] According to an embodiment of the present application, when the client receives the request returned from the server, the filter added to the client uses different filtering mechanisms for analysis and processing according to different device types and message protocols in the request, specifically:

[0173] Filter analysis for different device types includes: card reader request, barcode printer request, LED request, weighbridge request, license plate recognition request, and camera image loading request;

[0174] The filtering analysis of different message protocols includes: mqtt protocol communication requests and websocket protocol communication requests.

[0175] Specifically, filtering analysis of different device types

[0176] Reader Request

[0177] For card reader requests, the filter will first detect the USB device connected to the computer and verify it based on the pid and vid of the device model.

[0178] If the device model supported by the access is not detected, a prompt indicating that no supported device was detected will be returned.

[0179] If a supported device model is detected, the relevant card reader interface provided by the manufacturer will be called. If the interface call sends an error, the error information will be returned according to the relevant error code.

[0180] Barcode Printer Request

[0181] Also as a USB device, first detect the USB device connected to the computer and verify it according to the PID and VID of the device model.

[0182] When the device model supported by the access is not detected, a prompt indicating that the supported device is not detected is returned.

[0183] After the supported device model is detected, the device is connected. If the connection fails, it will return to the prompt "Failed to open the printer, please check the device connection". After the device is successfully connected, the relevant printing interface is called. If an error occurs during the interface call process, a prompt is generated according to the relevant error code.

[0184] LED Request

[0185] The filter will first initiate a device connection based on the maintained device IP, port and other information.

[0186] If the device cannot be connected successfully, a relevant error message will be returned.

[0187] After successfully connecting to the device, the relevant device parameters in the request are verified. If there are any problems with the parameter verification, relevant prompts will be given according to the verification error information. If no problems are found in the parameter verification, the relevant SDK interface that sends data to the LED is called. If an error occurs during the call, a corresponding prompt will be given according to the error code.

[0188] Weighbridge Request

[0189] Check whether the scale serial port can be opened normally according to the maintained serial port number, baud rate, data bit and other parameters.

[0190] If the opening fails, the prompt will be returned that the serial port does not exist or is occupied.

[0191] If it is opened normally, the relevant serial port data will be read and analyzed. If an error occurs during analysis, the corresponding prompt will be returned according to the error.

[0192] License Plate Recognition Request

[0193] First log in using the configured camera username, password, and IP.

[0194] If the login fails, the system will return prompts such as failure to open the camera.

[0195] After the camera is successfully opened, call the license plate recognition interface for recognition. If recognition fails, the interface returns an error code for relevant prompts.

[0196] Camera image loading request

[0197] Classify the return message based on the preview instruction sent to the device.

[0198] The channel is offline, please check the device status; the preview command is successful but the device does not respond, please check the device or network; check whether the streaming service is started, etc.

[0199] Filtering analysis of different message protocols

[0200] MQTT protocol communication request

[0201] First, check the connection to determine whether the corresponding mqtt channel can be connected normally. If the connection fails, a prompt indicating the relevant connection failure is returned.

[0202] If the connection is successful, the relevant interface will be called to send a message to the device, and the time of sending the message will be recorded.

[0203] If the relevant device data message is not received within the specified time, a prompt indicating that the return message has timed out will be generated.

[0204] After successfully receiving the return message, authentication will be performed based on the returned token. If authentication fails, it means that the identity authentication has not been passed, and a prompt related to the authentication failure will be returned.

[0205] If the authentication is successful, the returned message content is verified, and errors are classified and prompts are generated according to different device types.

[0206] Websocket protocol communication request

[0207] It will first check whether there is a successfully established websocket connection. If not, a prompt will be generated indicating that there is no websocket connection.

[0208] If there is a connection, relevant device calls will be made, and specific docking error prompts will be divided and generated according to the device type and specific error information.

[0209] According to an embodiment of the present application, the card reader request is specifically:

[0210] Detect the connected USB device and verify it according to the pid and vid of the device model;

[0211] If the supported device model is not detected, a prompt indicating that the supported device is not detected is returned;

[0212] If a supported device model is detected, the relevant card reader interface provided by the manufacturer is called. If the interface call sends an error, the error information is returned according to the relevant error code.

[0213] Specifically, the pid and vid (vendor identifier) ​​are used for verification. The pid and vid are important identification information of the device, similar to the "identity card" of the device, through which it can be accurately identified whether the device is the required card reader device and whether it is compatible with the system.

[0214] No supported device detected

[0215] If the supported device model is not detected during the verification process, this means that the connected device may not be the correct card reader or there is a problem with the card reader driver or other related settings. At this time, the system will return a prompt message that the supported device is not detected, so that the user can understand that there is a problem with the device connection and needs to check whether the device is connected correctly or whether the corresponding driver needs to be installed.

[0216] Actions after a supported device is detected

[0217] When the supported device model is detected, it means that the connected device is a card reader that meets the requirements. Next, the system will call the relevant card reader interface provided by the manufacturer. This interface is the channel for the card reader to interact with the system. By calling this interface, the system can send instructions to the card reader and obtain data fed back by the card reader. However, if an error is sent during the interface call, this indicates that a problem occurred during the data interaction. At this point, the system will return error information based on the relevant error code. The error code is a standardized error identifier that can help developers or technicians quickly locate the problem, such as insufficient permissions, incorrect data format, or other reasons that caused the interface call to fail.

[0218] According to one embodiment of the present application, the barcode printer request is specifically:

[0219] Detect the connected USB device and verify it according to the pid and vid of the device model;

[0220] If the supported device model is not detected, a prompt indicating that the supported device is not detected is returned;

[0221] If a supported device model is detected, the device is connected. If the device cannot be connected successfully, the prompt "Failed to open the printer" is returned. Please check the device connection prompt. If the device is successfully connected, the relevant printing interface is called. If an error occurs during the interface calling process, a prompt is generated according to the relevant error code.

[0222] Specifically, detect access devices and verify

[0223] When it comes to barcode printer requests, since barcode printers are usually connected to computers via USB interfaces, the USB device connected to the computer must be detected first. By checking the pid (product identifier) ​​and vid (vendor identifier) ​​of the device model, it is determined whether the connected device is the required barcode printer and whether it is compatible with the system. These two identifiers are like unique identifiers of the device and can accurately identify the device.

[0224] No supported device detected

[0225] If the supported device model is not detected during the verification process, this indicates that the connected device may not be the correct barcode printer or there is a problem with the relevant settings. At this time, the system will return a prompt message that the supported device is not detected, so that the user knows that there is a problem with the device connection, and then check whether the device connection is correct or whether the appropriate driver needs to be installed.

[0226] Actions after a supported device is detected

[0227] When the supported device model is detected, it means that the barcode printer that meets the requirements is connected. Then the device connection operation will be carried out.

[0228] Connection failure scenarios

[0229] If the device cannot be connected successfully, it may be due to device failure, connection line problem or other reasons. At this time, the system will return the prompt "Failed to open the printer, please check the device connection" to guide the user to check the problems related to the device connection.

[0230] Connection success

[0231] If the device is successfully connected, the relevant printing interface will be called. This interface is the channel for the barcode printer to interact with the system, through which the system can send printing instructions and data to the printer.

[0232] However, if an error occurs during the interface call, it means that there is a problem in the data interaction link. At this time, the system will generate a prompt based on the relevant error code, which can help technicians quickly locate the problem, such as whether the interface call failed due to data format errors, permission issues, or other reasons.

[0233] According to an embodiment of the present application, the LED request is specifically:

[0234] Initiate device connection based on the maintained device IP and port information. If the device cannot be successfully connected, a relevant error message will be returned.

[0235] If the device is successfully connected, the relevant device parameters in the request will be verified. If there is a problem with the parameter verification, relevant prompts will be given according to the verification error information; if no problem is found in the parameter verification, the relevant SDK interface that sends data to the LED will be called. If an error occurs during the call, a corresponding prompt will be given according to the error code.

[0236] Specifically, the device connection operation

[0237] For LED requests, the device connection will be initiated first based on the maintained device IP and port information. This is because in a network environment, devices need to communicate through specific IP addresses and port numbers. If the device cannot be successfully connected, it may be due to network setting errors, device failure, or incorrect configuration of IP addresses and port numbers. At this time, the system will return relevant error prompts so that users can troubleshoot the problem.

[0238] Verification operation after successful connection

[0239] When the device is successfully connected, the relevant device parameters in the request will be verified.

[0240] Problems with parameter verification

[0241] If the parameter verification finds a problem, it may be due to a parameter setting error or a mismatch between the device and the system. At this time, the system will give relevant prompts based on the verification error information to help users understand which parameters have problems so that they can be corrected.

[0242] When no problem is found in parameter verification

[0243] If no problem is found in the parameter verification, the relevant SDK interface for sending data to the LED will be called. The SDK (Software Development Kit) interface is a collection of tools for developers to interact with specific devices. By calling this interface, the function of sending data to the LED device can be realized.

[0244] However, if an error occurs during the interface call, it may be due to a permission issue for the interface call, a data transmission issue, or an abnormality in the data processing of the device itself. At this time, the system will give a corresponding prompt based on the error code, which can help technicians quickly locate the problem so that they can take appropriate solutions.

[0245] According to an embodiment of the present application, the weighbridge request is specifically:

[0246] Check whether the scale serial port can be opened normally according to the maintained serial port number, baud rate and data bit parameters. If the opening fails, it will return a prompt that the serial port does not exist or is occupied.

[0247] If it is opened normally, the relevant serial port data will be read and analyzed. If an error occurs during the analysis, the corresponding prompt will be returned according to the error.

[0248] Specifically, the serial port is opened and checked

[0249] For scale requests, first check whether the scale serial port can be opened normally based on the maintained serial port number, baud rate, data bit and other parameters. The serial port number is used to identify different serial port devices, and the baud rate and data bit are important setting parameters for serial port communication. If these parameters are not set correctly or there is a problem with the scale device itself, it may cause the serial port to fail to open normally.

[0250] When the opening fails, the system will return a prompt such as the serial port does not exist or is occupied. The serial port does not exist because the device is not connected correctly or the driver is not installed correctly. If it is occupied, it may be that other programs are using the serial port resources.

[0251] Serial port data processing

[0252] If the serial port can be opened normally, the relevant serial port data will be read and parsed. The serial port data may contain information such as the weight measured by the scale. During the parsing process, if an error occurs, it may be due to data format errors, data corruption during transmission, or problems with the parsing algorithm. At this time, the system will return corresponding prompts based on the error to help troubleshoot the problem.

[0253] According to an embodiment of the present application, the license plate recognition request is specifically:

[0254] Use the configured camera username, password, and IP address to log in. If the login fails, a prompt indicating that the camera opening failed will be returned.

[0255] If the camera is successfully opened, the license plate recognition interface is called for recognition. If recognition fails, the interface returns an error code with relevant prompts.

[0256] Specifically, the camera login operation

[0257] For license plate recognition requests, you must first log in using the configured camera username, password, and IP. This information is used to verify whether the user has permission to access the camera and establish a connection with the camera. If the login fails, it may be due to incorrect username or password, or camera network connection problems, in which case the system will return a prompt indicating that the camera failed to be opened.

[0258] License Plate Recognition Operation

[0259] When the camera is successfully turned on, the license plate recognition interface will be called for recognition. This interface is a program interface for implementing the license plate recognition function. If the license plate cannot be successfully recognized, it may be due to unclear license plate images, inaccurate recognition algorithms, or the vehicle is in a special position. At this time, the system will give relevant prompts based on the error code returned by the interface for further troubleshooting.

[0260] According to an embodiment of the present application, the camera image loading request is specifically:

[0261] The return message of the preview command sent to the device is classified into: the channel is offline, please check the device status;

[0262] The preview command succeeded but the device did not respond. Please check the device or network.

[0263] Check if the streaming service starts prompting.

[0264] Specifically, the message classification is based on

[0265] When it comes to camera image loading requests, the system will classify the messages returned by the preview command sent to the device. This preview command is an operation command for obtaining the camera image, and the device will return the corresponding message based on its own status and the received command.

[0266] Different classification situations and tips

[0267] Channel is offline

[0268] If the returned message indicates that the channel is offline, it means that there is a problem with the communication channel between the camera and the system. It may be due to a device disconnection, network failure, or a device failure that makes it impossible to establish an effective communication channel. At this time, the system will prompt the user to check the device status, including whether the device is powered on normally, whether the device's network connection is normal, and whether the device's related settings are correct.

[0269] The preview command succeeded but the device did not respond

[0270] When the return message shows that the preview command is successful but the device does not respond, it means that the system has successfully sent the preview command, but the camera has not given the corresponding feedback. This may be due to device freezes, device software or hardware failures, or network delays or packet loss. At this time, the system will prompt the user to check the device or network. The user needs to check whether the camera device itself is working properly, and whether the network connection is stable and whether there is network congestion.

[0271] Check whether the streaming service is enabled

[0272] If the message is returned to prompt you to check whether the streaming service is started, it is because the loading of the camera image usually requires the support of the streaming service. If the streaming service is not started or fails, the camera image cannot be obtained and displayed normally. At this time, the system will prompt the user to check whether the streaming service is started. The user needs to check whether the relevant streaming service software is running normally and whether the service needs to be restarted.

[0273] According to an embodiment of the present application, the MQTT protocol communication request is specifically: verifying the connection to determine whether the corresponding MQTT channel can be connected normally, and returning a prompt of related connection failure if the connection fails;

[0274] If the connection is successful, the relevant interface will be called to send a message to the device, and the time of sending the message will be recorded. If the relevant device data message is not received within the specified time, a prompt of return message timeout will be generated;

[0275] If the return message is successfully received, authentication will be performed based on the returned token. If authentication fails, it means that the identity authentication has not been passed and a prompt related to authentication failure will be returned;

[0276] If the authentication is successful, the returned message content will be classified into errors and prompts will be generated, and relevant operations will be performed according to different device types.

[0277] Specifically, connection verification

[0278] For MQTT protocol communication requests, the connection must first be verified to determine whether the corresponding MQTT channel can be connected normally. MQTT is a message queue telemetry transmission protocol. Before communication, it is necessary to ensure that the connection between the client and the channel is normal. If the connection fails, it may be due to network setting errors, server-side problems, or client configuration errors. At this time, the system will return a prompt related to the connection failure so that users can troubleshoot the problem.

[0279] Message sending and timeout processing

[0280] When the connection is successful, the relevant interface will be called to send a message to the device, and the time of sending the message will be recorded. This is to ensure that the message can be accurately sent to the device and facilitate the subsequent monitoring of message transmission. If the relevant device data message is not received within the specified time, it may be due to network delay, device failure or message loss. At this time, the system will generate a prompt that the return message has timed out, reminding the user that there may be a problem with the message transmission.

[0281] Authentication operation

[0282] After successfully receiving the return message, authentication will be performed based on the returned token. Token is an identifier used to verify identity. By verifying the token, you can ensure that the source of the message is legitimate. If authentication fails, it means that the message may come from an illegal source or there is a problem in the verification process. At this time, the system will return a prompt related to authentication failure to ensure the security of the system.

[0283] Message content processing

[0284] After successful authentication, the returned message content will be verified, and errors will be classified and prompts will be generated according to different device types. Different device types may have different requirements and formats for message content. By verifying the message content, the accuracy and completeness of the message can be ensured. If errors are found in the message content, the system will generate corresponding prompts based on the error situation and device type so that users can understand the problem and handle it.

[0285] According to an embodiment of the present application, the websocket protocol communication request specifically includes: checking whether there is a successfully established websocket connection, and if not, generating a related prompt that the websocket does not exist;

[0286] If there is a connection, relevant device calls will be made, and specific connection error prompts will be divided and generated according to the device type and specific error information.

[0287] Specifically, for websocket protocol communication requests, first check whether there is a successfully established websocket connection. Websocket is a protocol for full-duplex communication on a single TCP connection. Before communication, it is necessary to ensure that the connection has been successfully established. If there is no such connection, it may be due to network configuration errors, server-side problems, or the client did not initiate the connection correctly. At this time, the system will generate a related prompt that there is no websocket connection, so that users can troubleshoot the problem.

[0288] Device call and error prompts

[0289] When there is a connection, the relevant device will be called. During the call process, if there is a problem, it will be divided according to the device type and specific error information and a docking error prompt will be generated. Different device types may have different requirements and processing methods for connection and data transmission. By generating prompts based on device types and specific error information, users can be more accurately informed of the problem, making it easier for users to handle it in a targeted manner. For example, if it is a camera device, it may prompt that the camera connection is interrupted or the image transmission is wrong; if it is other devices, corresponding error prompts will be given according to their own characteristics.

[0290] This interpretation information comes from the text block.

[0291] Anything not described in this application can be achieved by adopting or drawing on existing technologies.

[0292] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from other embodiments.

[0293] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for distinguishing device docking error boundaries, characterized in that: include: The client sends a call request for a specified device to the server according to business requirements, and the client pre-sets the information and parameters required by different devices; The client receives the request returned from the server, and uses different filtering mechanisms to analyze and process different device types and message protocols in the request through filters set on the client; the characteristics and requirements of the device types correspond to the filtering mechanisms one by one; the specifications and requirements of the message protocols correspond to the filtering mechanisms one by one; If the client identifies information and parameters that do not conform to the pre-defined device, the request is processed, the cause of the error is analyzed, and a corresponding prompt is returned. If no error information is identified, the device is called normally to complete the device docking operation.

2. The method according to claim 1, characterized in that: The client receives the request returned from the server, and uses different filtering mechanisms to analyze and process different device types and message protocols in the request through filters set on the client, specifically: Filter analysis for different device types includes: card reader request, barcode printer request, LED request, weighbridge request, license plate recognition request, and camera image loading request; The filtering analysis of different message protocols includes: mqtt protocol communication requests and websocket protocol communication requests.

3. The method according to claim 2, characterized in that The card reader request is specifically: Detect the connected USB device and verify it according to the pid and vid of the device model; If the supported device model is not detected, a prompt indicating that the supported device is not detected is returned; If a supported device model is detected, the relevant card reader interface provided by the manufacturer is called. If the interface call sends an error, the error information is returned according to the relevant error code.

4. The method according to claim 2, characterized in that: The barcode printer request is specifically: Detect the connected USB device and verify it according to the pid and vid of the device model; If the supported device model is not detected, a prompt indicating that the supported device is not detected is returned; If a supported device model is detected, the device will be connected. If the device cannot be successfully connected, the message "Open Printer Failed" will be displayed. Please check the device connection prompt. If the device is successfully connected, the relevant printing interface will be called. If an error occurs during the interface call process, a prompt will be generated according to the relevant error code.

5. The method according to claim 2, characterized in that: The LED request is specifically: Initiate device connection based on the maintained device IP and port information. If the device cannot be successfully connected, a relevant error message will be returned. If the device is successfully connected, the relevant device parameters in the request will be verified. If there is a problem with the parameter verification, relevant prompts will be given according to the verification error information; If no problem is found in the parameter verification, the relevant SDK interface for sending data to the LED is called. If an error occurs during the call, a corresponding prompt is given according to the error code.

6. The method according to claim 2, characterized in that The weighbridge request is specifically: Check whether the scale serial port can be opened normally according to the maintained serial port number, baud rate, and data bit parameters. If the opening fails, a prompt indicating that the serial port does not exist or is occupied will be returned; If it is opened normally, the relevant serial port data will be read and analyzed. If an error occurs during the analysis, the corresponding prompt will be returned according to the error.

7. The method according to claim 2, characterized in that The license plate recognition request is specifically: Use the configured camera username, password, and IP address to log in. If the login fails, a prompt indicating that the camera opening failed will be returned. If the camera is successfully opened, the license plate recognition interface is called for recognition. If recognition fails, the interface returns an error code with relevant prompts.

8. The method according to claim 2, characterized in that: The camera image loading request is specifically: The return message of the preview command sent to the device is classified into: the channel is offline, please check the device status; The preview command succeeded but the device did not respond. Please check the device or network. Check if the streaming service starts prompting.

9. The method according to claim 2, characterized in that: The mqtt protocol communication request specifically includes: verifying the connection to determine whether the corresponding mqtt channel can be connected normally, and returning a prompt indicating the relevant connection failure if the connection fails; If the connection is successful, the relevant interface will be called to send a message to the device, and the time of sending the message will be recorded. If the relevant device data message is not received within the specified time, a prompt of return message timeout will be generated; If the return message is successfully received, authentication will be performed based on the returned token. If authentication fails, it means that the identity authentication has not been passed and a prompt related to authentication failure will be returned; If the authentication is successful, the returned message content will be classified into errors and prompts will be generated, and relevant operations will be performed according to different device types.

10. The method according to claim 2, characterized in that The websocket protocol communication request specifically includes: checking whether there is a successfully established websocket connection, and if not, generating a prompt related to the non-existence of the websocket; If there is a connection, relevant device calls will be made, and specific connection error prompts will be divided and generated according to the device type and specific error information.

Images