CN114846901A

CN114846901A - Communication method, device, equipment and storage medium

Info

Publication number: CN114846901A
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: 2022-08-02
Anticipated expiration: 2040-02-18
Also published as: WO2021163891A1; CN114846901B

Abstract

The embodiment of the application provides a communication method, a communication device and a storage medium, which are mainly applied to bridge equipment, wherein the bridge equipment is used for realizing connection between OCF equipment and non-OCF equipment, the bridge equipment can acquire the connection state between the non-OCF equipment and the bridge equipment and perform 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 bridge equipment can be clearly confirmed, the connected non-OCF equipment 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 internet of things, in particular to a communication method, a communication device, communication equipment and a storage medium.

Background

The Internet of Things (IoT) is to collect any object or process needing monitoring, connection and interaction in real time and collect various required information through various devices and technologies such as various information sensors, radio frequency identification technologies, global positioning systems, infrared sensors and laser scanners, and to realize ubiquitous connection between objects and people through various possible network accesses, thereby realizing intelligent sensing, identification and management of objects and processes. With the development of the technology of the internet of things, communication among devices of various protocol types is gradually realized.

At present, in a communication process of an internet of things device, interconnection of different devices may be achieved through a bridging mode, fig. 1 is a schematic diagram of a bridging architecture from a bluetooth/zigbee protocol to an 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, a bluetooth/zigbee protocol device in the drawing. The OCF bridge platform comprises several functional modules, a virtual OCF service, a bridge function 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 implemented 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 device information corresponding to the non-OCF device 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, which may result in unsuccessful access and poor access efficiency.

Disclosure of Invention

Embodiments of the present application provide a communication method, an apparatus, a device, and a storage medium, which are used to solve the problem that when a resource request is made from an OCF client to a non-OCF protocol device disconnected from a bridge platform, the non-OCF protocol device cannot be successfully accessed because the non-OCF protocol device is disconnected.

In a first aspect, an embodiment of the present application may provide a communication method, which is 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, and the method includes:

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

and performing update processing according to the connection state, wherein the update processing is used for updating the connection condition between the non-OCF device and the bridge device.

In a second aspect, an embodiment of the present application may provide an apparatus for processing based on a device connection status, 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 performing update processing according to the connection state, and the update processing is used for updating the connection condition between the non-OCF device and the bridge device.

In a third aspect, an embodiment 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 the computer-executable instructions stored by the memory, so that the processor executes the communication method provided by any one of the embodiments of the first aspect.

In a fourth aspect, embodiments of the present application may provide a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the computer-readable storage medium is configured to implement the communication method as provided in any implementation manner of the first aspect.

In a fifth aspect, an embodiment of the present application may provide a chip, including: a processor, a memory and a communication interface, the processor being configured to perform the communication method of the first aspect.

In a sixth aspect, embodiments of the present application may provide a computer program, which is configured to execute the communication method according to the first aspect when the computer program is executed by a processor.

In a seventh aspect, an embodiment of the present application may provide a computer program product, including: program instructions for implementing the communication method of the first aspect.

The communication method, the communication device, the communication 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 an OCF client and non-OCF equipment, the bridging equipment can acquire the connection state between the non-OCF equipment and the bridging equipment and perform 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 equipment and the bridging equipment can be clearly confirmed, the connected non-OCF equipment is guaranteed to be accessed, 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 in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to these drawings without inventive exercise.

FIG. 1 is a schematic diagram of a bridge architecture from a Bluetooth/Zigbee protocol to an OCF protocol;

fig. 2 is a schematic diagram of a bridging architecture of an OCF client and a non-OCF device provided in the present application;

fig. 3 is a flowchart illustrating a first communication method according to an embodiment of the present disclosure;

fig. 4 is a flowchart illustrating a second embodiment of a communication method provided in the present application;

fig. 5 is a schematic flowchart of a third embodiment of a communication method provided in the present application;

fig. 6 is an interaction diagram of an OCF client and a non-OCF device based on a bridge device according to the present application;

FIG. 7 is an interaction diagram of an example of a communication method provided herein;

FIG. 8 is an interaction diagram of another example of a communication method provided herein;

