CN114846901B

CN114846901B - Communication method, device, equipment and storage medium

Info

Publication number: CN114846901B
Application number: CN202080087911.6A
Authority: CN
Inventors: 杨宁
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2020-02-18
Filing date: 2020-02-18
Publication date: 2024-05-31
Anticipated expiration: 2040-02-18
Also published as: WO2021163891A1; CN114846901A

Abstract

The embodiment of the application provides a communication method, a device, equipment and a storage medium, which are mainly applied to bridging equipment, wherein the bridging equipment is used for realizing connection between OCF equipment and non-OCF equipment, the bridging equipment can acquire the connection state between the non-OCF equipment and the bridging equipment, and performs certain processing according to the connection state, so that when a user accesses through an OCF client, the connection state between the non-OCF equipment and the bridging equipment can be clearly confirmed, the non-OCF equipment connected is ensured to be accessed, the problem of access failure is avoided, and the access efficiency is effectively improved.

Description

Communication method, device, equipment and storage medium

Technical Field

The embodiment of the application relates to the technology of the Internet of things, in particular to a communication method, a device, equipment and a storage medium.

Background

The internet of things (THE INTERNET of Things, ioT) refers to collecting any object or process needing to be monitored, connected and interacted in real time through various devices and technologies such as various information sensors, radio frequency identification technologies, global positioning systems, infrared sensors, laser scanners, and the like, collecting various needed information, and realizing ubiquitous connection of objects and people through various possible network accesses, thereby realizing intelligent perception, identification and management of objects and processes. With the development of the internet of things technology, communication between devices of various protocol types is gradually realized.

At present, in the communication process of the internet of things equipment, interconnection of different equipment can be realized in a bridging manner, fig. 1 is a schematic diagram of a bridging architecture from a bluetooth/zigbee protocol to an open interconnection foundation (Open Connectivity Foundation, OCF) protocol, and as shown in fig. 1, the architecture at least includes an OCF client, an OCF bridging platform and at least one non-OCF device, that is, the bluetooth/zigbee protocol device in the figure. Several functional modules are included in the OCF bridge platform, virtual OCF services, bridge functions, and virtual clients corresponding to different protocols, such as the virtual bluetooth/zigbee protocol client in fig. 1. The mapping of different non-OCF protocols to OCF protocols is achieved by these several functional modules. Based on the above architecture, in the implementation of the prior art, the OCF client may initiate access to the non-OCF device through the non-OCF device corresponding device information or the vod information.

However, when a resource request is made from the OCF client to the non-OCF device, the non-OCF device may be disconnected, resulting in failure to access, and poor access efficiency.

Disclosure of Invention

The embodiment of the application provides a communication method, a device, equipment and a storage medium, which are used for solving the problem that non-OCF protocol equipment disconnected with a bridging platform cannot be successfully accessed because the non-OCF protocol equipment is disconnected at present when a resource request is carried out from an OCF client.

In a first aspect, an embodiment of the present application may provide a communication method, applied to a bridge device, where the bridge device is configured to implement a connection between an OCF client and at least one non-OCF device, where the method includes:

acquiring a connection state between a non-OCF device and the bridging device;

And carrying out updating processing according to the connection state, wherein the updating processing is used for updating the connection condition between the non-OCF equipment and the bridging equipment.

In a second aspect, an embodiment of the present application may provide a processing apparatus based on a device connection state, where the apparatus is configured to implement a connection between an OCF client and at least one non-OCF device, and the apparatus includes:

the acquisition module is used for acquiring the connection state between the non-OCF equipment and the bridging equipment;

And the processing module is used for carrying out updating processing according to the connection state, and the updating processing is used for updating the connection condition between the non-OCF equipment and the bridging equipment.

In a third aspect, embodiments of the present application may provide a bridging device, including:

A processor, a memory, an interface to communicate with other electronic devices;

the memory stores computer-executable instructions;

The processor executes computer-executable instructions stored in the memory to cause the processor to perform a communication method as provided in any of the embodiments of the first aspect.

In a fourth aspect, embodiments of the present application may provide a computer-readable storage medium having stored therein computer-executable instructions for implementing a communication method as provided by any of the embodiments of the first aspect when the computer-executable instructions are executed by a processor.

In a fifth aspect, embodiments of the present application may provide a chip, including: the communication device comprises a processor, a memory and a communication interface, wherein the processor is used for executing the communication method of the first aspect.

In a sixth aspect, embodiments of the present application may provide a computer program for performing the communication method of the first aspect when the computer program is executed by a processor.

In a seventh aspect, embodiments of the present application may provide a computer program product comprising: program instructions for implementing the communication method according to the first aspect.

The communication method, the device, the equipment and the storage medium provided by the embodiment of the application are mainly applied to bridging equipment, the bridging equipment is used for realizing the connection between the OCF client and the non-OCF equipment, the bridging equipment can acquire the connection state between the non-OCF equipment and the bridging equipment, and certain updating processing is carried out according to the connection state, so that when a user accesses through the OCF client, the connection state between the non-OCF equipment and the bridging equipment can be clearly confirmed, the access to the connected non-OCF equipment is ensured, the problem of access failure is avoided, and the access efficiency is effectively improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions of the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings may be obtained according to the drawings without inventive effort to a person skilled in the art.

