WO2017215477A1 - 一种用于物联网的事件处理方法、装置和设备 - Google Patents

一种用于物联网的事件处理方法、装置和设备 Download PDF

Info

Publication number
WO2017215477A1
WO2017215477A1 PCT/CN2017/087136 CN2017087136W WO2017215477A1 WO 2017215477 A1 WO2017215477 A1 WO 2017215477A1 CN 2017087136 W CN2017087136 W CN 2017087136W WO 2017215477 A1 WO2017215477 A1 WO 2017215477A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
action
message
identifier
function module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2017/087136
Other languages
English (en)
French (fr)
Inventor
杨江波
张春晖
蔡艳明
赵骥
王文超
张楠
刘胡笳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of WO2017215477A1 publication Critical patent/WO2017215477A1/zh
Priority to US16/215,155 priority Critical patent/US10944587B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H04L12/2827—Reporting to a device within the home network; wherein the reception of the information reported automatically triggers the execution of a home appliance functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/16—Sound input; Sound output
    • G06F3/167—Audio in a user interface, e.g. using voice commands for navigating, audio feedback
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/26—Speech to text systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/281—Exchanging configuration information on appliance services in a home automation network indicating a format for calling an appliance service function in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/282—Controlling appliance services of a home automation network by calling their functionalities based on user interaction within the home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/2849—Audio/video appliances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/285—Generic home appliances, e.g. refrigerators
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • the present invention relates to the field of computer application technologies, and in particular, to an event processing method, apparatus, and device for an Internet of Things.
  • Intelligent hardware is a technological concept following the smart phone. It transforms the traditional device through the combination of software and hardware, so that it has intelligent functions. Intelligent hardware is usually embodied in various smart devices such as smart home appliances, smart cars, smart wearable devices, and smart medical devices.
  • the present invention provides an event processing method, apparatus, and device for the Internet of Things, which expands the manner of event processing so that it can be applied to device level interconnection or linkage between function modules.
  • the present invention provides an event processing method for the Internet of Things, the method comprising:
  • the smart device acquires an event of the function module
  • the invention also provides an event processing method for the Internet of Things, the method comprising:
  • the smart device acquires an event of the function module
  • the function module linked by the event is triggered according to the registration information of the event.
  • the invention also provides an event processing method for the Internet of Things, the method comprising:
  • the cloud device receives an event message that is reported by the smart device and includes event information.
  • the present invention provides an event processing apparatus for an Internet of Things, which is disposed on a smart device, and the device includes:
  • An event obtaining unit configured to acquire an event of the function module
  • the event processing unit is configured to send the event message to the cloud device for the registration information of the event.
  • the present invention also provides an event processing apparatus for an Internet of Things, which is disposed on a smart device, and the device includes:
  • An event obtaining unit configured to acquire an event of the function module
  • An event processing unit configured to register information of the event, triggering a function module linked by the event.
  • the present invention also provides an event processing apparatus for the Internet of Things, the apparatus comprising:
  • the event receiving unit is configured to receive an event message that is reported by the smart device and includes event information.
  • the invention also provides an apparatus, including
  • One or more processors are One or more processors;
  • One or more programs the one or more programs being stored in the memory, executed by the one or more processors to:
  • the event processing mechanism provided by the present invention can send an event message to the cloud device according to the event registration information after the event of the function module is acquired, or trigger a function module linked by the event. Get rid of the limitation that the event can only be at the system level.
  • This extension enables the event processing mechanism to be applied to the interconnection of smart devices and the cloud, the interconnection of Internet of Things with other smart devices, or the linkage between internal modules of smart devices.
  • Figure 1 is a system architecture diagram on which the present invention is based
  • FIG. 2 is a flowchart of a main method according to an embodiment of the present invention.
  • FIG. 3 is a flowchart of an event processing situation according to an embodiment of the present invention.
  • FIG. 4 is a schematic diagram of a remote development configuration according to an embodiment of the present invention.
  • FIG. 5 is a schematic structural diagram of a Device Profile according to an embodiment of the present disclosure.
  • FIG. 6 is a flowchart of another Event processing scenario according to an embodiment of the present invention.
  • FIG. 7 is a flowchart of an implementation of a cloud device sending a control instruction to an intelligent device according to an Event message according to an embodiment of the present disclosure
  • FIG. 8 is a structural diagram of an apparatus installed in an intelligent terminal according to an embodiment of the present invention.
  • FIG. 9 is a structural diagram of an apparatus installed in a cloud device according to an embodiment of the present disclosure.
  • FIG. 10 is a schematic structural diagram of a device according to an embodiment of the present disclosure.
  • FIG. 11 is a flowchart of an action message interaction between a cloud device and a smart device according to an embodiment of the present invention.
  • the word “if” as used herein may be interpreted as “when” or “when” or “in response to determining” or “in response to detecting.”
  • the phrase “if determined” or “if detected (conditions or events stated)” may be interpreted as “when determined” or “in response to determination” or “when detected (stated condition or event) “Time” or “in response to a test (condition or event stated)”.
  • the system includes at least a cloud device and a smart device, wherein the cloud device may be a server in the cloud or a server cluster composed of multiple servers.
  • the smart device may be, for example, a smart home device, an intelligent network device, a smart car, a smart wearable device, a smart medical device, or the like.
  • the smart home appliances may include home appliances equipped with intelligent hardware such as smart TVs, smart air conditioners, smart water heaters, smart lights, smart doors and windows, smart refrigerators, smart air purifiers, and the like.
  • the intelligent network device may include, for example, a switch equipped with smart hardware, a wireless AP, and the like.
  • Smart wearable devices may include, for example, smart watches equipped with smart hardware, smart glasses, smart bracelets, smart helmets, AR devices, VR devices, and the like.
  • the smart medical device may include, for example, an intelligent thermometer equipped with intelligent hardware, an intelligent blood pressure meter, a smart blood glucose meter, and the like.
  • system may also include a development device, which is responsible for the development of the smart device, and is embodied in the present invention as sending a device configuration file to the cloud device.
  • a development device responsible for the development of the smart device, and is embodied in the present invention as sending a device configuration file to the cloud device.
  • the event processing on the smart device side is mainly implemented by the control center in the smart device, and the control hub can be a unit for completing the control and coordination functions of each functional module in the smart device, as shown in FIG. 2 .
  • the control center mainly performs the following steps:
  • Each function module in the smart device monitors the respective supported Event, and once the Event is detected, the Event is reported to the control hub.
  • a function module refers to a collection of program elements in a smart device that can perform certain functions. Usually, one function module corresponds to one function of the smart device, but the granularity of function is more flexible. For example, the light detection module, the switch module, and the like in the smart light are all functional modules.
  • the information of the Event is sent to the cloud device through the Event message, or the function module linked by the Event is triggered.
  • the processing of the Event event can mainly include two situations.
  • One situation is that the event is reported to the cloud device, and the situation can be used to implement the interconnection between the smart device and the cloud device;
  • Event other functional modules of the same smart device are triggered, and this situation can be used to implement linkage between different functional modules of the same smart device.
  • Event registration needs to be done locally in advance, as will be detailed in subsequent embodiments.
  • FIG. 3 is a flowchart of an event processing situation according to an embodiment of the present invention. As shown in FIG. 3, the following steps may be performed:
  • control hub of the smart device receives the device configuration file sent by the development device.
  • control center of the smart device performs Event registration locally according to the device configuration file, including registering event information reported to the cloud device.
  • the above two steps may be a pre-registration process.
  • the developer may define a device profile for the smart hardware (ie, the smart device), and then send the device profile to the smart device and the cloud device through the development device, as shown in the figure. Shown in 4.
  • the developer of the smart device can implement the configuration of the remote event.
  • the name of the Event and its corresponding event parameter can be defined in the profile.
  • the format used can be "Event Name: Event Parameter", for example:
  • a general Device Profile can be provided for a certain type of smart device.
  • the intelligent speaker provided by the A smart speaker developer and the B smart speaker developer has functions of playing, pause, resume, and volume setting. These two smart speakers can share this Device Profile.
  • you can define them through the separate Device Profile. This method can reduce the duplication of intelligent hardware development, form accumulation, and at the same time reduce the development threshold of intelligent hardware, and facilitate the popularization of intelligent hardware development.
  • the Device Profile can be described by a document, and more preferably, it can be organized in the form of a tree header file directory.
  • the child nodes of each node are sub-functions of the node, as shown in FIG.
  • the root node is a smart device, and its child nodes include: power module, audio module, video module, etc., and there may be more levels of child nodes, which are different in this figure.
  • the configuration information corresponding to the power module, the audio module, and the video module is respectively stored on the node corresponding to the power module, the audio module, and the video module, including the Event name and its corresponding parameter. As shown in FIG.
  • the power management related configuration information may be included on the power
  • the audio control related configuration information voice_control.h
  • the playlist related configuration information play_list.h
  • the playback control related configuration information may include brightness control related configuration information (light_control.h) and image related configuration information (image.h). Where “.h” is the format suffix of the configuration information.
  • the Event registration performed on the smart device may include: the control center resolves the Device Profile, locally registers the event identifier included in the Device Profile, or locally registers the event identifier included in the Device Profile and the event parameter corresponding to the event identifier.
  • the event identifier may be in the form of an Event id or an Event name. In the subsequent embodiments of the present invention, the Event name is taken as an example for description.
  • the name of these registered events is the name of the event reported to the cloud device.
  • "registration" includes locally recording information to be registered (for example, an Event name, an Event name, and a time parameter corresponding to the Event name).
  • the registration on the smart device side may include the registration of the function module in addition to the Event registration.
  • the so-called function module refers to a part of the smart device having a specific function, such as a power module, a control module, a detection module, and the like.
  • the developer can send the function module registration file to the control center of the smart device through the development device, or directly preset to the control center of the smart device, and the control center of the smart device can register the function module according to the function module registration file.
  • the function module registration file may include initialization process information of each function module, so that the smart device can automatically run the initialization process of each function module when the system is started.
  • the function module registration file may further include an event name that is supported by each function module, so that each function module can report the event name corresponding to the monitored event to the control center.
  • the registration process similarly receives the Device Profile sent by the development device, and locally registers the event information and the event information corresponding to the event information according to the Device Profile, where the event information may include the Event name and The corresponding Event parameter, or include the Event name.
  • This registration can be applied to the cloud device to control the same smart device according to the Event reported by the smart device.
  • the cloud device registers the event information, the destination device identifier, and the control finger corresponding to the event information locally according to the Device Profile. make.
  • This registration can be applied to the cloud device to control other smart devices according to the Event reported by the smart device. The processing of the cloud device will be described in the subsequent steps.
  • the above registration mechanism can be executed during the operation of the smart device, in addition to being executed when the smart device is activated, to implement device upgrade, and the like.
  • the developer upgrades the smart device more easily.
  • the Device Profile containing the new Event registration information can be sent to the smart device and the cloud device.
  • Cloud devices and smart devices can easily implement new Event registrations through the above registration mechanism.
  • all Event information included in the Device Profile may be registered, or only event information that has not been registered may be registered, and the event information that already exists in the local may be skipped.
  • the Device Profile can also be preset in the control hub, for example, the Device Profile is preset to the control center when the smart device is shipped from the factory. . It is also possible to customize the Device Profile on the smart device according to its own usage habits or actual use requirements. For example, the device profile is configured on the interface provided by the smart device to the user, and the device profile configured by the user is stored by the control center of the smart device.
  • the above configuration methods of the Device Profile enable users, whether developers or smart devices, to flexibly configure the control scheme of the smart device according to requirements.
  • control center of the smart device acquires the Event name reported by the function module.
  • Event name of the Event is reported to the control hub.
  • the control hub sends the Event name to the cloud device through the Event message.
  • the event identifier may include any description information that can be used to determine the event.
  • the event message may only carry the Event name.
  • the method may be applicable to the case where the cloud device registers the Event name and its corresponding Event parameter when registering.
  • the Event message may carry the Event name and its corresponding Event parameter.
  • the case may be applicable to the case where the cloud device does not register the Event parameter corresponding to the Event name when registering.
  • Subsequent cloud devices can perform various operations based on the Event message.
  • the cloud device can record the received Event information without any confirmation of the Event message.
  • a cloud device can also perform the following processing:
  • the cloud device sends a control instruction corresponding to the received Event name to the smart device according to the control instruction corresponding to the pre-registered Event name. That is, the cloud device reports the smart device that reports the event according to the received event. In the case of control, such as controlling an event of a voice recording, the control of the smart device is triggered.
  • the cloud device locally registers an Event name, a destination device identifier corresponding to the Event name, and a control instruction.
  • the destination device identifier is directed to a smart device or other smart device that sends an Event message, and is used to trigger control of another smart device based on an event of one smart device.
  • the cloud device determines the destination device identifier and the control command corresponding to the event name that is locally registered, and sends the determined control command to the smart device corresponding to the destination device identifier.
  • the implementation of issuing a control command to the smart device for the cloud device will be described in the embodiment shown in FIG.
  • the event information reported to the cloud device may carry the device identification information of the smart device.
  • the cloud device may first perform identity verification based on the device identification information carried in the Event message, that is, determine whether it is legal. The device ID, if yes, processes the received Event message, otherwise it can be directly discarded.
  • the device identifier of the smart device may be any information that can uniquely identify the smart device.
  • a unique IoT ID uniformly assigned to each smart device by the identifier distribution device may be adopted, and the ID is solidified at the factory. The chip of the device cannot be falsified or illegally obtained.
  • a legal device identifier can be set in advance at the cloud device. If the device identifier of the smart device is uniformly allocated by the identifier distribution device, the cloud device can obtain a legal device identifier from the identifier distribution device in advance.
  • Event message in addition to the Event name, the Event parameter (which may not be included), and the device identification information, other content fields may be included, which is not limited by the present invention.
  • For the cloud device it can be set to return without responding to the received Event message, or can be set to return an Event response message to the smart device.
  • the cloud device is configured to return an Event response message to the smart device
  • the event message may be retransmitted and may be The number of passes is limited.
  • the Event response message may include an Event name, which is used to identify a correspondence relationship with the Event message.
  • FIG. 6 is a flowchart of another Event processing scenario according to an embodiment of the present invention. As shown in FIG. 6, the following steps may be performed:
  • control hub of the smart device receives the device configuration file sent by the development device.
  • control center of the smart device performs Event registration locally according to the device configuration file, and includes a function module and a control command linked to register the Event information.
  • the two steps may be a pre-registration process.
  • the device profile refer to the related description in the embodiment shown in FIG. 3, and details are not described herein again.
  • the Event registration in this embodiment is different from the embodiment shown in FIG. 3 in that the registration can be performed only in the smart device.
  • the control hub resolves the Device Profile
  • the Event name and the Event name included in the Device Profile are locally registered.
  • Linked function modules and execution instructions are locally registered.
  • control hub acquires the Event name reported by the function module 1.
  • the function module 1 After the function module 1 detects the event, the event name of the event is reported to the control hub.
  • control hub determines the function module 2 and the execution instruction linked by the Event name reported by the locally registered function module 1.
  • an execution instruction corresponding to the Event name may be sent to the function module, thereby implementing another function module based on the Event of one function module.
  • control hub sends the determined execution instruction to the function module 2.
  • FIG. 7 is a flowchart of an implementation of a cloud device sending a control command to an intelligent device based on an Event message according to an embodiment of the present invention. As shown in FIG. 7, the process may include the following steps:
  • the cloud device after receiving the Event message reported by the smart device, the cloud device sends a first Action message to the smart device, where the first Action message includes an action identifier.
  • first Action message and the second Action message are the names of the first message and the second message listed in the embodiment of the present invention, but the embodiment of the present invention is not limited to such a message name.
  • the cloud device After receiving the event reported by the smart device, the cloud device triggers the delivery of the first Action message.
  • the control of the smart device by the cloud device is based on some specific events. For example, an event that controls voice recording triggers the cloud device to perform voice recognition, and then sends corresponding control.
  • the cloud device can send the first Action message to the smart device after receiving the event reported by the smart device.
  • the cloud device queries the business logic related to the event.
  • the correspondence between the Event and the Action identifier may be set in advance in the cloud device.
  • the Action ID corresponding to the Event is actually determined, and then the Action is determined according to the information registered in advance locally.
  • the identifier and its corresponding control parameter are sent to the smart terminal through the first Action message.
  • the cloud device sends the first Action message to another smart device after receiving the event reported by the smart device.
  • the cloud device queries the business logic related to the event.
  • the business logic is actually the correspondence between the preset Event and the Action identifier and the destination device identification information. That is to say, on the one hand, the corresponding Action identifier can be determined by the Event, and the destination device identifier can be determined on the other hand, and then the Action ID is included in the first Action message and sent to the smart device corresponding to the destination device identifier.
  • the cloud device may first determine the identifier information of the destination terminal device corresponding to the first action message before sending the first Action message (the destination device identifier information carried in the control command, and the identifier of the smart device sending the event). Whether the information or the registered destination device identification information corresponding to the event is a legal device identifier. If not, the first Action message is not sent to the smart device; if yes, the first Action message is allowed to be sent to the smart device.
  • the cloud device can be configured with a legal device identifier in advance. If the device identifier of the smart device is uniformly allocated by the device, the cloud device can obtain a legal device identifier from the device.
  • the cloud device receives a second Action message returned by the smart device, where the second Action message includes the Action ID and the Action state.
  • the action identifier in the second Action message is consistent with the action identifier in the first Action message, and is used to indicate an association between the second Action message and the first Action message.
  • the Action state is used to indicate the action execution status of the smart device for the first Action message. In view of different stages of the action execution, the Action state may include but is not limited to:
  • First state indicating that the first Action message is received.
  • the second state the preparation for indicating that the action is performed according to the control parameter corresponding to the Action identifier in the first Action message has been completed.
  • the third state indicating that the execution of the action according to the control parameter corresponding to the Action identifier in the first Action message is completed.
  • the fourth state indicating that an abnormality occurs in the execution of the action according to the control parameter corresponding to the Action identifier in the first Action message.
  • Action registration is described in detail below through a specific embodiment.
  • the action involved in the embodiment of the present invention can be understood as the control information sent by the cloud device to the smart device, which corresponds to various functions provided by the smart device, and the action delivered by the cloud device may correspond to one action, or may correspond to one action. sequence.
  • Action A message can be understood as a message for an Action to interact between a cloud device and a smart device.
  • an Action identifier may be used to identify and distinguish each Action.
  • the action identifier corresponds to a specific control parameter, wherein the control parameter may include an action type, such as play, pause, and the like. Some actions such as pauses only need the action type, but there are some other parameters such as playing, raising the volume, etc., which require some other parameters, such as playing the object and increasing the volume.
  • These Action IDs and their corresponding control parameters can be defined by the Device Profile.
  • the Device Profile can be in such a format as: "Action ID: Control Parameters", where multiple control parameters can be separated by commas, for example:
  • Action2 name pause
  • the action corresponding to action1 name is to play the apple; the action corresponding to action2 name is pause.
  • the Device Profile can define the Event ID and its corresponding event parameters in addition to the Action ID and its corresponding control parameters.
  • the format adopted can be "Event ID: Event Parameter", for example:
  • a general Device Profile can be provided for a certain type of smart device.
  • the intelligent speaker provided by the A smart speaker developer and the B smart speaker developer has functions of playing, pause, resume, and volume setting. These two smart speakers can share this Device Profile.
  • you can define them through the separate Device Profile. This method can reduce the duplication of intelligent hardware development, form accumulation, and at the same time reduce the development threshold of intelligent hardware, and facilitate the popularization of intelligent hardware development.
  • the Device Profile can be described by a document, and more preferably, it can be organized in the form of a tree header file directory. Its organizational structure can be as shown in Figure 5, and will not be described again.
  • the registration process in the cloud is mainly to: resolve the device profile of a certain type of smart device, and locally register the action identifiers included in the Device profile and the control parameters corresponding to the action identifier, the event identifier, and the event parameters corresponding to the event identifier. .
  • the cloud device can perform the sending of the Action message and the receiving and processing of the Event message.
  • the registration process on the smart device side is mainly: the control center of the smart device resolves the Device Profile, which is local. Register the action identifiers included in the Device Profile and the control parameters corresponding to the Action ID, the Event ID, and the event parameters corresponding to the Event ID. In this way, the smart device can receive, process, and send Action messages, and send and process Event messages.
  • the registration on the smart device side may include the registration of the function module in addition to the Action registration and the Event registration.
  • the so-called function module refers to the part of the smart device that has a specific function. For example, power modules, control modules, detection modules, and the like.
  • the developer can send the function module registration file to the control center of the smart device through the development device, or directly preset to the control center of the smart device, and the control center of the smart device can register the function module according to the function module registration file.
  • the function module registration file may include initialization process information of each function module, so that the smart device can automatically run the initialization process of each function module when the system is started.
  • the function module registration file may further include an Action identifier supported by each function module, so that after receiving the first Action instruction, the control hub can determine a function module for performing an action according to the Action identifier therein, and control parameters corresponding to the Action identifier. Provide the corresponding function module to perform the action.
  • the developer can upgrade the smart device more easily.
  • the device profile including the new action identifier and the corresponding control parameter can be sent to the cloud device and the smart device, the cloud device and The smart device can easily implement the upgrade of the new Action through the above registration mechanism.
  • the cloud device and the smart device can register all the action identifiers included in the Device Profile, or register only the Action IDs that have not been registered. You can skip the existing Action IDs.
  • FIG. 8 is a structural diagram of an apparatus installed in an intelligent terminal according to an embodiment of the present invention, where the apparatus corresponds to a control hub involved in the method embodiment.
  • the apparatus may include an event obtaining unit 01 and an event processing unit 02, and may further include a registration interface 03, a registration unit 04, a message receiving unit 05, a message transmitting unit 06, and a determining unit 07.
  • the main functions of each component are as follows:
  • the event obtaining unit 01 is responsible for acquiring the Event reported by the function module.
  • Each function module in the smart device monitors the respective supported Event. Once the Event is detected, the Event is reported to the device, and the Event Acquisition Unit 01 of the device can acquire the Event.
  • the event processing unit 02 is responsible for sending an event message to the cloud device according to the registration information of the Event, or triggering a function module linked by the Event. That is to say, the processing of the Event event can mainly include two situations, one The situation is to report the event to the cloud device. This situation can be used to implement the interconnection between the smart device and the cloud device. In another case, other function modules are triggered according to the Event. This situation can be used to implement linkage between the function modules.
  • the registration interface 03 is responsible for obtaining a device configuration file sent by the development device or a device configuration file preset locally. Developers can define a Device Profile for their own smart hardware (ie, smart device) and then send the Device Profile to the smart device through the development device. In this way, the developer of the smart device can implement the configuration of the remote event. In this embodiment, the name of the Event and its corresponding event parameter can be defined in the profile.
  • the registration unit 04 is responsible for registering the Event locally according to the device configuration file.
  • the control center parses the Device Profile, locally registers the Event name included in the Device Profile, or locally registers the Event name included in the Device Profile and the event parameter corresponding to the Event name.
  • the name of these registered events is the name of the event reported to the cloud device.
  • the event obtaining unit 01 acquires the event name reported by the function module. If the event name acquired by the event acquiring unit 01 belongs to the locally registered Event name reported to the cloud device, the event processing unit 02 sends an Event message to the cloud device.
  • the event processing unit 02 may send an Event message containing the Event name to the cloud device when the Event message is sent to the cloud device. This method is applicable to the case where the cloud device registers the Event name and its corresponding Event parameter when registering.
  • the Event message containing the Event name and the Event parameter corresponding to the Event name may also be sent to the cloud device. This may be applicable to the case where the cloud device does not register the Event parameter corresponding to the Event name when registering.
  • the registration information of the event may include: an event name and a function module and an execution instruction linked by the event name.
  • the event obtaining unit 01 acquires the event identifier reported by the function module; the event processing unit 02 determines the function module and the execution instruction linked by the event name acquired by the locally registered event acquiring unit 01; and sends the determination to the linked function module. Execution instructions.
  • the registration on the smart device side may include the registration of the function module in addition to the Event registration, the registration interface 03 acquires the function module registration file sent by the development device or locally preset, and the registration unit 04 registers the file according to the function module. Register the function module.
  • the function module registration file may include: each function The initialization process information of the module is used to automatically run the initialization process of each function module when the system is started; or, each function module supports the reported event identifier.
  • the event processing unit 02 described above can also receive an Event response message returned by the cloud device. If the Event response message is not received within the set duration of sending the Event message to the cloud device, the Event message may be resent to the cloud device. Here you can control the number of retransmissions of Event messages.
  • the message receiving unit 05 is responsible for receiving the first message sent by the cloud device for the event message, where the first message includes an action identifier.
  • the message sending unit 06 is responsible for returning a second message to the cloud device.
  • the second message includes an action identifier and an action state, and the action state is used to indicate an action execution status of the smart device for the first message.
  • the determining unit 07 is responsible for determining the control parameter corresponding to the registered action identifier by using the action identifier included in the first message, so as to perform the corresponding action by using the control parameter.
  • the first message may further include a control parameter corresponding to the action identifier, so that the smart device performs the corresponding action by using the control parameter.
  • the above action states may include the following four states:
  • the first state indicating the first state in which the first message is received.
  • the second state a second state indicating that the preparation for performing the action according to the control parameter corresponding to the action identifier has been completed.
  • the third state indicating that the third state of the action is completed according to the control parameter corresponding to the action identifier.
  • the fourth state indicating a fourth state in which an abnormality occurs in the action according to the control parameter corresponding to the action identifier.
  • FIG. 9 is a structural diagram of an apparatus for setting a cloud device according to an embodiment of the present invention.
  • the apparatus may include: an event receiving unit 11, and may further include a recording unit 12, a message sending unit 13, and a registration interface 14.
  • the main functions of each component are as follows:
  • the event receiving unit 11 is responsible for receiving an Event message containing the Event information reported by the smart device.
  • the Event information may include: an Event name, which is applicable to the case where the Cloud device registers the Event name and its corresponding Event parameter.
  • the Event information may include an Event name corresponding to the Event name and the Event name, and this case may be applied to the case where the Cloud device registers the Event name.
  • the recording unit 12 can record the event information.
  • the Event message from the smart device side can be not confirmed.
  • the Event response message for the Event message may also be returned to the smart device by the response sending unit 16 after receiving the Event message at the event receiving unit 11.
  • the message sending unit 13 may further send a first message to the smart device or other smart device that sends the Event message according to the Event information, where the first message includes an action identifier.
  • the message receiving unit 17 is responsible for receiving the second message returned by the smart device for the first message, the second message includes an action identifier and an action state, and the action state is used to indicate an action execution status of the smart device for the first message.
  • the determining unit 18 is responsible for acquiring the control parameter corresponding to the registered action identifier, and the control parameter is included in the first message.
  • the above action states may include, but are not limited to, the following four states:
  • the first state indicating the first state in which the first message is received.
  • the second state a second state indicating that the preparation for performing the action according to the control parameter corresponding to the action identifier has been completed.
  • the third state indicating that the third state of the action is completed according to the control parameter corresponding to the action identifier.
  • the fourth state indicating a fourth state in which an abnormality occurs in the action according to the control parameter corresponding to the action identifier.
  • the developer can send a Device Profile to the cloud device through the development device.
  • the registration interface 14 receives the Device Profile sent by the development device.
  • the registration unit 15 locally registers the Event information and the control instruction corresponding to the Event information according to the Device Profile, or locally registers the Event information, the destination device identifier and the control command corresponding to the Event information.
  • the Event information may include an Event name, and may further include an Event parameter corresponding to the Event name.
  • the above method and apparatus provided by the embodiments of the present invention may be embodied by a computer program that is set up and operates in a device.
  • the device may include one or more processors, and also includes a memory and one or more programs, as shown in FIG.
  • the one or more programs are stored in a memory and executed by the one or more processors to implement the method flow and/or device operations illustrated in the above-described embodiments of the present invention.
  • the method flow executed by one or more of the above processors may include:
  • the application scenario is an Event mechanism between the terminal and the cloud.
  • the developer pre-registers the relevant Event of the voice control module in the intelligent audio to the control center in the intelligent hardware, and the related Event is also pre-registered to the cloud.
  • One of the events is to control voice recording.
  • the voice recording module in the intelligent audio monitors the control voice recording event when it is triggered, and reports the event name to the control hub.
  • the control hub determines that it belongs to the pre-registered Event name reported to the cloud device.
  • the intelligent audio reports the Event message containing the Event name to the cloud device.
  • the cloud device may not perform any confirmation for the Event itself, but may perform subsequent processing based on the Event, for example, identifying the control voice included in the Event, and issuing a corresponding control command according to the control voice box.
  • the Event mechanism provided by the present invention can implement interconnection between a smart device and a cloud device.
  • the event name is reported to the control center in the smart door and window. After the control center determines that the Event name belongs to the event that is reported to the cloud device, the event name is reported to the cloud device by using the Event message.
  • the cloud device After receiving the Event message, the cloud device determines the destination device identifier and the control command corresponding to the Event name by querying the pre-registered Event registration information. Assuming that the determined destination device identifier points to the smart light, and the control command is an instruction to turn on the light, the cloud device sends a control command to turn on the light to the smart light. This kind of scene can be realized, when the user opens the door, the smart light automatically lights up.
  • the Event mechanism provided by the present invention can implement interconnection of a smart device with other smart devices through a cloud device.
  • the application scenario is an Event mechanism between functional modules in a smart device.
  • the light detecting module in the smart light After detecting the event whose light brightness is lower than the preset threshold, the light detecting module in the smart light sends the Event name to the control center in the smart light.
  • the control center determines that the function name and the control instruction that are linked in the event name registered locally, that is, the Event name linkage switch module, and the corresponding control instruction is a light-on instruction. Then, the control center sends a light-on command to the switch module of the smart light.
  • the smart light is turned on at this time. This kind of scene can be realized, when the ambient light brightness is lower than the preset threshold, the smart light automatically lights up.
  • Event mechanism provided by the present invention can implement interconnection between internal modules of the smart device.
  • FIG. 11 is a flowchart of an action message interaction between a cloud device and a smart device according to an embodiment of the present invention. As shown in FIG. 11, the process may specifically include the following steps:
  • the cloud device sends a first Action message including an action identifier and a control parameter to the smart device, where the action is represented by an action message.
  • the ID is uniquely identified by the Action identifier.
  • the smart device after receiving the first Action message, the smart device returns a second Action message including the Action ID and the first state information to the cloud device, where the action is represented by an Action_received message.
  • the second Action message in this step is uniquely identified by the action identifier and the first state information, where the first state indicates that the first Action message is received.
  • the smart device returns a second Action message including the action identifier and the second state information to the cloud device after the preparation of the action is completed according to the control parameter in the first Action message, where the action is performed in the action_ (Action_doing) indicates.
  • the second Action message in this step is uniquely identified by the Action identifier and the second state information, wherein the second state indicates that the preparation for performing the action according to the control parameter in the first Action message has been completed.
  • the smart device after the smart device performs the action according to the control parameter, the smart device returns a second Action message including the action identifier and the third state information to the cloud device, where the action is represented by an action_done message.
  • the second Action message in this step is uniquely identified by the action identifier and the third state information, wherein the third state indication is performed according to the control parameter in the first Action message.
  • the smart device when the smart device performs an action according to the control parameter, the smart device returns a second Action message including the action identifier and the fourth state information to the cloud device, where the action is represented by an action_exception message.
  • the second Action message in this step is uniquely identified by the Action identifier and the fourth state information, where the fourth state indicates that an abnormality occurs in the action according to the control parameter in the first Action message. It should be noted that step 1105 does not necessarily appear after step 1104, which may occur at any time after step 1102, and may occur as long as an exception occurs.
  • Action_received is not received within the set time of sending the action, the action is resent. If Action_doing is not received within the set time of receiving Action_received, the action is resent. If Action_done is not received within the set time of receiving Action_doing, the action is resent. If Action_exception is received, the action is resent. In addition, you can set the maximum number of resends for the action. After the maximum number of retransmissions is reached, the action is not resent.
  • various Action states received by the cloud device may be returned to the control device that sends the control command.
  • the user's mobile phone sends a control command to play the "Little Apple” audio to the smart sound through the cloud.
  • the correspondence between the action identifier and the control command is pre-stored in the cloud device.
  • the cloud device After receiving the control instruction for playing the "Little Apple” audio sent by the user's mobile phone, the cloud device determines the action identifier corresponding to the instruction according to the corresponding relationship, for example, the action identifier is:
  • Action name1 play, args: “Little Apple”.
  • the action name1 is the action identifier, and the play and args: "small apple" are the control parameters.
  • the cloud device determines the destination terminal device, that is, the smart audio, according to the ID2 (a kind of Internet of Things ID that is uniformly assigned by the identifier distribution device and uniquely identifies the smart device), and sends the first Action message to the smart speaker.
  • the first Action message may include the following fields: an action identifier and a control parameter.
  • the smart speaker After receiving the first Action message, the smart speaker returns a second Action message with a status of action_received to the cloud device.
  • the second Action message may include the following fields: action name1 and the current action state (ie, action_received), which can uniquely identify the message returned by the smart speaker.
  • the cloud device does not receive the second Action message including the action_received returned by the smart speaker within the set duration, the first Action message may be resent.
  • the smart sound After the smart sound returns a second Action message containing the action_received to the cloud device, the smart sound starts to perform the action execution according to the control parameter in the first Action message. After the preparation is completed, return a second Action message containing the action_doing to the cloud.
  • the second Action message with the action state of action_doing may include the following fields: action name1 and the current action state (ie, action_doing), which can uniquely identify the message returned by the smart speaker.
  • the smart sound After performing the action of playing the "Little Apple” audio, the smart sound returns a second Action message containing the action_done to the cloud device.
  • the second Action message with the action state of action_done may include the following fields: action name1 and the current action state (ie, action_done), which can uniquely identify the instruction returned by the smart speaker.
  • the second Action message containing the action_exception may be returned to the cloud.
  • the second Action message containing the action_exception may include the following fields: action name1 and the current action state (ie, action_exception), these two words The segment can uniquely identify the instruction that the smart speaker returns this time.
  • the second Action message including the action_exception may further include a parameter field indicating a specific exception type.
  • the cloud device can know the action execution state of the smart sound on the action according to the action state returned by the smart sound, thereby ensuring that the control executed by the cloud device is monitored in each state executed on the smart hardware device, thereby ensuring the complete execution of the action. Sex and tracing. In addition, the cloud device can also return the action status returned by the smart sound to the smart phone that sends the control command, so that the user can know the execution status of the action in time.
  • the application scenario is an Event mechanism between the smart device and the cloud device.
  • the developer pre-registers the relevant Event of the voice control module in the smart audio to the IDJS CORE (Control Hub) in the intelligent hardware, and the related Event is also pre-registered to the cloud device.
  • One of the events is to control voice recording.
  • the control voice recording event of the smart sound When the control voice recording event of the smart sound is triggered, the smart sound sends the event to the cloud.
  • the cloud may not make any confirmation for the Event itself, but may perform subsequent processing based on the Event, for example, identifying the control voice included in the Event, determining the corresponding Action identifier and control parameters according to the control voice, and carrying the Action in the first Action. Issued in the message.
  • the cloud device determines an Action identifier, a control parameter, and a destination terminal device corresponding to the Event.
  • the determined Action ID is: Action name2
  • the control parameter is: light
  • the destination terminal device is a smart light.
  • the cloud device sends the action name2 and its corresponding control parameter to the smart light through the first Action message.
  • the smart light can perform the smart light according to the Action name2 and its corresponding control parameter. Light up. And can return a second Action message in a different state.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated order The element can be implemented in the form of hardware or in the form of hardware plus software functional units.
  • the above-described integrated unit implemented in the form of a software functional unit can be stored in a computer readable storage medium.
  • the above software functional unit is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor to perform the methods of the various embodiments of the present invention. Part of the steps.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like, which can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Human Computer Interaction (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • General Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Acoustics & Sound (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Selective Calling Equipment (AREA)
  • User Interface Of Digital Computer (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明提供了一种用于物联网的事件处理方法、装置和设备，其中智能设备中的控制中枢获取功能模块的事件，依据所述事件的注册信息，向云端设备发送事件消息，或者触发所述事件所联动的功能模块。摆脱了事件只能在系统级别的限制，这种扩展使得事件处理机制，能够应用于智能设备与云端的互联、通过物联网与其他智能设备的互联、或者智能设备内部模块之间的联动。

Description

一种用于物联网的事件处理方法、装置和设备
本申请要求2016年06月17日递交的申请号为201610435323.2、发明名称为“一种用于物联网的事件处理方法、装置和设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及计算机应用技术领域，特别涉及一种用于物联网的事件处理方法、装置和设备。
背景技术
智能硬件是继智能手机之后的一个科技概念，通过软硬件结合的方式对传统设备进行改造，进而让其拥有智能化的功能。智能硬件在产品上通常体现为各种智能设备，诸如智能家电、智能汽车、智能穿戴设备、智能医疗设备等。
在智能设备的各种功能实现时，不可避免地会涉及到对事件(Event)的处理，诸如定时器事件、语音录制事件、特定条件触发的事件等等，然而在现有技术中，这类事件的处理几乎都局限在智能设备的操作系统级别，局限性很大，无法应用于设备级别的互联或者功能模块之间的联动。
发明内容
有鉴于此，本发明提供了一种用于物联网的事件处理方法、装置和设备，对事件处理的方式进行扩展，使其可以应用于设备级别的互联或者功能模块之间的联动。
具体技术方案如下：
本发明提供了一种用于物联网的事件处理方法，该方法包括：
智能设备获取功能模块的事件；
依据所述事件的注册信息，向云端设备发送事件消息。
本发明还提供了一种用于物联网的事件处理方法，该方法包括：
智能设备获取功能模块的事件；
依据所述事件的注册信息，触发所述事件所联动的功能模块。
本发明还提供了一种用于物联网的事件处理方法，该方法包括：
云端设备接收智能设备上报的包含事件信息的事件消息。
本发明提供了一种用于物联网的事件处理装置，设置于智能设备，该装置包括：
事件获取单元，用于获取功能模块的事件；
事件处理单元，用于所述事件的注册信息，向云端设备发送事件消息。
本发明还提供了一种用于物联网的事件处理装置，设置于智能设备，该装置包括：
事件获取单元，用于获取功能模块的事件；
事件处理单元，用于所述事件的注册信息，触发所述事件所联动的功能模块。
本发明还提供了一种用于物联网的事件处理装置，该装置包括：
事件接收单元，用于接收智能设备上报的包含事件信息的事件消息。
本发明还提供了一种设备，包括
一个或者多个处理器；
存储器；
一个或者多个程序，所述一个或者多个程序存储在所述存储器中，被所述一个或者多个处理器执行以实现如下操作：
获取功能模块上报的事件；
依据所述事件的注册信息，向云端设备发送事件消息，或者触发所述事件所联动的功能模块。
本发明提供的事件处理机制，能够在获取功能模块的事件后，依据事件的注册信息，向云端设备发送事件消息，或者触发事件所联动的功能模块。摆脱了事件只能在系统级别的限制，这种扩展使得事件处理机制，能够应用于智能设备与云端的互联、通过物联网与其他智能设备的互联、或者智能设备内部模块之间的联动。
附图说明
图1为本发明所基于的系统架构图；
图2为本发明实施例提供的主要方法流程图；
图3为本发明实施例提供的一种Event处理情形的流程图；
图4为本发明实施例提供的远程开发配置的示意图；
图5为本发明实施例提供的一种Device Profile的结构示意图；
图6为本发明实施例提供的另一种Event处理情形的流程图；
图7为本发明实施例提供的云端设备基于Event消息向智能设备下发控制指令的实现流程图；
图8为本发明实施例提供的设置于智能终端的装置结构图；
图9为本发明实施例提供的设置于云端设备的装置结构图；
图10为本发明实施例提供的设备结构示意图；
图11为本发明实施例提供的云端设备与智能设备之间的Action消息交互流程图。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。
在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。
应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。
为了方便对本发明的理解，首先对于本发明所基于的系统架构进行简单描述。如图1中所示，该系统至少包括云端设备和智能设备，其中云端设备可以是云端的一个服务器，也可以是由多个服务器构成的服务器集群。智能设备可以是诸如智能家电设备、智能网络设备、智能汽车、智能穿戴式设备、智能医疗设备等。其中智能家电设备可以包括诸如智能电视、智能空调、智能热水器、智能电灯、智能门窗、智能冰箱、智能空气净化器等搭载了智能硬件的家电设备。智能网络设备可以包括诸如搭载了智能硬件的交换机、无线AP等。智能穿戴式设备可以包括诸如搭载了智能硬件的智能手表、智能眼镜、智能手环、智能头盔、AR设备、VR设备等等。智能医疗设备可以包括诸如搭载了智能硬件的智能体温计、智能血压仪、智能血糖仪等。
除此之外，该系统还可以包括开发设备，开发设备负责针对智能设备的开发工作，在本发明中体现为向云端设备发送设备配置文件。具体将在后续实施例中详细描述。
首先对该事件处理在智能设备端的实现进行描述，智能设备端的事件处理主要由智能设备中的控制中枢实现，控制中枢可以为智能设备中完成各功能模块的控制和协调功能的单元，如图2中所示，该控制中枢主要执行以下步骤：
在201中，获取功能模块上报的Event。
智能设备中各功能模块对各自支持的Event进行监测，一旦监测到Event，则将该Event上报至控制中枢。功能模块指的是智能设备中能够完成一定功能的程序元素的集合，通常一个功能模块与智能设备的一个功能对应，但功能的粒度划分比较灵活。例如，智能电灯中的光线检测模块、开关模块等都是功能模块。
在202中，依据该Event的注册信息，将该Event的信息通过Event消息发送给云端设备，或者触发该Event所联动的功能模块。
从本步骤可以看出，对Event事件的处理可以主要包括两种情形，一种情形是将Event上报至云端设备，这种情形可以用于实现智能设备与云端设备的互联；另一种情形是依据Event触发同一智能设备的其他功能模块，这种情形可以用于实现同一智能设备的不同功能模块之间的联动。在控制中枢中若要实现这两种情形，需要预先在本地进行Event注册，这将在后续实施例中进行详述。
为了方便对图2所示方法的理解，下面通过两个实施例分别对上述Event事件处理的两种情形进行描述。
图3为本发明实施例提供的一种Event处理情形的流程图，如图3所示，可以执行以下步骤：
在301中，智能设备的控制中枢接收开发设备发送的设备配置文件。
在302中，智能设备的控制中枢依据设备配置文件，在本地进行Event注册，包括注册向云端设备上报的Event信息。
上述两个步骤可以为预先的注册过程，开发者可以针对自己的智能硬件(即智能设备)定义设备配置文件(Device Profile)，然后通过开发设备将Device Profile发送给智能设备和云端设备，如图4中所示。通过这种方式，智能设备的开发者就能够实现远程的Event的配置。在本实施例中，Profile中可以定义Event名称及其对应的事件参数。采用的格式可以为“Event名称：事件参数”，例如：
event1 name：power_low args:10％
表示电量低于10％的事件。
在本发明实施例中，可以针对某一类智能设备提供一个通用的Device Profile，例如A智能音箱开发者和B智能音箱开发者提供的智能音箱都有播放、暂停、恢复、音量设置等功能，这两种智能音箱就可以共用这个Device Profile。对于两种智能音箱各自有特色的功能，则可以通过分别的Device Profile进行定义。这种方式可以减少智能硬件开发的重复劳动，形成累积，同时也降低了智能硬件的开发门槛，便于智能硬件开发的普及。
Device Profile可以通过一个文档来说明，更优地，可以通过树形的头文件目录形式进行组织。在该树形的头文件目录中，各节点的子节点是该节点的子功能，如图5中所示。根节点为智能设备(device)，其子节点包括：电源模块(power)、音频模块(audio)、视频模块(video)……，还可以存在更多层次的子节点，在此图中不一一穷举。在电源模块、音频模块、视频模块对应的节点上分别存储电源模块、音频模块、视频模块所对应的配置信息，包括Event名称及其对应参数。如图5中所示，power上可以包括电源管理相关的配置信息(power_manage.h)，audio上可以包括声音控制相关的配置信息(voice_control.h)、播放列表相关的配置信息(play_list.h)、播放控制相关的配置信息(play_control.h)，vedio上可以包括亮度控制相关的配置信息(light_control.h)、图像相关的配置信息(image.h)。其中，“.h”为配置信息的格式后缀。
在智能设备端进行的Event注册可以包括：控制中枢解析Device Profile，在本地注册Device Profile所包含的事件标识，或者在本地注册Device Profile所包含的事件标识以及事件标识对应的事件参数。其中事件标识可以是Event id，或者Event名称等形式，在本发明后续实施例中，均以Event名称为例进行描述。
这些注册的Event名称为向云端设备上报的Event名称。其中，“注册”包括在本地对要注册的信息(例如Event名称、Event名称以及Event名称对应的时间参数)进行记录。
另外，在智能设备端的注册除了包含Event注册之外，还可以包含功能模块的注册，所谓功能模块指的是智能设备中具有特定功能的部分，例如电源模块、控制模块、检测模块等。开发者通过开发设备能够将功能模块注册文件发送给智能设备的控制中枢中，或者直接预置于智能设备的控制中枢，智能设备的控制中枢能够依据该功能模块注册文件进行功能模块的注册。其中功能模块注册文件可以包括各功能模块的初始化流程信息，使得智能设备在系统启动时能够自动运行各功能模块的初始化过程。另外，功能模块注册文件还可以包括各功能模块支持上报的Event名称，使得各功能模块能够将监测到的Event对应的Event名称上报给控制中枢。
在云端设备侧也存在一个注册过程，该注册过程类似地，接收开发设备发送的Device Profile，依据该Device Profile在本地注册事件信息和事件信息对应的控制指令，其中事件信息可以包括Event名称及其对应的Event参数，或者包括Event名称。这种注册可以应用于云端设备依据智能设备上报的Event实现对该同一智能设备进行控制。或者，云端设备依据Device Profile在本地注册事件信息、事件信息对应的目的设备标识和控制指 令。这种注册可以应用于云端设备依据智能设备上报的Event实现对其他智能设备进行控制。关于云端设备的处理将在后续步骤中描述。
上述注册机制，除了可以在智能设备激活时执行之外，在智能设备运行过程中也可以执行，用以实现设备升级等。通过上述注册机制，开发者对智能设备的升级更加简单，例如当有新的Event注册信息时，可以将包含该新的Event注册信息的Device Profile发送给智能设备和云端设备。云端设备和智能设备通过上述的注册机制，就可以轻松实现新的Event注册。其中云端设备和智能设备的注册过程中，可以对Device Profile包含的所有Event信息均进行注册，也可以仅注册尚未注册的Event信息，对于本地已经存在的Event信息可以跳过。
需要说明的是，除了开发者通过开发设备向智能设备的控制中枢发送Device Profile的方式之外，也可以在控制中枢中预置Device Profile，例如在智能设备出厂时将Device Profile预置于控制中枢。还可以由用于依据自身的使用习惯或者实际使用需求，自定义地在智能设备配置Device Profile。例如通过智能设备向用户提供的接口，配置Device Profile，并由智能设备的控制中枢存储该用户配置的Device Profile。Device Profile的上述几种配置方式，使得无论是开发者还是智能设备的使用者，均能够根据需求灵活地对智能设备的控制方案进行配置。
在303中，智能设备的控制中枢获取功能模块上报的Event名称。
当某功能模块监测到Event后，将该Event的Event名称上报给控制中枢。
在304中，若确定功能模块上报的Event名称属于本地注册的向云端设备上报的事件标识，则控制中枢将Event名称通过Event消息发送给云端设备。
本申请实施例中，事件标识可以包括任何可以用于确定该事件的描述信息。
控制中枢在向云端设备发送Event消息时，该Event消息中可以仅携带Event名称，例如，这种方式可以适用于云端设备在注册时，注册Event名称及其对应Event参数的情况。或者Event消息中可以携带Event名称及其对应的Event参数，例如，这种情况可以适用于云端设备在注册时，并未注册Event名称对应的Event参数的情况。
后续云端设备可以基于Event消息进行各种操作，例如，云端设备可以不对Event消息进行任何确认，对接收到的Event信息进行记录。例如，云端设备还可以进行以下处理：
云端设备依据预先注册的Event名称对应的控制指令，向该智能设备发送接收到的Event名称对应的控制指令。即云端设备依据接收到的Event，对上报Event的智能设备 进行控制的情况，例如控制语音录制的Event会触发对该智能设备的控制。
还有一种情况，就是云端设备在本地注册有Event名称、该Event名称对应的目的设备标识和控制指令。其中目的设备标识指向发送Event消息的智能设备或其他智能设备，对于目的设备标识指向其他智能设备的情况，用于基于一个智能设备的Event触发对另一智能设备的控制。云端设备接收到智能设备上报的Event名称后，确定在本地注册的该Event名称对应的目的设备标识和控制指令，将确定出的控制指令发送给该目的设备标识对应的智能设备。对于云端设备向智能设备下发控制指令的实现将在图7所示实施例中描述。
为了提高安全性，上报给云端设备的Event消息中可以携带智能设备的设备标识信息，云端设备接收到Event消息后，可以首先基于Event消息携带的设备标识信息进行身份验证，即判断是否为合法的设备标识，如果是，则对接收到的Event消息进行处理，否则可以直接丢弃。
该智能设备的设备标识可以是任意的能够唯一标识智能设备的信息，优选地，可以采用由标识分配设备统一分配给各智能设备的、唯一的物联网ID，该ID在出厂时被固化于智能设备的芯片中，不可篡改和非法获取。在云端设备处可以预先设置合法的设备标识，若智能设备的设备标识由标识分配设备统一分配，则云端设备可以预先从标识分配设备处获取合法的设备标识。
对于Event消息而言，除了包含Event名称、Event参数(可以不包含)以及设备标识信息之外，还可以包含其他内容字段，本发明对此不加以限制。
对于云端设备而言，可以被设置为对接收到的Event消息不做任何响应的返回，也可以被设置为对向智能设备返回Event响应消息。
在云端设备被设置为向智能设备返回Event响应消息的情况下，若智能设备在上报Event消息后的设定时长内未接收到Event响应消息，则可以进行Event消息的重传，并且可以对重传次数进行限制。Event响应消息中可以包含Event名称，该Event名称用于标识与Event消息之间的对应关系。
图6为本发明实施例提供的另一种Event处理情形的流程图，如图6所示，可以执行以下步骤：
在601中，智能设备的控制中枢接收开发设备发送的设备配置文件。
在602中，智能设备的控制中枢依据设备配置文件，在本地进行Event注册，包括注册Event信息所联动的功能模块和控制指令。
同样，这两个步骤可以为预先的注册过程，关于设备配置文件(Device Profile)的相关描述可以参见图3所示实施例中的相关描述，在此不再赘述。
在本实施例中的Event注册与图3所示实施例不同的是，该注册可以仅在智能设备中进行，控制中枢解析Device Profile后，在本地注册Device Profile所包含的Event名称以及Event名称所联动的功能模块和执行指令。
在603中，控制中枢获取功能模块1上报的Event名称。
当功能模块1监测到Event后，将该Event的Event名称上报给控制中枢。
在604中，控制中枢确定本地注册的功能模块1上报的Event名称所联动的功能模块2和执行指令。
若在本地注册有与该Event名称存在联动关系的功能模块，则就可以向该功能模块发送与该Event名称对应的执行指令，从而实现基于一个功能模块的Event控制另一功能模块。
在605中，控制中枢向功能模块2发送确定的执行指令。
图7为本发明实施例提供的云端设备基于Event消息向智能设备下发控制指令的实现流程图，如图7所示，该流程可以包括以下步骤：
在701中，云端设备接收智能设备上报的Event消息后，向智能设备发送第一Action消息，该第一Action消息包括Action标识。
需要说明的是，第一Action消息和第二Action消息为本发明实施例中列举的第一消息和第二消息的名称，但本发明实施例并不限于这种消息名称。云端设备接收到智能设备上报的Event后，触发第一Action消息的下发。在一些业务逻辑中，云端设备对智能设备的控制是基于一些特定事件的，例如控制语音录制的Event会触发云端设备进行语音识别后，下发对应的控制。
在这种情况下，云端设备可以接收到一个智能设备上报的Event后，向该智能设备下发第一Action消息。
当智能设备向云端设备上报该Event时，云端设备查询与该Event相关的业务逻辑。可以预先在云端设备设置Event与Action标识之间的对应关系，在查询与该Event相关的业务逻辑时，实际上就是确定该Event对应的Action标识，然后再依据预先在本地注册的信息，将Action标识及其对应的控制参数通过第一Action消息下发给智能终端。
还存在这样的情况：云端设备接收到一个智能设备上报的Event后，向另一个智能设备下发第一Action消息。
当智能设备向云端上报该Event时，云端设备查询与该Event相关的业务逻辑。这里的业务逻辑实际上是预置的Event与Action标识以及目的设备标识信息之间的对应关系。也就是说，通过Event一方面可以确定出对应的Action标识，另一方面可以确定出目的设备标识，然后将该Action标识包含在第一Action消息中发送给该目的设备标识对应的智能设备。
对于上述两种情况，云端设备在发送第一Action消息之前，可以首先判断该第一Action消息对应的目的终端设备的标识信息(控制指令中携带的目的设备标识信息、发送Event的智能设备的标识信息或者已注册的与Event对应的目的设备标识信息)，是否为合法的设备标识，如果否，则禁止向智能设备发送第一Action消息；如果是，才允许向智能设备发送第一Action消息。
其中，在云端设备处可以预先设置合法的设备标识，若智能设备的设备标识由标识分配设备统一分配，则云端设备可以预先从标识分配设备处获取合法的设备标识。
对于第一Action消息而言，除了包括Action标识、控制参数、智能设备的标识信息之外，还可以包含其他内容字段，本发明对此不加以限制。
在702中，云端设备接收智能设备返回的第二Action消息，该第二Action消息包括上述Action标识和Action状态。
其中，第二Action消息中的Action标识与第一Action消息中的Action标识一致，用以指示该第二Action消息与第一Action消息之间的关联。Action状态用于指示智能设备针对第一Action消息的动作执行状况，鉴于动作执行的不同阶段，Action状态可以包括但不限于：
第一状态：指示接收到第一Action消息。
第二状态：指示依据第一Action消息中的Action标识所对应的控制参数执行动作的准备工作已完成。
第三状态：指示依据第一Action消息中的Action标识所对应的控制参数执行动作已完毕。
第四状态：指示依据第一Action消息中的Action标识所对应的控制参数执行动作出现异常。
下面通过具体实施例对Action注册的机制进行详细描述。本发明实施例中涉及的Action可以理解为云端设备下发给智能设备的控制信息，其对应的是智能设备提供的各种功能，云端设备下发的Action可以对应一个动作，也可以对应一个动作序列。Action 消息可以理解为针对Action在云端设备和智能设备之间交互的消息。
为了区分不同的动作，在本发明实施例中，可以采用Action标识来标识和区分各Action。Action标识与具体的控制参数对应，其中控制参数可以包括动作类型，例如播放、暂停等。诸如暂停等一些Action仅需要动作类型即可，但还有一些诸如播放、调高音量等Action需要一些其他的参数，例如播放对象、调高音量的幅度。这些Action标识及其对应的控制参数可以通过设备配置文件(Device Profile)进行定义。Device Profile中可以采用这样的格式：“Action标识：控制参数”，其中多个控制参数可以采用逗号隔开，例如：
action1 name：play，args:“小苹果”
action2 name：pause
其中，action1 name对应的动作是播放小苹果；action2 name对应的动作是暂停。
另外，Device Profile除了可以定义Action标识及其对应的控制参数之外，还可以定义Event标识及其对应的事件参数。采用的格式可以为“Event标识：事件参数”，例如：
event1 name：power_low args:10％
表示电量低于10％的事件。
开发者可以针对自己的智能硬件(即智能设备)定义Device Profile，然后通过开发设备将Device Profile发送给云端设备和智能设备。通过这种方式，智能设备的开发者就能够实现远程的Action和Event的配置。在本发明实施例中，可以针对某一类智能设备提供一个通用的Device Profile，例如A智能音箱开发者和B智能音箱开发者提供的智能音箱都有播放、暂停、恢复、音量设置等功能，这两种智能音箱就可以共用这个Device Profile。对于两种智能音箱各自有特色的功能，则可以通过分别的Device Profile进行定义。这种方式可以减少智能硬件开发的重复劳动，形成累积，同时也降低了智能硬件的开发门槛，便于智能硬件开发的普及。
Device Profile可以通过一个文档来说明，更优地，可以通过树形的头文件目录形式进行组织。其组织结构可以如图5所示，不再赘述。
在云端的注册过程主要是：解析某类型智能设备的Device Profile，针对该类型智能设备在本地注册Device Profile所包含的各Action标识以及Action标识对应的控制参数、Event标识以及Event标识对应的事件参数。这样云端设备就能够进行Action消息的下发和Event消息的接收、处理。
在智能设备端的注册过程主要是：智能设备的控制中枢解析Device Profile，在本地 注册Device Profile所包含的各Action标识以及Action标识对应的控制参数、Event标识以及Event标识对应的事件参数。这样，智能设备就能够针对Action消息进行接收、处理和发送，以及对Event消息进行发送和处理。
另外，与云端设备的注册不太一样的是，在智能设备端的注册除了包含Action注册和Event注册之外，还可以包含功能模块的注册，所谓功能模块指的是智能设备中具有特定功能的部分，例如电源模块、控制模块、检测模块等。开发者通过开发设备能够将功能模块注册文件发送给智能设备的控制中枢中，或者直接预置于智能设备的控制中枢，智能设备的控制中枢能够依据该功能模块注册文件进行功能模块的注册。其中功能模块注册文件可以包括各功能模块的初始化流程信息，使得智能设备在系统启动时能够自动运行各功能模块的初始化过程。另外，功能模块注册文件还可以包括各功能模块支持的Action标识，使得控制中枢接收到第一Action指令后，能够依据其中的Action标识确定执行动作的功能模块，并将该Action标识对应的控制参数提供给相应的功能模块以执行动作。
通过上述注册机制，开发者对智能设备的升级更加简单，例如当有新的Action标识时，可以将包含该新的Action标识及对应控制参数的Device Profile发送给云端设备和智能设备，云端设备和智能设备通过上述的注册机制，就能够轻松实现新的Action的升级。其中云端设备和智能设备在注册过程中，可以对Device Profile包含的所有Action标识均进行注册，也可以仅注册尚未注册的Action标识，对于本地已经存在的Action标识可以跳过。
以上是对本发明所提供的方法进行的详细描述，下面结合具体实施例对本发明所提供的装置进行详细描述。
图8为本发明实施例提供的设置于智能终端的装置结构图，该装置对应于方法实施例中涉及的控制中枢。如图8所示，该装置可以包括：事件获取单元01和事件处理单元02，还可以包括注册接口03、注册单元04、消息接收单元05、消息发送单元06和确定单元07。其中各组成单元的主要功能如下：
事件获取单元01负责获取功能模块上报的Event。智能设备中各功能模块对各自支持的Event进行监测，一旦监测到Event，则将该Event上报至本装置，本装置的事件获取单元01就可以获取到该Event。
事件处理单元02负责依据Event的注册信息，向云端设备发送事件消息，或者触发Event所联动的功能模块。也就是说，对Event事件的处理可以主要包括两种情形，一种 情形是将Event上报至云端设备，这种情形可以用于实现智能设备与云端设备的互联；另一种情形是依据Event触发其他功能模块，这种情形可以用于实现功能模块之间的联动。
针对上述第一种情形，即将Event上报至云端设备的情形，可以采用如下的注册方式：
注册接口03负责获取开发设备发送的设备配置文件或者在本地预置的设备配置文件。开发者可以针对自己的智能硬件(即智能设备)定义设备配置文件(Device Profile)，然后通过开发设备将Device Profile发送给智能设备。通过这种方式，智能设备的开发者就能够实现远程的Event的配置。在本实施例中，Profile中可以定义Event名称及其对应的事件参数。
注册单元04负责依据设备配置文件，在本地进行Event的注册。包括：控制中枢解析Device Profile，在本地注册Device Profile所包含的Event名称，或者在本地注册Device Profile所包含的Event名称以及Event名称对应的事件参数。这些注册的Event名称为向云端设备上报的Event名称。
这种情况下，事件获取单元01获取功能模块上报的Event名称，若事件获取单元01获取的Event名称属于本地注册的向云端设备上报的Event名称，则事件处理单元02向云端设备发送Event消息。
其中，事件处理单元02在向云端设备发送Event消息时可以将包含Event名称的Event消息发送给云端设备，这种方式适用于云端设备在注册时，注册Event名称及其对应Event参数的情况。也可以将包含Event名称和该Event名称对应的Event参数的Event消息发送给云端设备，这种情况可以适用于云端设备在注册时，并未注册Event名称对应的Event参数的情况。
针对上述第二种情形，即依据Event触发其他功能模块的情形，这种情形下，事件的注册信息可以包括：Event名称以及Event名称所联动的功能模块和执行指令。
这种情形下，事件获取单元01获取功能模块上报的事件标识；事件处理单元02确定本地注册的事件获取单元01获取的Event名称所联动的功能模块和执行指令；向所联动的功能模块发送确定出的执行指令。
另外，在智能设备端的注册除了包含Event注册之外，还可以包含功能模块的注册，注册接口03获取开发设备发送的或者在本地预置的功能模块注册文件，注册单元04依据功能模块注册文件，进行功能模块的注册。其中功能模块注册文件可以包括：各功能 模块的初始化流程信息，用于在系统启动时自动运行各功能模块的初始化过程；或者，各功能模块支持上报的事件标识。
上述的事件处理单元02还可以接收云端设备返回的Event响应消息。在向云端设备发送Event消息的设定时长内未接收到该Event响应消息，则可以重新向云端设备发送该Event消息。在此可以控制Event消息的重传次数。
消息接收单元05负责接收云端设备针对事件消息发送的第一消息，第一消息包括动作标识。
消息发送单元06负责向云端设备返回第二消息，第二消息包括动作标识和动作状态，动作状态用于指示智能设备针对第一消息的动作执行状况。
确定单元07负责利用第一消息中包含的动作标识，确定注册的该动作标识对应的控制参数，以便利用控制参数执行相应动作。
其中，上述第一消息中还可以包括动作标识对应的控制参数，以便智能设备利用控制参数执行相应动作。
上述的动作状态可以包括以下四种状态：
第一种状态：指示接收到第一消息的第一状态。
第二种状态：指示依据动作标识对应的控制参数执行动作的准备工作已完成的第二状态。
第三种状态：指示依据动作标识对应的控制参数执行动作已完毕的第三状态。
第四种状态：指示依据动作标识对应的控制参数执行动作出现异常的第四状态。
图9为本发明实施例提供的设置于云端设备的装置结构图，如图9所示，该装置可以包括：事件接收单元11，还可以进一步包括记录单元12、消息发送单元13、注册接口14、注册单元15、响应发送单元16、消息接收单元17和确定单元18。其中各组成单元的主要功能如下：
事件接收单元11负责接收智能设备上报的包含Event信息的Event消息。其中，Event信息可以包括：Event名称，这种情况适用于在云端设备注册有Event名称及其对应Event参数的情况。或者，Event信息可以包括Event名称和Event名称对应的Event参数，这种情况可以适用于在云端设备注册有Event名称的情况。
在接收到Event消息之后，记录单元12可以对事件信息进行记录。对于云端设备而言，可以对来自智能设备端的Event消息不进行确认。也可以由响应发送单元16在事件接收单元11接收到Event消息后，向智能设备返回针对该Event消息的Event响应消息。
除此之外，更进一步地，消息发送单元13可以依据Event信息，向该发送Event消息的智能设备或者其他智能设备发送第一消息，该第一消息包括动作标识。
消息接收单元17负责接收智能设备针对第一消息返回的第二消息，第二消息包括动作标识和动作状态，动作状态用于指示智能设备针对第一消息的动作执行状况。
确定单元18负责获取注册的动作标识对应的控制参数，将该控制参数包含在第一消息中。
上述的动作状态可以包括但不限于以下四种状态：
第一种状态：指示接收到第一消息的第一状态。
第二种状态：指示依据动作标识对应的控制参数执行动作的准备工作已完成的第二状态。
第三种状态：指示依据动作标识对应的控制参数执行动作已完毕的第三状态。
第四种状态：指示依据动作标识对应的控制参数执行动作出现异常的第四状态。
对于云端设备上Event的注册，开发者可以通过开发设备向云端设备发送Device Profile。注册接口14接收开发设备发送的Device Profile。注册单元15依据Device Profile，在本地注册Event信息和该Event信息对应的控制指令，或者在本地注册Event信息、该Event信息对应的目的设备标识和控制指令。其中，Event信息可以包括Event名称，还可以进一步包括Event名称对应的Event参数。
本发明实施例提供的上述方法和装置可以以设置并运行于设备中的计算机程序体现。该设备可以包括一个或多个处理器，还包括存储器和一个或多个程序，如图10中所示。其中该一个或多个程序存储于存储器中，被上述一个或多个处理器执行以实现本发明上述实施例中所示的方法流程和/或装置操作。例如，被上述一个或多个处理器执行的方法流程，可以包括：
获取功能模块上报的事件；
依据所述事件的注册信息，向云端设备发送事件消息，或者触发所述事件所联动的功能模块。
下面列举本发明的几个应用场景的实例：
应用场景1：
该应用场景是终端与云端之间的Event机制。
由于开发者预先将智能音响中语音控制模块的相关Event注册到了智能硬件中的控制中枢，并且该相关Event也预先注册到了云端。其中一种Event为控制语音录制。当 智能音响中语音录制模块监测到控制语音录制Event被触发时，将该Event名称上报给控制中枢。
控制中枢确定其属于预先注册的上报给云端设备的Event名称。智能音响将包含该Event名称的Event消息上报给云端设备。云端设备对于该Event本身可以不做任何确认，但可以基于该Event进行后续处理，例如对该Event所包含的控制语音进行识别，依据控制语音箱该智能音响下发相应的控制指令等。
在这种应用场景中，本发明提供的Event机制能够实现智能设备与云端设备的互联。
应用场景2：
智能门窗中的状态监测模块监测到开门的Event后，将该Event名称上报给智能门窗中的控制中枢。控制中枢确定该Event名称属于上报给云端设备的Event后，将该Event名称通过Event消息上报给云端设备。
云端设备接收到该Event消息后，通过查询预先注册的Event注册信息，确定该Event名称对应的目的设备标识和控制指令。假设确定的目的设备标识指向智能电灯，控制指令为开灯的指令，那么云端设备向智能电灯发送开灯的控制指令。这种场景能够实现，当用户开门后，智能电灯自动点亮。
在这种应用场景中，本发明提供的Event机制能够实现智能设备通过云端设备与其他智能设备的互联。
应用场景3：
该应用场景是智能设备中功能模块间的Event机制。
智能电灯中的光线检测模块监测到光线亮度低于预设阈值的Event后，将该Event名称发送给智能电灯中的控制中枢。控制中枢确定在本地注册的该Event名称存在联动的功能模块和控制指令，即该Event名称联动开关模块，对应的控制指令为开灯指令。则控制中枢向智能电灯的开关模块发送开灯指令。此时智能电灯就被打开。这种场景能够实现，当环境光线亮度低于预设阈值时，智能电灯自动点亮。
在这种应用场景中，本发明提供的Event机制能够实现智能设备内部模块之间的互联。
在上面图7所示的实施例中以及提及关于第二Action消息的几种情况，下面结合一个具体实施例对云端设备和智能设备之间的Action消息交互进行详细描述。图11为本发明实施例提供的云端设备与智能设备之间的Action消息交互流程图，如图11中所示，该流程可以具体包括以下步骤：
在1101中，云端设备向智能设备发送包含Action标识和控制参数的第一Action消息，图中以动作(Action)消息进行表示。
在该第一Action消息(对应于图7所示实施例中的第一Action消息)中，通过Action标识进行唯一标识。
在1102中，智能设备接收到第一Action消息后，向云端设备返回包括上述Action标识和第一状态信息的第二Action消息，图中以动作_已接收(Action_received)消息表示。
本步骤中的第二Action消息通过Action标识和第一状态信息进行唯一标识，其中第一状态指示接收到第一Action消息。
在1103中，智能设备在依据第一Action消息中的控制参数完成执行动作的准备工作候，向云端设备返回包括上述Action标识和第二状态信息的第二Action消息，图中以动作_执行中(Action_doing)表示。
本步骤中的第二Action消息通过Action标识和第二状态信息进行唯一标识，其中第二状态指示依据第一Action消息中的控制参数执行动作的准备工作已完成。
在1104中，智能设备在依据控制参数执行动作完毕后，向云端设备返回包括上述Action标识和第三状态信息的第二Action消息，图中以动作_已完成(Action_done)消息表示。
本步骤中的第二Action消息通过Action标识和第三状态信息进行唯一标识，其中第三状态指示依据第一Action消息中的控制参数执行动作完毕。
在1105中，智能设备在依据控制参数执行动作发生异常时，向云端设备返回包括上述Action标识和第四状态信息的第二Action消息，图中以动作_异常(Action_exception)消息表示。
本步骤中的第二Action消息通过Action标识和第四状态信息进行唯一标识，其中第四状态指示依据第一Action消息中的控制参数执行动作出现异常。需要说明的是，步骤1105并不一定出现于步骤1104之后，其可能产生于步骤1102之后的任何时间中，只要发生异常，就可能会执行。
对于云端设备而言，若在发送Action的设定时长内未接收到Action_received，则重发Action。若在接收到Action_received的设定时长内未接收到Action_doing，则重发Action。若在接收到Action_doing的设定时长内未接收到Action_done，则重发Action。若接收到Action_exception，则重发Action。另外，也可以设置Action的重发次数上限，达到该重发次数上限后，不再重发Action。
另外，对于云端设备接收到的各种Action状态，可以返回给发送控制指令的控制设备。
针对云端设备与智能设备之间的Action交互，列举几个应用场景实例：
应用场景1：
用户手机通过云端向智能音响发送播放“小苹果”音频的控制指令。在云端设备预先存储有action标识与控制指令之间的对应关系。云端设备接收到用户手机发送来的播放“小苹果”音频的控制指令后，依据上述对应关系，确定该指令对应的action标识，例如该action标识为：
action name1：play，args:“小苹果”。
其中action name1为action标识，play和args:“小苹果”为控制参数。
然后，云端设备依据该控制指令中包含的ID2(一种由标识分配设备统一分配的、唯一标识智能设备的物联网ID)确定目的终端设备，即智能音响，向智能音响发送第一Action消息。该第一Action消息中可以包含以下字段：action标识和控制参数。
智能音响接收到第一Action消息后，向云端设备返回包含状态为action_received的第二Action消息。该第二Action消息中可以包含以下字段：action name1以及本次action状态(即action_received)，这两个字段可以唯一标识智能音响本次返回的消息。
如果云端设备在设定时长内未接收到智能音响返回的包含状态为action_received的第二Action消息，则可以重新发送第一Action消息。
智能音响向云端设备返回包含状态为action_received的第二Action消息后，开始依据第一Action消息中的控制参数进行动作执行的准备工作。待准备工作完成后，向云端返回包含状态为action_doing的第二Action消息。该包含状态为action_doing的第二Action消息中可以包含以下字段：action name1以及本次action状态(即action_doing)，这两个字段可以唯一标识智能音响本次返回的消息。
智能音响执行播放“小苹果”音频的动作后，向云端设备返回包含状态为action_done的第二Action消息。该包含状态为action_done的第二Action消息中可以包含以下字段：action name1以及本次action状态(即action_done)，这两个字段可以唯一标识智能音响本次返回的指令。
智能音响若在动作执行过程中出现异常，则可以向云端返回包含状态为action_exception的第二Action消息。该包含状态为action_exception的第二Action消息中可以包含以下字段：action name1和本次action状态(即action_exception)，这两个字 段可以唯一标识智能音响本次返回的指令。另外该包含状态为action_exception的第二Action消息还可以包括指示具体异常类型的参数字段。
云端设备可以依据智能音响返回的action状态，获知智能音响对Action的动作执行状态，从而确保了云端设备下发的控制在智能硬件设备上执行的各个状态都在监控中，保证了动作执行的完整性和追查性。另外，云端设备还可以将智能音响返回的action状态返回给发送控制指令的智能手机，以便用户能够及时获知动作的执行状态。
应用场景2：
该应用场景是智能设备与云端设备之间的Event机制。
由于开发者预先将智能音响中语音控制模块的相关Event注册到了智能硬件中的IDJS CORE(控制中枢)，并且该相关Event也预先注册到了云端设备。其中一种Event为控制语音录制。当智能音响的控制语音录制Event被触发时，智能音响将该Event发送给云端。云端对于该Event本身可以不做任何确认，但可以基于该Event进行后续处理，例如对该Event所包含的控制语音进行识别，依据控制语音确定相应的Action标识和控制参数，并携带在第一Action消息中下发。
应用场景3：
智能门窗检测到开门的Event后，将该Event上报给云端设备。云端设备确定该Event对应的Action标识、控制参数和目的终端设备。例如，确定的Action标识为：Action name2，控制参数为：light，目的终端设备为智能电灯。则云端设备通过第一Action消息将Action name2及其对应的控制参数发送给智能电灯，智能电灯接收到该第一Action消息后，可以依据其中的Action name2及其对应的控制参数，进行智能电灯的点亮。并可以返回不同状态的第二Action消息。
在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单 元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (66)

  1. 一种用于物联网的事件处理方法，其特征在于，该方法包括：
    智能设备获取功能模块的事件；
    依据所述事件的注册信息，向云端设备发送事件消息。
  2. 根据权利要求1所述的方法，其特征在于，该方法还包括：
    获取开发设备发送的设备配置文件、用户配置的设备配置文件或者预置的设备配置文件；
    依据所述设备配置文件，进行事件的注册。
  3. 根据权利要求1或2所述的方法，其特征在于，所述事件的注册信息包括：
    向云端设备上报的事件标识；或者，
    向云端设备上报的事件标识以及事件标识对应的事件参数。
  4. 根据权利要求3所述的方法，其特征在于，所述获取功能模块上报的事件包括：获取功能模块上报的事件标识；
    依据所述事件的注册信息，向云端设备发送事件消息包括：
    若所述功能模块上报的事件标识属于注册的向云端设备上报的事件标识，则向云端设备发送事件消息。
  5. 根据权利要求3所述的方法，其特征在于，所述向云端设备发送事件消息包括：
    将包含事件标识的事件消息发送给云端设备；或者，
    将包含事件标识和该事件标识对应的事件参数的事件消息发送给云端设备。
  6. 根据权利要求1所述的方法，其特征在于，该方法还包括：
    获取开发设备发送的或者在本地预置的功能模块注册文件；
    依据所述功能模块注册文件，进行功能模块的注册。
  7. 根据权利要求6所述的方法，其特征在于，所述功能模块注册文件包括：
    各功能模块的初始化流程信息，用于在系统启动时自动运行各功能模块的初始化过程；或者，
    各功能模块支持上报的事件标识。
  8. 根据权利要求1所述的方法，其特征在于，该方法还包括：
    接收所述云端设备返回的事件响应消息。
  9. 根据权利要求8所述的方法，其特征在于，该方法还包括：
    在向所述云端设备发送事件消息的设定时长内未收到所述事件响应消息，则重新向 所述云端设备发送所述事件消息。
  10. 根据权利要求1所述的方法，其特征在于，该方法还包括：
    接收云端设备针对所述事件消息发送的第一消息，所述第一消息包括动作标识；
    向所述云端设备返回第二消息，所述第二消息包括所述动作标识和动作状态，所述动作状态用于指示所述智能设备针对所述第一消息的动作执行状况。
  11. 根据权利要求10所述的方法，其特征在于，该方法还包括：
    所述智能设备利用所述第一消息中包含的动作标识，确定注册的该动作标识对应的控制参数，以便利用所述控制参数执行相应动作。
  12. 根据权利要求10所述的方法，其特征在于，所述第一消息中还包括所述动作标识对应的控制参数；
    所述智能设备利用所述控制参数执行相应动作。
  13. 根据权利要求10所述的方法，其特征在于，所述动作状态包括：
    指示接收到所述第一消息的第一状态；或者，
    指示依据所述动作标识对应的控制参数执行动作的准备工作已完成的第二状态；或者，
    指示依据所述动作标识对应的控制参数执行动作已完毕的第三状态；或者，
    指示依据所述动作标识对应的控制参数执行动作出现异常的第四状态。
  14. 一种用于物联网的事件处理方法，其特征在于，该方法包括：
    智能设备获取功能模块的事件；
    依据所述事件的注册信息，触发所述事件所联动的功能模块。
  15. 根据权利要求14所述的方法，其特征在于，该方法还包括：
    获取开发设备发送的设备配置文件、用户配置的设备配置文件或者预置的设备配置文件；
    依据所述设备配置文件，进行事件的注册。
  16. 根据权利要求14或15所述的方法，其特征在于，所述事件的注册信息包括：
    事件标识以及事件标识所联动的功能模块和执行指令。
  17. 根据权利要求16所述的方法，其特征在于，所述获取功能模块上报的事件包括：获取功能模块上报的事件标识；
    依据所述事件的注册信息，触发所述事件所联动的功能模块包括：
    确定注册的所述上报的事件标识所联动的功能模块和执行指令；
    向所联动的功能模块发送确定出的执行指令。
  18. 根据权利要求14所述的方法，其特征在于，该方法还包括：
    获取开发设备发送的或者预置的功能模块注册文件；
    依据所述功能模块注册文件，进行功能模块的注册。
  19. 根据权利要求18所述的方法，其特征在于，所述功能模块注册文件包括：
    各功能模块的初始化流程信息，用于在系统启动时运行各功能模块的初始化过程；或者，
    各功能模块支持上报的事件标识。
  20. 根据权利要求14所述的方法，其特征在于，该方法还包括：
    接收云端设备返回的事件响应消息。
  21. 根据权利要求20所述的方法，其特征在于，该方法还包括：
    在向所述云端设备发送事件消息的设定时长内未收到所述事件响应消息，则重新向所述云端设备发送所述事件消息。
  22. 根据权利要求14所述的方法，其特征在于，该方法还包括：
    接收云端设备针对所述事件消息发送的第一消息，所述第一消息包括动作标识；
    向所述云端设备返回第二消息，所述第二消息包括所述动作标识和动作状态，所述动作状态用于指示所述智能设备针对所述第一消息的动作执行状况。
  23. 根据权利要求22所述的方法，其特征在于，该方法还包括：
    所述智能设备利用所述第一消息中包含的动作标识，确定注册的该动作标识对应的控制参数，以便利用所述控制参数执行相应动作。
  24. 根据权利要求22所述的方法，其特征在于，所述第一消息中还包括所述动作标识对应的控制参数；
    所述智能设备利用所述控制参数执行相应动作。
  25. 根据权利要求22所述的方法，其特征在于，所述动作状态包括：
    指示接收到所述第一消息的第一状态；或者，
    指示依据所述动作标识对应的控制参数执行动作的准备工作已完成的第二状态；或者，
    指示依据所述动作标识对应的控制参数执行动作已完毕的第三状态；或者，
    指示依据所述动作标识对应的控制参数执行动作出现异常的第四状态。
  26. 一种用于物联网的事件处理方法，其特征在于，该方法包括：
    云端设备接收智能设备上报的包含事件信息的事件消息。
  27. 根据权利要求26所述的方法，其特征在于，所述事件信息包括：
    事件标识；或者，
    事件标识和事件标识对应的事件参数。
  28. 根据权利要求26所述的方法，其特征在于，所述云端设备在接收到所述事件消息后，向所述智能设备返回事件响应消息。
  29. 根据权利要求26或27所述的方法，其特征在于，该方法还包括：
    所述云端设备对所述事件信息进行记录；或者，
    依据所述事件信息，向所述智能设备或者其他智能设备发送第一消息，所述第一消息包括动作标识。
  30. 根据权利要求29所述的方法，其特征在于，在向所述智能设备或者其他智能设备发送第一消息之后，还包括：
    接收智能设备返回的第二消息，所述第二消息包括所述动作标识和动作状态，所述动作状态用于指示所述智能设备针对所述第一消息的动作执行状况。
  31. 根据权利要求29所述的方法，其特征在于，该方法还包括：
    获取注册的所述动作标识对应的控制参数，将该控制参数包含在所述第一消息中。
  32. 根据权利要求30所述的方法，其特征在于，所述动作状态包括：
    指示接收到所述第一消息的第一状态；或者，
    指示依据所述动作标识对应的控制参数执行动作的准备工作已完成的第二状态；或者，
    指示依据所述动作标识对应的控制参数执行动作已完毕的第三状态；或者，
    指示依据所述动作标识对应的控制参数执行动作出现异常的第四状态。
  33. 一种用于物联网的事件处理装置，设置于智能设备，其特征在于，该装置包括：
    事件获取单元，用于获取功能模块的事件；
    事件处理单元，用于所述事件的注册信息，向云端设备发送事件消息。
  34. 根据权利要求33所述的装置，其特征在于，该装置还包括：
    注册接口，用于获取开发设备发送的设备配置文件、用户配置的设备配置文件或者预置的设备配置文件；
    注册单元，用于依据所述设备配置文件，进行事件的注册。
  35. 根据权利要求33或34所述的装置，其特征在于，所述事件的注册信息包括：
    向云端设备上报的事件标识；或者，
    向云端设备上报的事件标识以及事件标识对应的事件参数。
  36. 根据权利要求35所述的装置，其特征在于，所述事件获取单元，具体用于获取功能模块上报的事件标识；
    所述事件处理单元，具体用于若所述事件获取单元获取的事件标识属于注册的向云端设备上报的事件标识，则向云端设备发送事件消息。
  37. 根据权利要求35所述的装置，其特征在于，所述事件处理单元在向云端设备发送事件消息时，具体执行：
    将包含事件标识的事件消息发送给云端设备；或者，
    将包含事件标识和该事件标识对应的事件参数的事件消息发送给云端设备。
  38. 根据权利要求33所述的装置，其特征在于，该装置还包括：
    注册接口，用于获取开发设备发送的或者在本地预置的功能模块注册文件；
    注册单元，用于依据所述功能模块注册文件，进行功能模块的注册。
  39. 根据权利要求38所述的装置，其特征在于，所述功能模块注册文件包括：
    各功能模块的初始化流程信息，用于在系统启动时自动运行各功能模块的初始化过程；或者，
    各功能模块支持上报的事件标识。
  40. 根据权利要求33所述的装置，其特征在于，所述事件处理单元，还用于接收所述云端设备返回的事件响应消息。
  41. 根据权利要求40所述的装置，其特征在于，所述事件处理单元，还用于在向所述云端设备发送事件消息的设定时长内未收到所述事件响应消息，则重新向所述云端设备发送所述事件消息。
  42. 根据权利要求33所述的装置，其特征在于，该装置还包括：
    消息接收单元，用于接收云端设备针对所述事件消息发送的第一消息，所述第一消息包括动作标识；
    消息发送单元，用于向所述云端设备返回第二消息，所述第二消息包括所述动作标识和动作状态，所述动作状态用于指示所述智能设备针对所述第一消息的动作执行状况。
  43. 根据权利要求42所述的装置，其特征在于，该装置还包括：
    确定单元，用于利用所述第一消息中包含的动作标识，确定注册的该动作标识对应 的控制参数，以便利用所述控制参数执行相应动作。
  44. 根据权利要求42所述的装置，其特征在于，所述第一消息中还包括所述动作标识对应的控制参数；
    所述智能设备利用所述控制参数执行相应动作。
  45. 根据权利要求42所述的装置，其特征在于，所述动作状态包括：
    指示接收到所述第一消息的第一状态；或者，
    指示依据所述动作标识对应的控制参数执行动作的准备工作已完成的第二状态；或者，
    指示依据所述动作标识对应的控制参数执行动作已完毕的第三状态；或者，
    指示依据所述动作标识对应的控制参数执行动作出现异常的第四状态。
  46. 一种用于物联网的事件处理装置，设置于智能设备，其特征在于，该装置包括：
    事件获取单元，用于获取功能模块的事件；
    事件处理单元，用于所述事件的注册信息，触发所述事件所联动的功能模块。
  47. 根据权利要求46所述的装置，其特征在于，该装置还包括：
    注册接口，用于获取开发设备发送的设备配置文件、用户配置的设备配置文件或者预置的设备配置文件；
    注册单元，用于依据所述设备配置文件，进行事件的注册。
  48. 根据权利要求46或47所述的装置，其特征在于，所述事件的注册信息包括：
    事件标识以及事件标识所联动的功能模块和执行指令。
  49. 根据权利要求48所述的装置，其特征在于，所述事件获取单元，具体用于获取功能模块上报的事件标识；
    所述事件处理单元，具体用于确定本地注册的所述事件获取单元获取的事件标识所联动的功能模块和执行指令；向所联动的功能模块发送确定出的执行指令。
  50. 根据权利要求46所述的装置，其特征在于，该装置还包括：
    注册接口，用于获取开发设备发送的或者在本地预置的功能模块注册文件；
    注册单元，用于依据所述功能模块注册文件，进行功能模块的注册。
  51. 根据权利要求50所述的装置，其特征在于，所述功能模块注册文件包括：
    各功能模块的初始化流程信息，用于在系统启动时自动运行各功能模块的初始化过程；或者，
    各功能模块支持上报的事件标识。
  52. 根据权利要求46所述的装置，其特征在于，所述事件处理单元，还用于接收云端设备返回的事件响应消息。
  53. 根据权利要求52所述的装置，其特征在于，所述事件处理单元，还用于在向所述云端设备发送事件消息的设定时长内未收到所述事件响应消息，则重新向所述云端设备发送所述事件消息。
  54. 根据权利要求46所述的装置，其特征在于，该装置还包括：
    消息接收单元，用于接收云端设备针对所述事件消息发送的第一消息，所述第一消息包括动作标识；
    消息发送单元，用于向所述云端设备返回第二消息，所述第二消息包括所述动作标识和动作状态，所述动作状态用于指示所述智能设备针对所述第一消息的动作执行状况。
  55. 根据权利要求54所述的装置，其特征在于，该装置还包括：
    确定单元，用于利用所述第一消息中包含的动作标识，确定注册的该动作标识对应的控制参数，以便利用所述控制参数执行相应动作。
  56. 根据权利要求54所述的装置，其特征在于，所述第一消息中还包括所述动作标识对应的控制参数；
    所述智能设备利用所述控制参数执行相应动作。
  57. 根据权利要求54所述的装置，其特征在于，所述动作状态包括：
    指示接收到所述第一消息的第一状态；或者，
    指示依据所述动作标识对应的控制参数执行动作的准备工作已完成的第二状态；或者，
    指示依据所述动作标识对应的控制参数执行动作已完毕的第三状态；或者，
    指示依据所述动作标识对应的控制参数执行动作出现异常的第四状态。
  58. 一种用于物联网的事件处理装置，其特征在于，该装置包括：
    事件接收单元，用于接收智能设备上报的包含事件信息的事件消息。
  59. 根据权利要求58所述的装置，其特征在于，所述事件信息包括：
    事件标识；或者，
    事件标识和事件标识对应的事件参数。
  60. 根据权利要求58所述的装置，其特征在于，该装置还包括：
    响应发送单元，用于在所述事件接收单元接收到所述事件消息后，向所述智能设备 返回事件响应消息。
  61. 根据权利要求58或59所述的装置，其特征在于，该装置还包括：
    记录单元，用于对所述事件信息进行记录；或者，
    消息发送单元，用于依据所述事件信息，向所述智能设备或者其他智能设备发送第一消息，所述第一消息包括动作标识。
  62. 根据权利要求61所述的装置，其特征在于，该装置还包括：
    消息接收单元，用于接收智能设备针对所述第一消息返回的第二消息，所述第二消息包括所述动作标识和动作状态，所述动作状态用于指示所述智能设备针对所述第一消息的动作执行状况。
  63. 根据权利要求61所述的装置，其特征在于，该装置还包括：
    确定单元，用于获取注册的所述动作标识对应的控制参数，将该控制参数包含在所述第一消息中。
  64. 根据权利要求62所述的装置，其特征在于，所述动作状态包括：
    指示接收到所述第一消息的第一状态；或者，
    指示依据所述动作标识对应的控制参数执行动作的准备工作已完成的第二状态；或者，
    指示依据所述动作标识对应的控制参数执行动作已完毕的第三状态；或者，
    指示依据所述动作标识对应的控制参数执行动作出现异常的第四状态。
  65. 一种设备，包括
    一个或者多个处理器；
    存储器；
    一个或者多个程序，所述一个或者多个程序存储在所述存储器中，被所述一个或者多个处理器执行以实现如下操作：
    获取功能模块的事件；
    依据所述事件的注册信息，向云端设备发送事件消息。
  66. 一种设备，包括
    一个或者多个处理器；
    存储器；
    一个或者多个程序，所述一个或者多个程序存储在所述存储器中，被所述一个或者多个处理器执行以实现如下操作：
    获取功能模块的事件；
    依据所述事件的注册信息，触发所述事件所联动的功能模块。
PCT/CN2017/087136 2016-06-17 2017-06-05 一种用于物联网的事件处理方法、装置和设备 Ceased WO2017215477A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/215,155 US10944587B2 (en) 2016-06-17 2018-12-10 Event processing associated with a smart device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610435323.2A CN107517236B (zh) 2016-06-17 2016-06-17 一种用于物联网的事件处理方法、装置和设备
CN201610435323.2 2016-06-17

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/215,155 Continuation-In-Part US10944587B2 (en) 2016-06-17 2018-12-10 Event processing associated with a smart device

Publications (1)

Publication Number Publication Date
WO2017215477A1 true WO2017215477A1 (zh) 2017-12-21

Family

ID=60664310

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/087136 Ceased WO2017215477A1 (zh) 2016-06-17 2017-06-05 一种用于物联网的事件处理方法、装置和设备

Country Status (4)

Country Link
US (1) US10944587B2 (zh)
CN (1) CN107517236B (zh)
TW (1) TW201800960A (zh)
WO (1) WO2017215477A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109445848A (zh) * 2018-11-07 2019-03-08 深圳市云威物联科技有限公司 设备联动方法及装置

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107342083B (zh) * 2017-07-05 2021-07-20 百度在线网络技术（北京）有限公司 用于提供语音服务的方法和装置
CN114924526A (zh) * 2022-06-28 2022-08-19 中国电信股份有限公司 信息交互方法、系统及云化可编程逻辑控制器
US12468645B2 (en) 2023-06-30 2025-11-11 Keysight Technologies, Inc. Methods, systems, and computer readable media for exposing features of an internet of things (IoT) device

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140164525A1 (en) * 2012-12-06 2014-06-12 At&T Intellectual Property I, L.P. Event management system
CN104104532A (zh) * 2013-04-07 2014-10-15 浙江大华技术股份有限公司 一种信息处理方法、装置及系统
CN104202353A (zh) * 2014-07-09 2014-12-10 武汉领傲科技有限公司 一种物联网互联协作系统的云事件处理方法及装置
US8977741B1 (en) * 2012-02-29 2015-03-10 Google Inc. Method and system for cloud computing service transparency
CN105182783A (zh) * 2015-09-24 2015-12-23 小米科技有限责任公司 用于控制智能设备的方法、装置及终端
CN105676655A (zh) * 2015-12-29 2016-06-15 青岛海尔智能家电科技有限公司 一种非AllJoyn设备之间的联动方法及装置

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10132333B4 (de) 2001-07-02 2006-05-24 Siemens Ag Verfahren und Netzanordnung zum Zugriff auf geschützte Ressourcen per Mobilfunk-Endgerät
CN100344099C (zh) 2004-03-24 2007-10-17 华为技术有限公司 一种在宽带数据智能网中实现客户端小窗口的方法
US8688820B1 (en) 2004-06-28 2014-04-01 Oracle America, Inc. Methods and apparatus for remote management and self management of servers
US20090070786A1 (en) 2007-09-11 2009-03-12 Bea Systems, Inc. Xml-based event processing networks for event server
US20120323690A1 (en) 2011-06-15 2012-12-20 Joseph Michael Systems and methods for monitoring, managing, and facilitating location- and/or other criteria-dependent targeted communications and/or transactions
US9413827B2 (en) 2013-02-25 2016-08-09 Qualcomm Incorporated Context aware actions among heterogeneous internet of things (IOT) devices
US20140337515A1 (en) * 2013-05-08 2014-11-13 Connectloud Method and Apparatus To Remotely Monitor Information Technology Infrastructure
CN104380796B (zh) 2013-06-03 2018-05-18 华为技术有限公司 一种无默认承载的切换方法和设备
US9871865B2 (en) 2013-07-11 2018-01-16 Neura, Inc. Physical environment profiling through internet of things integration platform
CN105659633B (zh) * 2013-08-29 2020-04-28 康维达无线有限责任公司 物联网事件管理系统以及方法
US9736688B2 (en) 2013-10-04 2017-08-15 Sol Mingso Li Systems and methods for programming, controlling and monitoring wireless networks
US9520054B2 (en) 2013-10-07 2016-12-13 Google Inc. Mobile user interface for smart-home hazard detector configuration
CN104679493B (zh) * 2013-12-02 2017-12-12 北京天地超云科技有限公司 一种流程化的事件处理机制的改进方法
WO2015089788A1 (en) 2013-12-19 2015-06-25 Telefonaktiebolaget L M Ericsson (Publ) Method and tv associated communication device for switching user personalized interface
CN103702402B (zh) 2013-12-20 2016-08-24 山西慧联网络技术有限责任公司 基于无线传感器网络的低功耗停车位状态收集方法
US9989942B2 (en) * 2013-12-30 2018-06-05 Qualcomm Incorporated Preemptively triggering a device action in an Internet of Things (IoT) environment based on a motion-based prediction of a user initiating the device action
CN103888261B (zh) 2014-03-24 2017-10-27 北京智谷睿拓技术服务有限公司 证书更新方法及装置
US10158536B2 (en) * 2014-05-01 2018-12-18 Belkin International Inc. Systems and methods for interaction with an IoT device
CN204014088U (zh) 2014-04-19 2014-12-10 青岛职业技术学院 智能无线广域安防监测物联网系统
CN104302018A (zh) 2014-09-27 2015-01-21 青岛高校重工机械制造有限公司 智能无线广域安防监测物联网系统
US9590976B2 (en) 2014-10-08 2017-03-07 Google Inc. Network-assisted fabric pairing
US9410712B2 (en) 2014-10-08 2016-08-09 Google Inc. Data management profile for a fabric network
US20160127928A1 (en) 2014-10-30 2016-05-05 Neil L. McClure Alert device system and method
US10051561B2 (en) 2014-12-02 2018-08-14 Telefonaktiebolaget Lm Ericsson (Publ) Methods and nodes for M2M communication
CN104486175A (zh) * 2014-12-11 2015-04-01 乐视致新电子科技（天津）有限公司 智能家居设备联动控制方法、路由器
US10505752B2 (en) 2014-12-15 2019-12-10 Samsung Electronics Co., Ltd. Electronic apparatus and method of controlling group action
CN104601695A (zh) 2015-01-14 2015-05-06 北京京东尚科信息技术有限公司 智能设备管控方法、装置和系统
CN104808499B (zh) * 2015-03-09 2019-01-15 联想(北京)有限公司 一种基于联动规则控制智能家居设备的方法及控制装置
CN105137765A (zh) 2015-05-15 2015-12-09 丰唐物联技术（深圳）有限公司 智能设备联动设置方法及终端
US10327276B2 (en) 2015-06-12 2019-06-18 Telefonaktiebolaget Lm Ericsson (Publ) Methods and network nodes for evaluating a connection
US9942696B2 (en) 2015-09-14 2018-04-10 Telefonaktiebolaget Lm Ericsson (Publ) Communicating event data from an event device to an action device
US10324773B2 (en) 2015-09-17 2019-06-18 Salesforce.Com, Inc. Processing events generated by internet of things (IoT)
CN105182784A (zh) 2015-09-24 2015-12-23 小米科技有限责任公司 控制智能设备的方法、装置及终端
CN105632494A (zh) 2015-12-29 2016-06-01 青岛海尔智能家电科技有限公司 智能家电设备的控制方法及装置
US9866637B2 (en) 2016-01-11 2018-01-09 Equinix, Inc. Distributed edge processing of internet of things device data in co-location facilities
CN105549572A (zh) * 2016-02-23 2016-05-04 北京小米移动软件有限公司 智能家居设备的控制方法、装置及设备
CN105704234B (zh) 2016-03-23 2019-08-13 浙江风向标科技有限公司 智能设备的控制方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8977741B1 (en) * 2012-02-29 2015-03-10 Google Inc. Method and system for cloud computing service transparency
US20140164525A1 (en) * 2012-12-06 2014-06-12 At&T Intellectual Property I, L.P. Event management system
CN104104532A (zh) * 2013-04-07 2014-10-15 浙江大华技术股份有限公司 一种信息处理方法、装置及系统
CN104202353A (zh) * 2014-07-09 2014-12-10 武汉领傲科技有限公司 一种物联网互联协作系统的云事件处理方法及装置
CN105182783A (zh) * 2015-09-24 2015-12-23 小米科技有限责任公司 用于控制智能设备的方法、装置及终端
CN105676655A (zh) * 2015-12-29 2016-06-15 青岛海尔智能家电科技有限公司 一种非AllJoyn设备之间的联动方法及装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109445848A (zh) * 2018-11-07 2019-03-08 深圳市云威物联科技有限公司 设备联动方法及装置

Also Published As

Publication number Publication date
US20190182070A1 (en) 2019-06-13
US10944587B2 (en) 2021-03-09
CN107517236A (zh) 2017-12-26
TW201800960A (zh) 2018-01-01
CN107517236B (zh) 2021-06-15

Similar Documents

Publication Publication Date Title
WO2017215476A1 (zh) 一种用于物联网的智能设备控制方法、装置和设备
US11196742B2 (en) Method, system, and device for communicating data between devices to control one of the devices
CN108289110B (zh) 设备关联方法、装置、终端设备和操作系统
WO2021190357A1 (zh) 故障检测方法及设备
WO2017215477A1 (zh) 一种用于物联网的事件处理方法、装置和设备
JP2015097107A (ja) モバイルオペレーティング環境のための、イベント制御された連続的なロギングを提供すること
JP2017510182A (ja) ワイヤレスセンサネットワーク
WO2017177830A1 (zh) 基于二维码以对被监护人进行寻找的方法及系统
JP2011509635A (ja) 携帯機器管理スケジュールシステム及び方法
US10750076B2 (en) Network device, image processing method, and computer readable medium
CN109005096B (zh) 应用交互方法及装置
CN112910744A (zh) 智能设备控制方法及装置、存储介质及电子设备
CN117641113B (zh) 算法管理方法及系统
CN112671897B (zh) 分布式系统的访问方法、装置、存储介质、设备和产品
CN106210800A (zh) 一种多个智能电视间用户操作行为的同步方法及系统
US20220150348A1 (en) Method for Service Decision Distribution Among Multiple Terminal Devices and System
CN105653433B (zh) 一种应用程序的追踪方法及装置
CN105610880B (zh) M2m通信架构、信息交互方法及装置
CN113283350A (zh) 操作事件的提示方法及装置、存储介质及电子装置
CN108279830A (zh) 用于动作分析的方法、装置和移动终端
CN118264711A (zh) 基于mqtt协议的设备控制系统、方法、装置、设备及介质
US11442843B2 (en) Methods and systems for identifying, handling, and debugging a hung thread
HK1248423A1 (zh) 一种用於物联网的事件处理方法、装置和设备
CN113067757A (zh) 信息发送和存储方法、装置和介质
CN119128006B (zh) 一种面向分布式链路追踪框架的数字对象查询方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17812588

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17812588

Country of ref document: EP

Kind code of ref document: A1