FIG. 9 is an interaction diagram of yet another example of a communication method provided herein;

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

fig. 11 is a schematic structural diagram of a second processing apparatus according to an embodiment of the present application, where the processing apparatus is based on a device connection state;

fig. 12 is a schematic structural diagram of an embodiment of a bridging device provided in the present application;

fig. 13 is a schematic structural diagram of an embodiment of a bridging device provided in the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terms "first," "second," and the like in the description and in the claims, and in the drawings, of the embodiments of the application are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are, for example, capable of operation 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 is understood that "non-OCF protocol device" and "non-OCF device" are the same meaning and are used to describe devices that employ non-OCF protocols, and that "non-OCF protocol device" and "non-OCF device" may be substituted for each other. The "bridge platform" is specifically implemented in an electronic device, and may also be referred to as a "bridge device" or a "bridge device", and the like, which is not limited in this application.

Currently, a Bluetooth Low Energy (BLE) to Open interconnection Foundation (OCF) protocol and a mapping relation standard between a Zigbee protocol (Zigbee) and an OCF protocol exist, a translation work from other internet of things protocols to the OCF protocol is completed by an OCF Bridge (Bridge), when a non-OCF device is dropped, the OCF client can still find device information corresponding to the non-OCF device disconnected from the Bridge device, and can still see vod information of the non-OCF device under "/voip" (i.e., a device resource list) resource of the Bridge device, that is, in the OCF client installed in a device used for control by a user, information representing the non-OCF device through a Bridge virtual device also exists, and here, the information can become information of the virtual OCF device, which is also referred to as vod information.

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

as an OCF client, the device information corresponding to the non-OCF device disconnected with the bridge device can still be discovered through the bridge device, and the resource of the non-OCF protocol device can still be operated;

as an OCF client, the vod information corresponding to the non-OCF device disconnected with the bridge device can still be inquired from the "/vod" resource in the bridge device;

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

In view of the above problems in the prior art, the present application provides a method for processing a connection status of a device, so as to solve the above problems. Specifically, the scheme can be executed in the bridge device, the bridge device can continuously or periodically acquire the connection state between the non-OCF devices connected with the bridge device, and 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 of the virtual OCF devices, thereby avoiding access failure caused by information error, improving the access success rate, and improving the user experience.

The following describes in detail a processing scheme based on a device connection status provided by the present application 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 in this application, as shown in fig. 2, the bridging architecture at least includes an OCF client and one or more non-OCF devices, such as a bluetooth protocol device and a zigbee protocol device in the figure, connection between a non-OCF device and an OCF client is implemented by a bridging device, an OCF client and a bridging device interact with each other through an OCF protocol, and a bridging device and different non-OCF devices interact with each other through different non-OCF protocols. The bridge device mainly functions to perform protocol conversion and realize interaction between devices with different protocols.

In this scenario, it should be understood that the OCF client may be installed on a terminal device, such as a mobile phone, a computer, a tablet computer, an intelligent bracelet, and an intelligent watch of a user, which are used as a control device, to implement control of a non-OCF device through a bridge device, and the application is not limited to a specific control device form. In the technical solution of the embodiment of the present application, it should be further understood that the implementation steps of the OCF client in the solution are actually implemented on various types of terminal devices serving as the control device, and the OCF client may be directly replaced by a terminal device if necessary, which is not limited in the present application.

Fig. 3 is a schematic flow diagram of a first embodiment of a communication method provided in the present application, and as shown in fig. 3, the method may be applied to at least the scenario shown in fig. 2, where the scheme is mainly applied to a bridge 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, and this scheme is not limited in this respect.

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

The method for acquiring the connection state of the non-OCF device is not limited in this embodiment, and may specifically include at least the following methods:

the method one is that the bridge device sends an instruction to the non-OCF device, if the confirmation message or the feedback information is received within a preset time length, it is determined that the non-OCF device is in a connected state, and if no feedback is received for a long time, it is determined that the non-OCF device is disconnected and is in an offline state.