FIG. 1 is a schematic diagram of a Bluetooth/Zigbee-to-OCF bridging architecture;

Fig. 2 is a schematic diagram of a bridging architecture of an OCF client and a non-OCF device according to the present application;

fig. 3 is a schematic flow chart of a first embodiment of a communication method according to the present application;

fig. 4 is a schematic flow chart of a second embodiment of a communication method according to the present application;

fig. 5 is a schematic flow chart of a third embodiment of a communication method provided by the present application;

Fig. 6 is an interaction schematic diagram of an OCF client and a non-OCF device based on a bridge device provided by the present application;

FIG. 7 is an interactive schematic diagram of an example of a communication method provided by the present application;

FIG. 8 is an interactive schematic diagram of another example of a communication method provided by the present application;

FIG. 9 is an interactive schematic diagram of yet another example of a communication method provided by the present application;

Fig. 10 is a schematic structural diagram of a first embodiment of a processing apparatus based on a device connection status according to the present application;

FIG. 11 is a schematic structural diagram of a second embodiment of a processing apparatus based on a device connection status according to the present application;

Fig. 12 is a schematic structural diagram of an embodiment of a bridge device according to the present application;

Fig. 13 is a schematic structural diagram of an embodiment of a bridging device according to the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

The terms first, second and the like in the description of embodiments of the application, in the claims and in the above-described figures, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the application described herein may be implemented, for example, in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

In the present application, it should be understood that "non-OCF protocol device" and "non-OCF device" are the same meaning and are used to describe devices employing non-OCF protocols, and that "non-OCF protocol device" and "non-OCF device" may be replaced with each other. The "bridge platform" is embodied in an electronic device, and may also be referred to as "bridge device" or "bridge device", which is not limited to this application.

Currently, there is a standard mapping relationship between bluetooth low energy (Bluetooth Low Energy, BLE) to an open interconnection foundation (Open Connectivity Foundation, OCF) protocol, and Zigbee to OCF protocol, and translation from other internet of things protocols to OCF protocol is completed by OCF bridging (Bridge), when a non-OCF device is disconnected, an OCF client can still discover device information corresponding to the non-OCF device disconnected from the bridging device, and still can see vod information of the non-OCF device under "/vodlist" (i.e., a device resource list) resources of the bridging device, that is, in an OCF client installed in a device used for control by a user, there is information virtually representing the non-OCF device through the bridging device, which may be referred to herein as information of a virtual OCF device, that is also referred to as vod information.

To sum up, in the prior art, after the non-OCF protocol device is disconnected:

As the OCF client can still find the device information corresponding to the non-OCF device disconnected from the bridge device through the bridge device, the resources of the non-OCF protocol device can still be operated;

The OCF client can still query the vod information corresponding to the non-OCF equipment disconnected from the bridge equipment through "/vodlist" resources in the bridge equipment;

In such a case, if the user accesses the non-OCF device through the OCF client, the access cannot be successful, resulting in access failure. And the user does not know that the non-OCF device is already offline, resulting in a poor user experience.

The application provides a processing method based on the connection state of equipment to solve the problems in the prior art. Specifically, the scheme can be executed in the bridging device, the bridging device can continuously or periodically acquire the connection state between the non-OCF devices connected with the bridging device, then change the device connection state based on the connection state, or modify the ports of the virtual OCF devices, so that the OCF client can accurately determine the state of the non-OCF devices during the access period of the virtual OCF devices, access failure caused by information errors is avoided, the access success rate is improved, and meanwhile, the user experience is improved.

The processing scheme based on the device connection state provided by the application is described in detail below through specific applications and embodiments.

Fig. 2 is a schematic diagram of a bridging architecture of an OCF client and a non-OCF device provided by the present application, where, as shown in fig. 2, the bridging architecture at least includes an OCF client and one or more non-OCF devices, for example, a bluetooth protocol device and a zigbee protocol device in the figure, connection between the non-OCF device and the OCF client is implemented by the bridging device, interaction is implemented between the OCF client and the bridging device by an OCF protocol, and interaction is implemented between the bridging device and different non-OCF devices by different non-OCF protocols. The bridge device is mainly used for carrying out protocol conversion and realizing interaction among devices with different protocols.

In this scenario, it should be understood that the OCF client may be installed on a terminal device of a user's mobile phone, a computer, a tablet computer, a smart bracelet, a smart watch, or the like as a control device, so as to implement control of a non-OCF device through a bridging device, and the present application is not limited to a specific control device configuration. In the technical solution of the embodiment of the present application, it should also be understood that the implementation step of the OCF client in the solution is actually implemented on the various types of terminal devices as the control device, and if necessary, the OCF client may be directly replaced by the terminal device, which is not limited in this aspect of the present application.