And in the second mode, the non-OCF device actively sends a heartbeat packet, if the bridging device does not receive the heartbeat packet of the non-OCF device within a period of time, the non-OCF device is determined to be disconnected and is in an offline state, and if the bridging device can periodically or continuously receive the heartbeat packet of the non-OCF device, the non-OCF device is determined to be in a connected state.

Specifically, it can be known from the foregoing manner that, as long as the bridging device can receive the data packet sent by the non-OCF device within a certain time interval, it can confirm that the non-OCF device is in the connection state; if no data packet is received within 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, or may also be an instruction, or other interactive data, and the like, and the specific type of data is not limited in this application.

It should be understood that, in the embodiment of the present application, "heartbeat packet," "heartbeat data" and "heartbeat data packet" have the same meaning, 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 obtain a connection state between the non-OCF device and the bridge device according to a preset time interval.

In implementation of the scheme, the preset time interval may be determined by a time interval of sending the heartbeat packet or the heartbeat data by the non-OCF device, and the preset time interval should be at least greater than a time interval of sending the heartbeat data by the non-OCF device.

S102: and performing update processing according to the connection state, wherein the update processing is used for updating the connection condition between the non-OCF equipment and the bridge equipment.

In the step, after acquiring the connection state of a certain non-OCF device, the bridge device needs to perform certain update processing, and a main purpose of the present invention is 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, and at least change the connection state of the non-OCF device, or modify a port of a virtual OCF device in the bridge device, so that the OCF client cannot discover the offline non-OCF device or discover the online non-OCF device in time, or perform processing simultaneously in combination with the foregoing two manners, which is not limited in this embodiment.

In the communication method provided in this embodiment, the bridge device is configured to implement connection between the OCF client and the non-OCF device, and the bridge device can obtain a connection state between the non-OCF device and the bridge device and perform certain update 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 bridge device can be clearly confirmed, access to the connected non-OCF device is ensured, a problem of access failure is avoided, and 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 directly use the information representation of the non-OCF device, or may use the information representation of the virtual OCF device mapped by the non-OCF device, which is all intended to represent the non-OCF device. The information in the device resource list is mainly for the user to be able to confirm the connection status of the non-OCF device to be controlled from the OCF client, and does not limit what type of information is specific.

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

s201: and obtaining that the connection state between the non-OCF equipment and the bridging equipment is changed 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, may also actively send an instruction to determine the connection state with the non-OCF device according to the feedback condition, or may also determine the connection state through other detection manners, 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 time length or within several heartbeat cycles, it may be determined that the non-OCF device is in an offline state.

S202: and deleting the 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 an offline state.

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

After the updating, when the user accesses the non-OCF device from the OCF device through the bridge 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, indicating that the non-OCF device is 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 is prevented from selecting to access the offline non-OCF devices, and the user experience is improved.

In addition to performing the update processing in the above-described processing manner in step S202, the update processing may be performed in the following manner in step S203, or may be performed in combination with both the manners in step S202 and step S203.

S203: and configuring the ports of the virtual OCF equipment mapped with the non-OCF equipment so that the non-OCF equipment cannot be searched by the OCF client.

In this step, after the bridge device has acquired 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. And then the bridge device modifies the port of the virtual OCF device to 0, or other ports of the off-line non-OCF device which cannot be searched by the OCF client side are only required. After the processing mode is adopted, when a user accesses the non-OCF equipment through the OCF client, the information of the non-OCF equipment cannot be searched, 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 optional implementation manner, 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 of acquiring the device resource list by the OCF client include at least two:

first, the bridge 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 devices in the steps.

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

Step S2021: and receiving an equipment 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 a specific implementation of the scheme, a Bridge device between the OCF client and a non-OCF device (such as Zigbee, BLE, and the like) has a main function of performing protocol conversion, and may also be a Bridge platform (hereinafter referred to as Bridge) to periodically process heartbeat data from the non-OCF device. When the non-OCF equipment is disconnected from the Bridge, the heartbeat data of the non-OCF equipment is not reported any more, at this time, the multicast port number of the virtual OCF equipment corresponding to the non-OCF equipment in the Bridge is set to be 0 or cannot be found, and/or the online state in vod information corresponding to the non-OCF equipment under the resource of bridging equipment "/vod" (equipment resource list) in the Bridge can be set to be false; so that the OCF client cannot discover information corresponding to Bridge-disconnected non-OCF devices.