Fig. 3 is a schematic flow chart of a first embodiment of a communication method provided by the present application, as shown in fig. 3, which can be at least applied to the scenario shown in fig. 2, where the scheme is mainly applied to a bridging device, and specifically includes the following steps:

S101: and acquiring the connection state between the non-OCF device and the bridging device.

In this step, the bridge device may connect to one or more non-OCF devices, where the non-OCF devices may be newly connected devices, or may be reconnected after being offline, which is not limited in this scheme.

In the specific application process, the bridge device can periodically acquire the state of the connected non-OCF device, and also can acquire the state of the non-OCF device in real time, so as to determine whether the non-OCF device is in a connected state or has changed from the connected state to an offline state.

The manner of obtaining the connection state of the non-OCF device is not limited in this embodiment, and specifically may at least include the following ways:

In a first mode, the bridge device sends an instruction to the non-OCF device, if the acknowledgement message or the feedback information is received within a preset time period, the non-OCF device is determined to be in a connected state, and if no feedback is received for a long time period, the non-OCF device is determined to be disconnected and is determined to be in an offline state.

And secondly, actively transmitting a heartbeat packet by the non-OCF device, if the bridge device does not receive the heartbeat packet of the non-OCF device within a period of time, determining that the non-OCF device is disconnected, and if the bridge device can periodically or continuously receive the heartbeat packet of the non-OCF device, determining that the non-OCF device is in a connected state.

Specifically, according to the above manner, it can be known that, as long as the bridging device can receive the data packet sent by the non-OCF device within a certain time interval, the non-OCF device can be confirmed to be in a connection state; if no data packet is received for a longer period of time, the non-OCF device is determined to be in an offline state. The data packet may be a heartbeat data packet, an instruction, or other interactive data, and the application is not limited by what type of data is specific.

It should be understood that, in the embodiment of the present application, the meaning of "heartbeat packet", "heartbeat data" and "heartbeat data packet" are the same, and may be directly replaced with each other.

Optionally, in a specific implementation, in order to save energy consumption and reduce data processing pressure, the bridge device may acquire a connection state between the non-OCF device and the bridge device according to a preset time interval.

In this implementation of the solution, the preset time interval may be determined by a time interval during which the non-OCF device transmits the heartbeat packet or the heartbeat data, where the preset time interval should be at least greater than a time interval during which the non-OCF device transmits the heartbeat data.

S102: and carrying out updating processing according to the connection state, wherein the updating processing is used for updating the connection condition between the non-OCF equipment and the bridging equipment.

In the step, after the bridge device obtains the connection state of a certain non-OCF device, a certain update process is required, which mainly aims to enable the OCF client to accurately determine the state of the non-OCF device when determining that the non-OCF device needs to be accessed, at least the connection state of the non-OCF device may be changed, or the port of the virtual OCF device in the bridge device may be modified, so that the OCF client may not find the non-OCF device that is offline or timely find the non-OCF device that is online, or may also combine the two processes simultaneously.

According to the communication method provided by the embodiment, the bridging device is used for realizing connection between the OCF client and the non-OCF device, the bridging device can acquire the connection state between the non-OCF device and the bridging device, and performs certain updating processing according to the connection state, so that when a user accesses through the OCF client, the connection state between the non-OCF device and the bridging device can be clearly confirmed, the non-OCF device connected is ensured to be accessed, the problem of access failure is avoided, and the access efficiency is improved.

In all embodiments of the present application, it should be understood that the non-OCF device in the device resource list may be directly represented by information of the non-OCF device, or may be represented by information of a virtual OCF device mapped by the non-OCF device, which is for the purpose of representing the non-OCF device. The information in the device resource list is mainly for the purpose that the user can confirm the connection status of the non-OCF device to be controlled from the OCF client, and is not limited to what type of information is specifically.

Fig. 4 is a schematic flow chart of a second embodiment of a communication method provided by the present application, as shown in fig. 4, in which, in this case, a non-OCF device is disconnected due to a device disconnection, a power outage, or a manual shutdown, and the scheme provided by the present embodiment includes the following steps:

s201: and acquiring the connection state between the non-OCF equipment and the bridging equipment, and changing from connection to offline.

In this step, the bridge device may determine the connection state with the non-OCF device according to the heartbeat packet or the heartbeat data sent by the non-OCF device, or may actively send an instruction to determine the connection state with the non-OCF device according to the feedback condition, or may determine the connection state by other detection methods, which is not limited in this application.

For example, if no heartbeat packet or heartbeat data sent by the non-OCF device is received within a preset duration or within several heartbeat periods, it may be determined that the non-OCF device is in an offline state.

S202: and deleting the non-OCF device in the device resource list, or setting the connection state of the non-OCF device in the device resource list to be an offline state.

In this step, after the bridge device has acquired that the connection state of the non-OCF device is changed to offline, the non-OCF device may be deleted in the device resource list of the locally managed OCF device corresponding to the non-OCF device, or the state of the non-OCF device may be set to offline state in the device resource list.

After the updating process, when the user accesses the non-OCF device through the bridge device from the OCF device, the obtained device resource list does not include the non-OCF device in the offline state, or the device resource list marks the connection state of the offline non-OCF device, and the non-OCF device is marked to be in the offline state. At the moment, the user can directly determine which devices are online and which devices are offline, so that the user experience is improved, and the user is prevented from selecting to access the offline non-OCF devices.

In addition to the update processing performed in the processing manner in step S202 described above, the update processing may be performed in the following step S203, or the update processing may be performed in combination of both steps S202 and S203.

S203: the ports of the virtual OCF device mapped to the non-OCF device are configured so that the OCF client cannot search for the non-OCF device.

In this step, after the bridge device has obtained that the connection state of the non-OCF device is changed to offline, the virtual OCF device corresponding to the offline non-OCF device may be determined according to the mapping relationship between the non-OCF device and the virtual OCF device. The bridge device then modifies the port of the virtual OCF device to 0, or other ports of the off-line non-OCF device that cannot be searched by the OCF client. After the processing mode is adopted, when a user accesses non-OCF equipment through the OCF client, the information of the non-OCF equipment cannot be searched, so that the access to the off-line non-OCF equipment is effectively avoided, and the access failure caused by the off-line equipment is avoided.

In an alternative embodiment, after the bridge device performs the above processing based on the connection state of the non-OCF device, the OCF client accesses the non-OCF device based on the device resource list, and therefore, the OCF client needs to acquire the device resource list. At this time, the ways for the OCF client to obtain the device resource list at least include two ways:

First, the bridging device directly performs step S2022: and sending a device resource list to the OCF client, wherein the device resource list is the list after the connection state processing based on the non-OCF device in the step.

Second, after the bridge device processes the device resource list based on the connection state of the non-OCF device, the bridge device returns the list when the OCF client requests to obtain the list. Specifically, the bridging device may perform steps S2021 and S2022.

Step S2021: and receiving a device resource list acquisition request sent by the OCF client.

Step S2022: and sending the device resource list to the OCF client.

Based on the above scheme, in the specific implementation of the scheme, the Bridge device between the OCF client and the non-OCF device (such as Zigbee, BLE, etc.) has a main function of performing protocol conversion, and may also be a Bridge platform (hereinafter referred to as Bridge), to process heartbeat data from the non-OCF device at fixed time. When the non-OCF device is disconnected from the Bridge, the heartbeat data of the non-OCF device is not reported any more, and at this time, a multicast port number of a virtual OCF device corresponding to the non-OCF device in the Bridge is set to 0 or cannot be found, and/or an online state in the vod information corresponding to the non-OCF device under a Bridge device "/vodlist" (device resource list) resource in the Bridge may also be set to false; so that the OCF client cannot discover information corresponding to the Bridge disconnected non-OCF device.

In the communication method provided by the embodiment, after the bridge device obtains that the non-OCF device is offline, based on the offline state, the information of the offline non-OCF device in the device resource list is deleted or the state thereof is set to the offline state, or the port may be further configured, so that the OCF device client cannot search for the offline non-OCF device, thereby avoiding the problem that the user accesses when the user does not know that the non-OCF device is offline, resulting in access failure. Meanwhile, the access efficiency can be improved and the user experience can be improved through the mode.

Fig. 5 is a schematic flow chart of a third embodiment of a communication method provided by the present application, as shown in fig. 5, in which after a non-OCF device fails, a connection is re-established with a bridge device, or in the case that a new non-OCF device establishes a connection with the bridge device, the scheme provided by the present embodiment includes the following steps:

S301: and acquiring that the non-OCF equipment and the bridging equipment are connected, or changing the connection state between the non-OCF equipment and the bridging equipment from off-line to on-line.

In this step, the bridge device may receive a connection request initiated by the non-OCF device, or mainly search for a non-OCF device to be connected, perform connection data interaction, and perform network address allocation and the like to confirm the connection state, and then determine the connection state of the newly-online non-OCF device.

The connection state between the non-OCF device and the non-OCF device can be determined according to the heartbeat packet or the heartbeat data sent by the non-OCF device, the connection state between the non-OCF device and the non-OCF device can be determined according to the feedback condition by actively sending the instruction, or the connection state can be determined by other detection modes, so that the application is not limited. For example, if heartbeat data sent by a non-OCF device is periodically received, the non-OCF device is determined to be in a connected state.

S302: and adding non-OCF equipment in the equipment resource list, or setting the connection state of the non-OCF equipment in the equipment resource list to be in an on-line state.

In this step, after the bridge device determines that a new non-OCF device establishes connection, that is, determines that the state of the non-OCF device is online, first, a mapping relationship between a virtual OCF device and a non-OCF device is established, and then information of the non-OCF device is added to a device resource list of the corresponding OCF device, or information of the virtual OCF device corresponding to the non-OCF device may be added.

Or the bridge device detects that the offline non-OCF device is on-line again, the connection state of the non-OCF device (or the corresponding virtual OCF device) in the device resource list may be set to an on-line state. So that the user can select the online non-OCF device to access when accessing the non-OCF device through the OCF client.