In the communication method provided in this embodiment, after acquiring that the non-OCF device is offline, the bridge device deletes the information of the offline non-OCF device in the device resource list or sets the state of the offline non-OCF device to the offline state based on the offline state, or may further configure a port, so that the OCF device client cannot search the offline non-OCF device, thereby avoiding a problem that a user accesses the non-OCF device when the user does not know that the non-OCF device is offline, which may cause access failure. Meanwhile, the access efficiency can be improved and the user experience can be improved.

Fig. 5 is a flowchart of a third embodiment of the communication method provided in the present application, and as shown in fig. 5, in a case that a connection is reestablished with a bridge device after a failure of a non-OCF device is resolved, or a new non-OCF device establishes a connection with the bridge device, the scheme provided in the present embodiment includes the following steps:

s301: the method comprises the steps of obtaining that connection between non-OCF equipment and bridging equipment is established, or the connection state between the non-OCF equipment and the bridging equipment is changed 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 determine the connection state of the newly online non-OCF device after completing the connection state confirmation such as network address allocation.

The connection state between the non-OCF device and the non-OCF device may also be determined according to a heartbeat packet or heartbeat data sent by the non-OCF device, or the connection state between the non-OCF device and the non-OCF device may also be determined by actively sending an instruction according to a feedback condition, or the connection state may also be determined by other detection manners, which is not limited in this application. For example, periodically receiving heartbeat data sent by a non-OCF device, it is determined that the non-OCF device is 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 online state.

In this step, after determining that the new non-OCF device establishes connection, that is, after determining that the state of the non-OCF device is online, the bridging device first establishes a mapping relationship between the virtual OCF device and the non-OCF device, and then adds information of the non-OCF device to the device resource list of the corresponding OCF device, or may add information of the virtual OCF device corresponding to the non-OCF device.

Or, when detecting that the offline non-OCF device is online again, the bridge device may set the connection state of the non-OCF device (or the corresponding virtual OCF device) in the device resource list to the online state. Therefore, when the user accesses the non-OCF equipment through the OCF client, the user can select the online non-OCF equipment to access.

In addition to performing the update processing in the above-described processing manner in step S302, the update processing may be performed in the following step S303, or performed in combination with both the processing manners in step S302 and step S303.

S303: and configuring the port number of the virtual OCF device mapped to the non-OCF device so that the OCF client can search the non-OCF device.

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

first, the bridge 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 devices in the steps.

Step S3021: and receiving an equipment 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 a 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, which may also be a port number specified by another broadcast protocol, which is not limited herein. And/or, the online state of the virtual OCF device corresponding to the non-OCF device under the resource of the Bridge device "/vdlist" (device resource list) in Bridge may also be set to true; enabling the OCF client to discover non-OCF devices reconnected to Bridge.

In the communication method provided in this embodiment, after the bridge device obtains that the non-OCF device is recovered offline or newly comes online, 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 the online state, or a port may be configured, so that the non-OCF device can be searched by the OCF client, thereby facilitating a user to determine the state of the non-OCF device for access, improving access efficiency, and improving user experience.

Based on the solutions provided by the above embodiments, the following describes the communication method provided by the present application by way of a few specific examples.