In addition to the update processing performed in the processing manner in step S302 described above, the update processing may be performed in the manner in step S303 described below, or the update processing may be performed in combination of both steps S302 and S303.

S303: the port numbers of the virtual OCF devices mapped with the non-OCF devices are configured so that the OCF client can search for the non-OCF devices.

In this step, after the bridge device has obtained that the connection state of the non-OCF device is changed to online, or after the new non-OCF device establishes connection, the virtual OCF device corresponding to the offline non-OCF device may be determined according to the mapping relationship between the non-OCF device and the virtual OCF device. And the bridge equipment modifies the port of the virtual OCF equipment into a port number specified by a broadcast protocol, so that the OCF client can search the port of the OCF equipment. After the processing mode is adopted, when a user accesses non-OCF equipment through the OCF client, the information of the non-OCF equipment can be searched.

First, the bridging device directly performs step S3022: and sending a device resource list to the OCF client, wherein the device resource list is the list after the connection state processing based on the non-OCF device in the step.

Step S3021: and receiving a device resource list acquisition request sent by the OCF client.

Step S3022: and sending the device resource list to the OCF client.

Based on the above scheme, in the specific implementation of the scheme, after the non-OCF device re-accesses the Bridge, the multicast port number of the virtual OCF protocol device corresponding to the non-OCF device is set to 5683 or 5684, or may be a port number specified by another broadcast protocol, which is not limited. And/or, setting a virtual OCF device online state corresponding to the non-OCF device to true under a Bridge device "/vodlist" (device resource list) resource in Bridge; enabling OCF clients to discover non-OCF devices that reconnect to Bridge.

In the communication method provided by the embodiment, after the bridge device obtains that the non-OCF device is recovered offline or is newly on line, based on the connection state, the non-OCF device is added to the device resource list or the state of the non-OCF device is set to be an on-line state, or the port can be configured, so that the OCF client can search the non-OCF device, thereby facilitating the user to determine the state of the non-OCF device for access, improving the access efficiency and improving the user experience.

Based on the schemes provided by the above embodiments, the communication method provided by the present application is exemplified below by several specific examples.

In the following embodiment, the bridge device includes several modules of a bridge device, a virtual OCF service (virtual OCF server), a bridge platform, and a virtual non-OCF client (virtual non OCF client).

Fig. 6 is an interaction schematic diagram of an OCF client and a non-OCF device based on a bridge device provided by the present application, and as shown in fig. 6, the interaction process between the OCF client and the non-OCF device is specifically as follows.

The bridge module of the bridge device creates a device resource list of the bridge device between the OCF client and the bridge device, where the device resource list may be an integral list, or may be a device resource list for each OCF client, which is not limited in this scheme.

The bridge module of the bridge device receives the request of the OCF client and returns bridge device information to the OCF client. If the OCF client needs to access a non-OCF device, a device resource list acquisition request may be sent to the bridge device to return the bridge device to its device resource list.

Between the bridge device and the non-OCF device, the virtual non-OCF client of the bridge device receives a beacon request sent by the non-OCF device through the scanning or discovery device, and then returns data to the non-OCF device based on the beacon request. The non-OCF device sends an associated network request to the bridging device. The virtual non-OCF client of the bridging device assigns a network address to the discovered non-OCF device and then returns data containing the network address to the non-OCF device. After the non-OCF device completes network connection, a network connection state confirmation message is returned to the bridge device, and connection establishment between the bridge device and the non-OCF device is completed.

In the bridging device, after the non-OCF device and the bridging device complete connection establishment, the virtual non-OCF client sends a message for finding that the non-OCF protocol device is completed to the bridged platform, the bridged platform interacts with the virtual OCF service again, a corresponding virtual OCF device is created, and a mapping relation between the virtual OCF device and the non-OCF device is established. The virtual OCF service informs the bridge module to add device information, that is to say, the created vod information of the non-OCF device is stored in the device resource list, and may also be directly represented by the information of the non-OCF device, which is not limited.

In the subsequent access process, after the OCF client acquires the device resource list, the OCF client sends a resource access request to the virtual OCF device in the bridge device through the device resource list, the bridge device acquires the non-OCF device according to the mapping relation, and then the state information of the non-OCF device is accessed. And the non-OCF equipment sequentially returns the state information to the bridged platform, converts the state information of the non-OCF protocol into resource attribute information of the OCF protocol according to the corresponding relation between protocols, and returns the resource attribute information to the OCF client.

Fig. 7 is an interaction schematic diagram of an example of a communication method provided by the present application, as shown in fig. 7, on the basis of the interaction process shown in fig. 6, the interaction process between an OCF client and a non-OCF device provided by the present application is specifically as follows.

After the non-OCF device establishes a connection with the bridge device in accordance with the aforementioned connection procedure:

s401: establishing a mapping relation, wherein the step illustrates that establishing the mapping relation between the virtual OCF equipment and the non-OCF equipment is a precondition of the whole scheme.

S402: and setting a timer for the non-OCF equipment according to the set heartbeat packet sending time.

In a specific implementation of this step, assuming that the time interval for reporting the heartbeat data by the non-OCF device is 5s, the timer time set in Bridge needs to be not lower than the heartbeat data reporting time interval, for example, not lower than 5 heartbeat data reporting time intervals may be set, so as to indicate that the non-OCF device is completely disconnected from Bridge when no heartbeat data is received for more than 5 times.

S403: the non-OCF device periodically transmits heartbeat packets. In this step, the non-OCF device is set to send heartbeat data, that is, the heartbeat packet, at a certain time interval, so that the bridge device detects the connection state.

S404-S405: the bridge platform receives the heartbeat packet data notification, if the timer is not overtime at the moment, the timer is reset, timing is restarted, and the timer is ensured not to overtime;

S406: the non-OCF device disconnects and no heartbeat packet is sent.

S407-S408: and (5) overtime the timer, performing overtime processing, and setting the connection state of the non-OCF equipment to be offline.

In the above step, when the non-OCF device is disconnected from Bridge, the timer in Bridge is overtime, and the overtime time of the timer needs to be set to infinity, and the timer will not overtime at this time; the online status of non-OCF devices in Bridge is then set to offline status (KEEP ALIVE- > non alive).

S409-S410: the non-OCF device may also set the port of the virtual OCF device corresponding to the non-OCF device to 0. I.e., the port number of the multicast of the virtual OCF device corresponding to the off-line non-OCF device is set to 0.

S411-S412: and the bridge module receives the offline notification of the non-OCF device and sets the non-OCF device in the device resource list to be in an offline state. In this step, an online corresponding to the non-OCF device under the/vodlist resource in the bridge device is set to false, which indicates that the current non-OCF device is offline.

S413: and sending the processed equipment resource list to the OCF client.

Alternatively, in another implementation of this solution, based on the solution shown in fig. 7, after the non-OCF protocol device is disconnected from Bridge, several steps may be implemented as follows:

The "S411" step is modified to: and disconnecting the mapping relation between the offline non-OCF device and the virtual OCF device, and deleting the non-OCF protocol device in the Bridge device.

The "S412" step is modified to: and deleting the vod information corresponding to the offline non-OCF device under the resources of the bridging device resource list (/ vodlist), so that the OCF client cannot find the virtual OCF device corresponding to the offline non-OCF device and cannot access the non-OCF device through the bridging device.

In this example, in a Bridge device (Bridge) of an OCF protocol and a non-OCF protocol, processing heartbeat data from a non-OCF protocol device at a virtual non-OCF protocol client side at fixed time, establishing a timeout mechanism according to a heartbeat data timing transmission time, setting a timer not less than 5 times of the heartbeat data reporting time according to the heartbeat data reporting time, and entering timeout processing if the timer is overtime; and setting a multicast port number of the OCF protocol equipment corresponding to the non-OCF protocol equipment at the virtual OCF server according to the overtime processing condition of the timer, if the timer is overtime, the multi cast port number is set to 0 at the moment, so that the OCF client cannot find the non-OCF protocol equipment, and access failure caused by the fact that the non-OCF protocol equipment is offline in the process of accessing the non-OCF protocol equipment by the user through the OCF client is avoided.

Fig. 8 is an interaction schematic diagram of another example of the communication method provided by the present application, as shown in fig. 8, on the basis of the interaction process shown in fig. 6, the interaction process between the OCF client and the non-OCF device provided by the present application is specifically as follows.

S501: non-OCF devices re-enter the network.

S502-S503: the platform of the bridging device sets the state of the non-OCF device to be online, and sets a timer for the non-OCF device according to the set heartbeat packet sending time interval.

In the above step, after the non-OCF device re-establishes a connection with the Bridge, the online state of the non-OCF device needs to be set to online (non active- > KEEP ALIVE) in the Bridge; the timer of the non-OCF device is then set by an infinite time to a time not lower than the time interval of sending the heartbeat packet, for example, may be set to 5 times the time interval of non-OCF device heartbeat packet or heartbeat data reporting.

S504: the bridge device sets the port number of the virtual OCF device corresponding to the non-OCF device to 5683. That is, the multicast port number of the virtual OCF device corresponding to the non-OCF device is set to 5683 so that the OCF client can rediscover the non-OCF device and access.

S505 to S506: and notifying to modify the vod, and setting an online in the vod information corresponding to the non-OCF device under the device resource list (/ vodlist) resource of the bridge device to be true to indicate that the non-OCF device represented by the online is online.

In the subsequent execution process, the bridge device follows the scheme shown in S507-S509, so as to be able to acquire the connection state of the non-OCF device in time.

In the solution provided by the example shown in fig. 8, on the basis of the example shown in fig. 7, when the timer is not timed out or the non-OCF device re-establishes a connection with the Bridge device (Bridge), a multicast port of the virtual OCF device corresponding to the non-OCF device is set to 5683, so that the OCF client can always access the non-OCF device connected to the Bridge device.