In the following embodiments, the bridging device includes several modules, namely, a bridging module (bridge device), a virtual OCF service (virtual OCF server), a bridged platform (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 according to the present application, and as shown in fig. 6, an interaction process of the OCF client and the non-OCF device is specifically as follows.

In the method, the device resource list of the bridge device is created by the bridge module of the bridge device between the OCF client and the bridge device, and in the bridge device, the device resource list may be an integrated list or a device resource list for each OCF client, which is not limited in this scheme.

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

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

In the bridging device, after the connection between the non-OCF device and the bridging device is established, the virtual non-OCF client sends a message for discovering that the non-OCF protocol device is completed to the bridged platform, the bridged platform interacts with the virtual OCF service, a corresponding virtual OCF device is established, and the mapping relation between the virtual OCF device and the non-OCF device is established. The virtual OCF service notifies the bridge module to add device information, that is, 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 to this.

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, and the bridge device acquires the non-OCF device according to the mapping relationship and then accesses the state information of the non-OCF device. And the non-OCF equipment returns the state information to the bridged platform in sequence, converts the state information of the non-OCF protocol into resource attribute information of the OCF protocol according to the corresponding relation between the protocols, and returns the resource attribute information to the OCF client.

Fig. 7 is an interaction schematic diagram of an example of the communication method provided by the present application, and as shown in fig. 7, based on 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.

After the non-OCF device establishes a connection with the bridge device according to the aforementioned connection procedure:

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

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

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

S403: and the non-OCF equipment sends heartbeat packets at regular time. In this step, it is set that the non-OCF device needs 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 bridging platform receives the heartbeat packet data notification, and if the timer is not overtime at the moment, the timer is reset and restarted to ensure that the timer is not overtime;

s406: and disconnecting the connection, and sending no heartbeat packet by the non-OCF equipment.

S407-S408: and when the timer is overtime, carrying out overtime processing, and setting the connection state of the non-OCF equipment to be offline.

In the above steps, when the non-OCF device is disconnected from Bridge and the timer in Bridge times out, the timeout time of the timer needs to be set to infinity, and the timer will never time out at this time; and then setting the online state of the non-OCF equipment in Bridge to be an offline state (keep alive- > not alive).

S409-S410: and the non-OCF device is notified offline, and the port of the virtual OCF device corresponding to the non-OCF device can also be set to 0. That is, the port number of the multicast of the virtual OCF device corresponding to the offline non-OCF device is set to 0.

S411 to S412: and the bridge module receives the offline notification of the non-OCF equipment and sets the non-OCF equipment in the equipment resource list to be in an offline state. In this step, the online corresponding to the non-OCF device under the/vollist 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.

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

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

The step of "S412" is modified to: and deleting the vod information corresponding to the offline non-OCF device under the resource list (/ vod) of the bridge device, 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 bridge device.

In this example, in a Bridge device (Bridge) of an OCF protocol and a non-OCF protocol, a heartbeat data process from a non-OCF protocol device is processed at a timing at a virtual non-OCF protocol client side, a timeout mechanism is established according to a heartbeat data timing sending time, a timer not less than 5 times the heartbeat data reporting time is set according to the heartbeat data reporting time, and if the timer is overtime, the timeout process is performed; and at the virtual OCF server, setting a multicast port number of the OCF protocol device corresponding to the non-OCF protocol device according to the timeout processing condition of the timer, if the timer is overtime, the non-OCF protocol device is disconnected from the Bridge, and at this time, the multicast port number needs to be set to 0, so that the OCF client cannot find the non-OCF protocol device, and therefore, in the process that a user accesses the non-OCF protocol device through the OCF client, access failure caused by offline of the non-OCF protocol device is avoided.

Fig. 8 is an interaction schematic diagram of another example of the communication method provided by the present application, and as shown in fig. 8, based on 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: the non-OCF device re-enters the network.

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

In the above steps, after the non-OCF device establishes connection with Bridge again, the online status of the non-OCF device needs to be set to online (not alive- > keep alive) in Bridge; then, the timer of the non-OCF device is set from infinite time to a time not lower than the time interval for sending the heartbeat packet, for example, it may be set to 5 times the time interval for reporting the heartbeat packet or heartbeat data of the non-OCF device.

S504: the bridge device sets 5683 to the port number of the virtual OCF device corresponding to the non-OCF device. 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 it.

S505-S506: and notifying to modify the vod, and simultaneously setting online in the vod information corresponding to the non-OCF device under the device resource list (/ vod) resource of the bridge device to 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 to be able to timely acquire the connection status of the non-OCF device.

In the scheme provided by the above example shown in fig. 8, on the basis of the above example shown in fig. 7, after the timer has not timed out or the non-OCF device has reestablished a connection with the Bridge device (Bridge), the multicast port of the virtual OCF device corresponding to the non-OCF device needs to be 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 another example of the communication method provided by the present application, and as shown in fig. 9, this example is a subsequent implementation manner based on an alternative scheme shown in fig. 7, when 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 bridge device. If the non-OCF device comes online again, that is, for the non-OCF protocol device connected to the Bridge device (Bridge) to be reestablished, the mapping relationship between the virtual OCF device and the non-OCF device needs to be reestablished, and the configuration operations in S601-S603 in the flow shown in fig. 9 need to be performed again.

In the subsequent execution process, the bridge device can obtain the connection state of the non-OCF device in time according to the scheme shown in S604-S606.

Based on all the above embodiments and examples, it can be seen that in the communication method provided in the embodiments of the present application, the bridge device can obtain the connection state between the non-OCF device and the bridge device, and perform certain processing according to the connection state, and perform state remark on the state of the offline non-OCF device, or directly delete the state remark, so as to avoid the problem that the OCF client can also access the disconnected non-OCF device and cause access failure. The online state of the non-OCF device which is online or online again 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 processing apparatus based on a device connection state according to the present application, as shown in fig. 10, the apparatus is configured to implement connection between an OCF client and at least one non-OCF device, and the processing apparatus 10 based on the device connection state includes:

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

and a processing module 12, configured to perform update processing according to the connection state, where the update processing is used to update a connection condition between the non-OCF device and the bridge device.

Optionally, if the connection state of the first non-OCF device is changed from connection 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 presence of a gas in the gas,

configuring a port of the virtual OCF device mapped with the first non-OCF device so that the OCF client cannot search 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 device in a device resource list, or setting the connection state of the second non-OCF device in the device resource list to be an online state;

and/or the presence of a gas in the gas,

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 obtaining 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 obtaining 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 off-line state;

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

Optionally, the preset time interval is greater than a time interval of sending the heartbeat data packet by the non-OCF device.

Optionally, the processing module 12 is further configured to:

and after any non-OCF equipment is connected with the bridging equipment, creating a mapping relation between the non-OCF equipment and the virtual OCF equipment.

The processing apparatus based on the device connection state provided in any of the above embodiments is used to implement the technical solution in the bridge device in any of the above method embodiments, and the implementation principle and the technical effect are similar, which are not described herein again.

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

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

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

Optionally, only the sending module 14 may be included, and is configured to send the updated device resource list request to the OCF client.

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

a processor 111, an interface 112 for communicating with other electronic devices, and a memory 113;

the memory 113 stores computer-executable instructions;

the processor 111 executes the computer-executable instructions stored by the memory 113, so that the processor 111 executes the scheme of the communication method provided by any one 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 in the embodiments of the present application, and fig. 12 only illustrates the number as 1 as an example.

In one specific implementation of the bridging device shown in fig. 12, the memory, the processor and the interface may be connected via a bus, and optionally, the memory may be integrated within the processor.

The present application further provides a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the computer-readable storage medium is used for implementing the scheme of the communication method provided by any one of the foregoing method embodiments.

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

The present application further provides a computer program, which, when being executed by a processor, is configured to implement the technical solution of the communication method provided by any of the foregoing method embodiments.

The present application further provides a computer program product comprising: program instructions for implementing the technical solutions of the communication methods provided by any of the foregoing method embodiments.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described device embodiments are merely illustrative, and for example, the division of the modules is only one logical division, and other divisions may be realized in practice, for example, a plurality of modules may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, and the indirect coupling or communication connection of the modules may be in an electrical, mechanical or other form.

In the foregoing Specific implementation of the bridge device, it should be understood that the Processor may be a Central Processing Unit (CPU), other general-purpose processors, a Digital Signal Processor (DSP), an 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, or in a combination of the hardware and software modules in the processor.

All or a portion of the steps of implementing the above-described method embodiments may be performed by hardware associated with program instructions. The aforementioned program may be stored in a readable memory. When executed, the program performs steps comprising the method embodiments described above; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid state disk, magnetic tape, floppy disk, optical disk, and any combination thereof.

Claims

A communication method is applied to a bridging device, wherein the bridging device is used for realizing connection between an OCF client and at least one non-OCF device, and the method comprises the following steps:

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

and performing update processing according to the connection state, wherein the update processing is used for updating the connection condition between the non-OCF device and the bridge device.
The method according to claim 1, wherein if the connection status of the first non-OCF device changes from connected to offline, the performing the update process according to the connection status comprises:

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 presence of a gas in the gas,

configuring a port of the virtual OCF device mapped with the first non-OCF device so that the OCF client cannot search the first non-OCF device.
The method according to claim 1, wherein if a second non-OCF device establishes a connection with the bridge device, or a connection status of the second non-OCF device changes from offline to online, the performing the update process according to the connection status includes:

adding the second non-OCF device in a device resource list, or setting the connection state of the second non-OCF device in the device resource list to be an online state;

and/or the presence of a gas in the gas,

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.
The method according to any one of claims 1 to 3, wherein the obtaining the connection state between the non-OCF device and the bridge device comprises:

and acquiring the connection state between the non-OCF equipment and the bridging equipment according to a preset time interval.
The method according to claim 4, wherein the obtaining the connection status 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 online state.
The method of claim 4 or 5, wherein the predetermined time interval is greater than the time interval for transmitting data packets by the non-OCF device.
The method according to any one of claims 1 to 6, further comprising:

and after any non-OCF equipment is connected with the bridging equipment, creating a mapping relation between the non-OCF equipment and the virtual OCF equipment.
The method according to any one of claims 1 to 7, further comprising:

receiving an equipment resource list acquisition request sent by an OCF client;

and sending the equipment resource list to the OCF client according to the equipment resource list acquisition request.
The method according to any one of claims 1 to 7, further comprising:

and sending the updated equipment resource list request to the OCF client equipment.
An apparatus connection status-based processing apparatus, the apparatus being configured to implement a connection between an OCF client and at least one non-OCF device, the apparatus comprising:

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 performing update processing according to the connection state, and the update processing is used for updating the connection state between the non-OCF device and the bridge device.
The apparatus of claim 10, wherein if the connection status of the first non-OCF device changes from connected to offline, the processing module 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 presence of a gas in the gas,

configuring a port of the virtual OCF device mapped with the first non-OCF device so that the OCF client cannot search the first non-OCF device.
The apparatus according to claim 10, wherein if the second non-OCF device establishes a connection with the bridge device, or the connection status of the second non-OCF device changes from offline to online, the processing module is specifically configured to:

adding the second non-OCF device in a device resource list, or setting the connection state of the second non-OCF device in the device resource list to be an online state;

and/or the presence of a gas in the gas,

and configuring the port number of the virtual OCF device mapped with the second non-OCF device so that the second non-OCF device can be searched by the OCF device.
The apparatus according to any one of claims 10 to 12, wherein the obtaining module is specifically configured to:

and acquiring the connection state between the non-OCF equipment and the bridging equipment according to a preset time interval.
The apparatus of claim 13, wherein the obtaining module is specifically configured to:

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 online state.
The apparatus according to claim 13 or 14, wherein the preset time interval is greater than a time interval in which the non-OCF device transmits heartbeat packets.
The apparatus of any of claims 10 to 15, wherein the processing module is further configured to:

and after any non-OCF equipment is connected with the bridging equipment, creating a mapping relation between the non-OCF equipment and the virtual OCF equipment.
The apparatus of any one of claims 10 to 16, further comprising:

the receiving module is used for receiving an equipment resource list acquisition request sent by an OCF client;

and the sending module is used for sending the equipment resource list to the OCF client according to the equipment resource list obtaining request.
The apparatus of any one of claims 10 to 16, further comprising:

and the sending module is used for sending the updated equipment resource list request to the OCF client.
A bridging device, comprising:

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 by the memory, causing the processor to perform the communication method of any of claims 1 to 9.
A computer-readable storage medium having stored thereon computer-executable instructions for implementing the communication method of any one of claims 1 to 9 when executed by a processor.
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 9.
A computer program for performing the communication method according to any one of claims 1 to 9 when the computer program is executed by a processor.
A computer program product, comprising: program instructions for implementing the communication method of any one of claims 1 to 9.