Fig. 9 is an interaction schematic diagram of still another example of the communication method provided by the present application, as shown in fig. 9, where the example is a subsequent implementation of an alternative implementation of the solution shown in fig. 7, where the mapping relationship between the offline non-OCF device and the virtual OCF device is disconnected, and after the non-OCF device is deleted in the bridging device. If the non-OCF device is on-line again, that is, for the non-OCF protocol device reestablishing the connection with the Bridge device (Bridge), the mapping relationship between the virtual OCF device and the non-OCF device needs to be reestablished, and the configuration operations of S601-S603 in the flow shown in fig. 9 need to be performed again.

In the subsequent execution process, the bridging device follows the scheme shown in S604-S606, so as to be able to acquire the connection state of the non-OCF device in time.

Based on the above embodiments and examples, it can be known that in the communication method provided by the embodiment of the present application, the bridge device can obtain the connection state between the non-OCF device and the bridge device, and perform a certain process according to the connection state, and perform state remarks on the offline state of the non-OCF device, or directly delete the offline state of the non-OCF device, so as to avoid the problem that the OCF client can also access the disconnected non-OCF device to cause access failure. For the non-OCF equipment which is online or online again, the online equipment is reset, and the scheme can effectively improve the access efficiency, so that the user experience is improved.

Fig. 10 is a schematic structural diagram of a first embodiment of a device connection state-based processing apparatus according to the present application, as shown in fig. 10, where the device is configured to implement connection between an OCF client and at least one non-OCF device, and the device connection state-based processing apparatus 10 includes:

an obtaining module 11, configured to obtain a connection state between a non-OCF device and the bridge device;

and the processing module 12 is configured to perform an update process according to the connection status, where the update process is used to update the connection status between the non-OCF device and the bridge device.

Optionally, if the connection status of the first non-OCF device is changed from connected to offline, the processing module 12 is specifically configured to:

deleting the first non-OCF device in the device resource list, or setting the connection state of the first non-OCF device in the device resource list to be an offline state;

and/or the number of the groups of groups,

And configuring a port of the virtual OCF device mapped with the first non-OCF device so that the OCF client cannot search for the first non-OCF device.

Optionally, if the second non-OCF device establishes a connection with the bridge device, or the connection state of the second non-OCF device is changed from offline to online, the processing module 12 is specifically configured to:

Adding the second non-OCF equipment in an equipment resource list, or setting the connection state of the second non-OCF equipment in the equipment resource list to be an on-line state;

and/or the number of the groups of groups,

And configuring the port number of the virtual OCF device mapped with the second non-OCF device so that the OCF client can search the second non-OCF device.

Optionally, the acquiring module 11 is specifically configured to:

and acquiring the connection state between the non-OCF equipment and the bridging equipment according to a preset time interval.

Optionally, the acquiring module 11 is specifically configured to:

If the heartbeat data packet sent by the non-OCF equipment is not received within the preset time interval, determining that the non-OCF equipment is in an offline state;

and if the heartbeat data packet sent by the non-OCF equipment is received in the preset time interval, determining that the non-OCF equipment is in an on-line state.

Optionally, the preset time interval is greater than a time interval for the non-OCF device to send the heartbeat packet.

Optionally, the processing module 12 is further configured to:

And after any non-OCF device establishes connection with the bridging device, creating a mapping relation between the non-OCF device and the virtual OCF device.

The processing apparatus based on the device connection state provided in any of the foregoing embodiments is used to implement the technical scheme in the bridging device in any of the foregoing method embodiments, and the implementation principle and the technical effect are similar, and are not repeated herein.

Fig. 11 is a schematic structural diagram of a second embodiment of a processing apparatus based on a device connection state according to the present application, as shown in fig. 11, on the basis of the foregoing embodiment, the processing apparatus 10 based on a device connection state further includes:

a receiving module 13, configured to receive a device resource list acquisition request sent by an OCF client;

And a sending module 14, configured to send a device resource list to the OCF client according to the device resource list acquisition request.

Alternatively, only the sending module 14 may be included, so as to send the updated device resource list to the OCF client.

Fig. 12 is a schematic structural diagram of an embodiment of a bridge device according to the present application, and as shown in fig. 12, the bridge device 100 at least includes:

A processor 111, an interface 112 to communicate with other electronic devices, and a memory 113;

The memory 113 stores computer-executable instructions;

The processor 111 executes computer-executable instructions stored in the memory 113, so that the processor 111 executes the scheme of the communication method provided in any of the foregoing embodiments.

Fig. 12 is a simple design of a bridge device, and the number of processors and memories in the device is not limited by the embodiment of the present application, and fig. 12 is only illustrated with the number 1 as an example.

In a specific implementation of the bridge device shown in fig. 12, the memory, the processor and the interface may be connected by a bus, and optionally, the memory may be integrated inside the processor.

The present application also provides a computer-readable storage medium having stored therein computer-executable instructions for implementing the scheme of the communication method provided by any of the foregoing method embodiments when the computer-executable instructions are executed by a processor.

Fig. 13 is a schematic structural diagram of an embodiment of a chip according to the present application, as shown in fig. 13, the chip 200 at least includes: the processor 210, the memory 220 and the communication interface (the input interface 230 and the output interface 240), the processor 210 is configured to execute the technical solution of the communication method provided by any one of the foregoing method embodiments.

The application also provides a computer program which is used for executing the technical scheme of the communication method provided by any method embodiment when being executed by a processor.

The present application also provides a computer program product comprising: program instructions for implementing the technical solution of the communication method provided in any one of the foregoing method embodiments.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, the division of the modules is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple modules may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection of modules, electrical, mechanical, or other forms.

In the specific implementation of the bridge device described above, it should be understood that the Processor may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (DIGITAL SIGNAL Processor, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the present application may be embodied directly in a hardware processor for execution, or in a combination of hardware and software modules in a processor for execution.

All or part of the steps for implementing the method embodiments described above may be performed by hardware associated with program instructions. The foregoing program may be stored in a readable memory. The program, when executed, performs steps including the method embodiments described above; and the aforementioned memory (storage medium) includes: read-only Memory (ROM), RAM (Random Access Memory), flash Memory, hard Disk, solid state Disk, magnetic tape (MAGNETIC TAPE), floppy Disk (Floppy Disk), optical Disk (Optical Disk), and any combination thereof.

Claims

1. A method of communication, for use with a bridging device for enabling a connection between an open interconnection foundation OCF client and at least one non-OCF device, the method comprising:

acquiring a connection state between a non-OCF device and the bridging device;

updating according to the connection state, wherein the updating is used for updating the connection condition between the non-OCF equipment and the bridging equipment;

And sending the updated device resource list to the OCF client, wherein the device resource list comprises information for confirming the connection state of the non-OCF device and the bridging device.

2. The method of claim 1, wherein if the connection status of the first non-OCF device changes from connected to offline, the updating according to the connection status comprises:

3. The method of claim 1, wherein if a second non-OCF device establishes a connection with the bridge device or a connection state of the second non-OCF device changes from offline to online, the updating according to the connection state comprises:

Adding the second non-OCF equipment in the equipment resource list, or setting the connection state of the second non-OCF equipment in the equipment resource list to be an on-line state;

and configuring a port of the virtual OCF device mapped with the second non-OCF device so that the OCF client can search for the second non-OCF device.

4. The method of claim 1, wherein the obtaining the connection state between the non-OCF device and the bridge device comprises:

5. The method of claim 4, wherein the obtaining the connection state between the non-OCF device and the bridge device according to the preset time interval comprises:

if the data packet sent by the non-OCF equipment is not received within the preset time interval, determining that the non-OCF equipment is in an offline state;

and if the data packet sent by the non-OCF equipment is received within the preset time interval, determining that the non-OCF equipment is in an on-line state.

6. The method of claim 4, wherein the predetermined time interval is greater than a time interval during which a non-OCF device transmits data packets.

7. The method according to any one of claims 1 to 6, further comprising:

8. The method of any of claims 1 to 6, wherein the sending the updated device resource list to the OCF client comprises:

Receiving a device resource list acquisition request sent by the OCF client;

And sending the updated equipment resource list to the OCF client according to the equipment resource list acquisition request.

9. A processing apparatus based on a device connection status, applied to a bridging device, the apparatus being configured to implement a connection between an OCF client and at least one non-OCF device of an open interconnection foundation, the apparatus comprising:

The processing module is used for carrying out update processing according to the connection state, and the update processing is used for carrying out update state on the connection condition between the non-OCF equipment and the bridging equipment;

And the sending module is used for sending the updated equipment resource list to the OCF client, wherein the equipment resource list comprises information for confirming the connection state of the non-OCF equipment and the bridging equipment.

10. The apparatus of claim 9, wherein if the connection status of the first non-OCF device changes from connected to offline, the processing module is specifically configured to:

11. The apparatus of claim 9, wherein the processing module is specifically configured to:

12. The apparatus of claim 9, wherein the obtaining module is specifically configured to:

13. The apparatus of claim 12, wherein the obtaining module is specifically configured to:

14. The apparatus of claim 12, wherein the predetermined time interval is greater than a time interval during which a non-OCF device transmits heartbeat packets.

15. The apparatus of any one of claims 9 to 14, wherein the processing module is further configured to:

16. The apparatus according to any one of claims 9 to 14, further comprising:

the receiving module is used for receiving a device resource list acquisition request sent by the OCF client;

Correspondingly, the sending module is specifically configured to send the updated device resource list to the OCF client according to the device resource list obtaining request.

17. A bridging device, comprising:

the memory stores computer-executable instructions;

The processor executing computer-executable instructions stored in the memory, causing the processor to perform the communication method of any one of claims 1 to 8.

18. A computer-readable storage medium, in which computer-executable instructions are stored, which when executed by a processor are adapted to implement the communication method of any one of claims 1 to 8.

19. A chip, comprising: a processor, a memory and a communication interface, the processor being configured to perform the communication method of any of claims 1 to 8.

20. A computer program product, comprising: program instructions for implementing the communication method of any one of claims 1 to 8.