Rule-based Attribute Discovery

Abstract

A software system for use with a network controller is disclosed. The software system includes a plurality of modules, where some of the modules are specific to the network protocol used by the network controller. Other modules can be used for various network protocols without modification. In this way, the development of network controller software can be simplified, thereby reducing the development time. In addition, the system allows attributes and rules to be added flexibly at any time without modifying most of the system. The software system includes an attribute memory, a parser engine, a frame processor, a frame transmitter, and a frame receiver.

Description

Technical Field

[0001] The present invention describes systems and methods for discovering and modifying attributes associated with devices within a wireless network using a set of rules. Background Art

[0002] In some networks, there can be multiple network devices and one or more gateway controllers. These network devices can be input devices that forward information to the gateway controller or output devices that receive information from the gateway controller. In a particular example, the network can be a smart home network.

[0003] Determining and modifying the value of each state on each network device within a wireless network can be a tedious task. For example, for the Z-Wave protocol, there are three separate commands to request the value of a status or attribute and to modify the value of that status. This can be even more complex because these commands can vary based on the category of the network device. Other wireless protocols can be similarly complex.

[0004] Accordingly, it would be beneficial to have a system and method that simplifies this process. Additionally, it would be beneficial if the system and method utilized a data model that allowed for a rules-based approach. In this way, while the rules can be specific to the network protocol, the main software components of the system can be used for any wireless network protocol. Summary of the Invention

[0005] A software system for use with a network controller is disclosed. The software system includes multiple modules, where some of the modules are specific to the network protocol used by the network controller. Other modules can be used for various network protocols without modification. In this way, the development of software for the network controller can be simplified, thereby reducing development time. Additionally, the system allows for the flexible addition of attributes and rules at any time without the need for significant modification to most of the system. The software system includes an attribute memory, a parser engine, a frame processor, a frame sender, and a frame receiver.

[0006] According to one embodiment, a software system for use with a network controller is disclosed, wherein the software system includes a plurality of software modules disposed on a non-transitory computer-readable storage medium. The plurality of software modules includes: an attribute memory for storing information about each node in the network and attributes associated with each node; a parser engine for determining an action to be performed based on values of the attributes in the attribute memory; a frame processor including a plurality of synthesizer functions for creating a payload based on the action requested by the parser engine; a frame transmitter for combining the payload and network-specific information to form a data packet and sending the data packet to a network device; and a frame receiver for receiving incoming data packets and forwarding the incoming data packets to the frame processor. In some embodiments, the parser engine and the attribute memory are configured to operate with a plurality of different network protocols without modification. In certain embodiments, the attribute memory is configured as a state tree representation, wherein each attribute has a parent, a type, a reported value, and an expected value. In some embodiments, the frame processor registers rules with the parser engine such that, for each attribute type, a rule is registered that defines a GET synthesizer function for creating a payload to obtain the value of the attribute and a SET synthesizer function for creating a payload to modify the value of the attribute. In certain embodiments, if the expected value of an attribute is different from the reported value of the attribute, the parser engine invokes the SET synthesizer function associated with the attribute. In some embodiments, if the reported value of an attribute is a null value, the parser engine invokes the GET synthesizer function associated with the attribute. In certain embodiments, the frame transmitter obtains network-specific information from the attribute memory to form a data packet. In some embodiments, the frame transmitter returns a state to the parser engine and updates the attribute memory based on the state. In some embodiments, if the network device reports that the attribute has been successfully modified, the reported value of the attribute is updated to the expected value. In some embodiments, if the network device does not report that the attribute has been successfully modified, the reported value of the attribute is updated to a null value. In certain embodiments, the parser engine receives a notification that a node is unavailable and is configured to suspend all operations associated with the node and any child attributes associated with the node. In some embodiments, the frame transmitter determines that a plurality of data packets are associated with an attribute and creates a multicast data packet to combine the plurality of data packets. In certain embodiments, the frame receiver receives a data packet from a network device and updates the reported value of the attribute based on the data in the data packet.

[0007] According to another embodiment, a network controller is disclosed. The network controller includes: a processing unit; a network interface; and a storage device, wherein the above software system is disposed in the storage device.

[0008] According to another embodiment, a method of operating a network controller is disclosed. The method includes creating an attribute memory in the network controller, wherein the attribute memory is configured as a state tree representation to store information about each node in the network and attributes associated with each node, wherein each attribute has a reported value and an expected value; detecting that the reported value of a first attribute does not match the expected value; looking up a rule associated with the first attribute, wherein each rule includes a GET synthesizer function and a SET synthesizer function associated with the attribute; using the SET synthesizer function associated with the first attribute defined in the rule to create a payload of a data packet; obtaining network-specific information from the attribute memory; merging the network-specific information and the payload into the data packet; and sending the data packet to a network device to modify the value of the first attribute. In some embodiments, if the network device reports that the first attribute has been successfully modified, the reported value of the first attribute is updated to the expected value. In certain embodiments, if the network device does not report that the attribute has been successfully modified, the reported value of the first attribute is updated to a null value.

[0009] According to another embodiment, a method of operating a network controller is disclosed. The method includes creating an attribute memory in the network controller, wherein the attribute memory is configured as a state tree representation to store information about each node in the network and attributes associated with each node, wherein each attribute has a reported value and an expected value; detecting that the reported value of a first attribute is a null value; looking up a rule associated with the first attribute, wherein each rule includes a GET synthesizer function and a SET synthesizer function associated with the attribute; using the GET synthesizer function associated with the first attribute defined in the rule to create a payload of a data packet; obtaining network-specific information from the attribute memory; merging the network-specific information and the payload into the data packet; and sending the data packet to a network device to obtain the value of the first attribute. In certain embodiments, the method further includes receiving a data packet from the network device, wherein the data packet contains the value of the first attribute; and updating the reported value of the first attribute to the value contained in the data packet. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] To better understand the present invention, reference is made to the accompanying drawings, in which like numerals represent like elements, wherein:

[0011] Figure 1 is a block diagram of a representative network device;

[0012] Figure 2 illustrates the communication that occurs in a network having multiple network devices, including a gateway controller and multiple network devices, according to one embodiment;

[0013] Figure 3Shows a state tree representation according to one embodiment;

[0014] Figure 4 Shows a state tree representation according to a second embodiment;

[0015] Figure 5 Shows a block diagram illustrating the software architecture on a gateway controller;

[0016] Figure 6 Shows a sequence that can be executed to obtain the value of an attribute; and

[0017] Figure 7 Shows a sequence that can be executed to modify the value of an attribute. Detailed Description

[0018] Figure 1 Shows a block diagram of a representative network device 10. The network device can be used as an input device, an output device, or a gateway controller, as described in more detail below.

[0019] As Figure 1 shown, the network device 10 has a processing unit 20 and an associated storage device 25. The processing unit 20 can be any suitable component, such as a microprocessor, an embedded processor, an application-specific circuit, a programmable circuit, a microcontroller, or other similar devices. The storage device 25 contains instructions that, when executed by the processing unit 20, enable the network device 10 to perform the functions described herein. The storage device 25 can be a non-volatile memory, such as flash memory (FLASH ROM), electrically erasable read-only memory, or other suitable devices. In other embodiments, the storage device 25 can be a volatile memory, such as random access memory (Random Access Memory, RAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM).

[0020] The network device 10 further includes a network interface 30, and the network interface 30 can be a wireless interface including an antenna 35. The network interface 30 can support any wireless network that supports multicast (e.g., Wi-Fi), a network using the Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard (e.g., Zigbee), a network using the IEEE 802.15.6 standard, and a wireless smart home protocol (e.g., Z-Wave). The network interface 30 is used to allow the network device to communicate with other devices arranged on the network 31.

[0021] The network device 10 may include a second storage device 40, which stores data received and transmitted by the network interface 30. This second storage device 40 is traditionally a volatile memory. The processing unit 20 has the ability to read from and write to the second storage device 40 in order to communicate with other nodes in the network 31. Although not shown, the network device 10 also has a power source, which may be a battery or a connection to a permanent power source (such as a wall socket).

[0022] Although the storage device 25 is disclosed, any computer-readable medium may be used to store these instructions. For example, a read only memory (ROM), a random access memory (RAM), a magnetic storage device (such as a hard disk drive), or an optical storage device (such as a Compact Disk (CD) or a Digital Versatile Disc (DVD)) may be employed. Additionally, these instructions may be downloaded into the storage device 25 via a network connection (not shown), via a CD ROM, or by other mechanisms. These instructions may be written in any programming language, without being limited by the present invention. Thus, in some embodiments, there may be multiple computer-readable media containing the instructions described herein. As Figure 1 shown, the first computer-readable medium may communicate with the processing unit 20. The second computer-readable medium may be a CDROM or a different storage device located away from the network device 10. The instructions contained on this second computer-readable medium may be downloaded onto the memory device 25 to allow the network device 10 to execute the instructions.

[0023] Although the processing unit 20, the storage device 25, the network interface 30, and the second storage device 40 are shown as separate components in Figure 1 it should be understood that some or all of these components may be integrated into a single electronic component. More precisely, Figure 1 they are used to illustrate the functions of the network device 10 rather than its physical configuration.

[0024] Figure 2 A network 100 with multiple network devices and a gateway controller 150 is shown. The multiple network devices may include one or more input devices (such as a wall switch 110), and one or more output devices (such as a first lamp 120 and a second lamp 130). The wall switch 110 may have multiple buttons 111, 112. Although the wall switch 110 is disclosed, the input device is not limited to this embodiment. The input device may also be a doorbell, a sensor (such as a thermal sensor, a smoke sensor, a motion sensor, a thermometer), or any other input device. Similarly, the output device does not need to be a lamp; other output devices may be such as window covering actuators, audio-visual devices, door locks, or thermostats.

[0025] Each of these devices can be a network device having the above-mentioned and Figure 1 components shown. The architecture of the gateway controller 150 can be different from that of other devices. For example, the gateway controller 150 can have a more powerful processing unit 20. The storage device 25 and the second storage device 40 of the gateway controller 150 can be larger than the storage device 40 in other devices. In addition, the gateway controller 150 can be powered by a wall socket instead of a battery.

[0026] In a particular embodiment, the network 100 can be a Z-WAVE network. The Z-WAVE protocol defines multiple command classes, such as the central scene command class, the multi-level switch command class, the color switch command class, the sound switch command class, and the window covering command class, etc.

[0027] In some embodiments, the gateway controller 150 needs to know the value of each state or property in each network device that is part of the wireless network. Therefore, the gateway controller 150 can send data packets 200, 210, and 220 to the wall switch 110, the first lamp 120, and the second lamp 130 respectively. The devices can return information to the gateway controller 150 via data packets 230, 240, and 250 respectively. The gateway controller 150 needs to save all the information it receives.

[0028] One method is to create a state tree representation for the gateway controller 150, as Figure 3 shown. Although this state tree representation refers to the Z-Wave embodiment, these concepts are equally applicable to other network protocols.

[0029] In this figure, each property or state in each network device in the wireless network is represented by a box in the tree. The tree is organized in a hierarchical manner. Each box contains a type, which can be a root, a node, an endpoint, a property, or other types. In addition, each box contains a state name. The box also includes the reported value of the state and the expected value of the state.

[0030] For example, the gateway controller 150 can be the root of a tree and have a network identity (HomeID) of FB E6 8C CE. In other network protocols, this field may be referred to as a network identity (Identity, ID). Additionally, the gateway controller 150 can be wirelessly connected to two nodes. The first node has a node ID of 03, two endpoints, and two associated attributes. One endpoint has an endpoint ID of 00 and includes two attributes, a binary switch version and a binary switch value. The second endpoint has an endpoint ID of 01 and an attribute of a binary switch value. Further, the two attributes associated with the first node are related to a security key and a role type. For example, a status tree representation can store the keys granted to each node. The second node has a node ID of 04 and has one associated endpoint. This endpoint has an endpoint ID of 00 and two attributes. In this configuration, the first attribute is an association group. The second attribute is an attribute of the first attribute and is thus shown as a child of the first attribute. The second attribute represents the association group content. The association group content is a list of node IDs that belong to the association.

[0031] An association group is a feature of Z-Wave. Each node can have multiple associations, and each association is a set of rules that describe what happens when a given event occurs. For example, if a wall switch has a button, the rules can specify that when the button is activated, the gateway controller will send a BINARY_SWITCH_SET command to all nodes in group 1; and when the button is pressed, the gateway controller will send a BASIC_SET command to all nodes in group 2. Therefore, in order to represent association data, data needs to be stored under each group ID.

[0032] Of course, each node and endpoint can have a different number of nodes, endpoints, and / or a different number or groups of attributes and states. However, the boxes in this status tree representation, regardless of type, include a reported value and an expected value for their respective states. Additionally, in order to correctly represent the status tree representation, each box also includes a parent represented by the lines connecting Figure 3 the individual boxes. By creating the status tree representation in this way, the database can be used with any network protocol.

[0033] This status tree representation allows a rule-based system to be used to enumerate, query, and update all attributes associated with the gateway controller 150.

[0034] To implement this approach, the software can be divided into multiple software modules or programs. Some of these software modules or programs can be generic as they can be used with any network protocol. Other modules among these software modules can be specific to a network protocol.

[0035] A block diagram of a representative software architecture is as Figure 5As shown. The block diagram represents a software system including multiple different software modules. Each software module is arranged on a non-transitory storage medium that can be read and executed by a processing unit 20. For example, each software module can exist in a memory device 25.

[0036] Figure 5 A data structure used as an attribute memory 500 is shown. The attribute memory 500 is organized as a state tree representation stored in a storage device 25. As described in more detail below, the attribute memory 500 can be read and written by a processing unit 20. The format of the attribute memory 500 enables the attribute memory 500 to be used with any network protocol.

[0037] Various software modules are also shown. These modules can include a parser engine 510, a frame sender 530, a frame processor 520, and a frame receiver 540. The parser engine 510 is responsible for parsing information at initialization and updating the information as needed. The parser engine 510 is also common to all network protocols.

[0038] The frame sender 530 is used to send data packets to a desired network device using a specific network protocol. The frame sender 530 can also be responsible for creating any network-specific fields for the frame, such as a destination node, a source node, an encryption scheme, etc.

[0039] The frame receiver 540 is responsible for receiving incoming data packets. Like the frame sender 530, the frame receiver 540 is specific to the network protocol used.

[0040] The frame processor 520 is also specific to a particular network protocol. The frame processor 520 is a plurality of synthesizer functions responsible for parsing incoming data packets and creating a payload for outgoing data packets.

[0041] More specifically, the frame receiver 540 can receive a data packet. The received data packet is sent to the frame processor 520, which parses the information contained in the data packet. This information can include reported values of certain attributes in the attribute memory 500. In this case, the frame processor 520 will update the attribute memory 500 with the new reported values. In some embodiments, the new reported values of a particular attribute will mean that there are other attributes associated with that particular attribute. For example, the attribute of ASSOCIATION_GROUP_ID can have child attributes associated with it. Then, the frame processor 520 can create these new implicit child attributes in the attribute memory 500.

[0042] The parser engine 510 is responsible for determining which information in the attribute memory 500 needs to be retrieved or modified. For example, the parser engine 510 can receive a notification from the attribute memory 500 that a new attribute has been created or modified. In response, the parser engine 510 will send a frame synthesis request to the frame processor 520. Then, the appropriate synthesizer function in the frame processor 520 will synthesize the necessary data packet and return the data packet to the parser engine 510. Then, the parser engine 510 will pass this data packet to the frame sender 530, and the frame sender 530 adds headers and other network-specific information and sends the data packet to the intended network device.

[0043] Each action performed by the processing unit 20 will be described in more detail.

[0044] The first step is to register rules with the parser engine 510. The parser engine 510 is designed to be general-purpose and can thus be used with any network protocol. However, the rules and commands for each network protocol may be different. Therefore, the rules registered with the parser engine 510 are unique to a particular network protocol. For example, if the parser engine 510 is to be used in a gateway controller operating on a Z-Wave network, the frame processor 520 will be specific to Z-Wave. Each of the synthesizer functions in the frame processor 520 will register its rules with the parser engine 510. The rules can have the following format:

[0045] <attribute_id,GET_synthesizer,SET_synthesizer>

[0046] Therefore, the parser engine 510 has a rule book, where each rule has a specific attribute and the SET and GET synthesizer functions associated with that attribute. The multiple SET and GET synthesizers include the frame processor 520.

[0047] In other words, when the parser engine 510 encounters a situation where it needs to retrieve the value of a specific attribute, it references the rule associated with that specific attribute and calls the GET synthesizer function identified in the rule. Similarly, when the parser engine 510 encounters a situation where it needs to modify the value of a specific attribute, it references the rule associated with that specific attribute and calls the SET synthesizer function identified in the rule.

[0048] In addition, a send function can also be registered with the parser engine 510. The send function is used to actually send data packets and can be specific to the network. Therefore, the frame sender 530 can also register with the parser engine 510 so that the parser engine 510 uses a specific send function for each specific network protocol.

[0049] Once the various software functions are enumerated and registered, the gateway controller 150 must create an attribute memory 500 organized as a state tree representation. In some embodiments, this function may be performed by the parser engine 510. In other embodiments, network-specific software modules may be used to create the state tree representation or at least a portion of the state tree representation.

[0050] During the network discovery process, each time a new node is discovered, the node and its nodeID are added to the state tree representation directly below the HomeID box, as Figure 3 shown. In other words, the state tree is constructed by iteratively collecting information.

[0051] The process of creating the state tree representation is explained below.

[0052] When the gateway controller 150 is reset, the network is empty and the attribute memory 500 includes only a HomeID node and a NodeID node for the gateway controller itself.

[0053] When a network device is added to the network, the NodeID of the new network device is added. Information known about the node and the time it was included is also added. For example, this information may include the granted security key and Z-Wave node information (NodeInformation, NIF) frames, as well as the fact that the node always has endpoint 0. The NIF frame has a list of Z-Wave command classes supported by the node (an example of a command class is BINARY_SWITCH).

[0054] The attribute memory 500 has a callback system that allows the parser engine 510 to execute a function whenever the value of an attribute is created, deleted, or changed. As Figure 5 shown, whenever an attribute is created, changed, or deleted, the attribute memory 500 communicates with the parser engine 510. The callback in the attribute memory 500 is monitoring the NIF attribute and when this attribute changes, a version attribute is created for each command class that has neither an expected value nor a reported value. Now the parser engine 510 executes because it has rules registered for the version attribute. The parser engine 510 requests the frame processor 520 to synthesize a data packet and then sends the packet using the frame sender 530.

[0055] When a version of a command class is obtained, a monitoring function is registered for this command class. For example, a version of such a command class could be the BINARY_SWITCH_VERSION attribute. This monitoring function will create a BINARY_SWITCH_VALUE attribute. If the version is greater than 1, the monitoring function will also create a BINARY_SWITCH_CAPABLITIES attribute. Similarly, this attribute has parsing rules assigned to allow the parsing of information.

[0056] In some embodiments, some Z-Wave frame processors not only set the reported values in the property memory 500, but also create new properties that allow for further parsing. For example, the ASSOCIATION_GROUPINGS_REPORT frame processor will read a node with 3 association groups, so it will create 3 ASSOCIATION_GROUP_ID properties in the property memory 500 and add an ASSOCIATION_GROUP_CONTENT property (with no expected value or reported value) under each group ID. Similarly, the parser engine 510 will execute and obtain the required information.

[0057] This process continues until all nodes and properties have been parsed.

[0058] In addition, if during the network discovery process it is determined that a node is no longer part of the network, the state tree representation can be updated by deleting the node. In addition, all properties associated with the node are also deleted (i.e., all boxes that have the deleted node as a parent).

[0059] Thus, after discovery is complete, a property memory 500 with a state tree representation of each node in the network is created. Once created, the gateway controller 150 can query various states to find their reported values. This can be achieved as follows.

[0060] At initialization, the reported value of each state and property can be set to a null value, which indicates that the value has not been reported or is unknown. In other embodiments, the initial value can be known. A tree discovery engine can be used to parse the state tree and discover all properties that do not have a reported value. In some embodiments, the tree discovery engine is independent of the parser engine 510. For example, the tree discovery engine can be incorporated into the property memory 500. In other embodiments, the tree discovery engine passes the properties to the parser engine 510. Then, the parser engine 510 requests the frame processor 520 to synthesize a frame using an appropriate GET frame synthesizer. The frame processor 520 uses the context properties to construct the payload of the frame with the appropriate commands and parameters. Once the payload of the frame has been synthesized, the frame processor 520 indicates that the frame has been synthesized, as Figure 5 shown. Then, the parser engine 510 forwards the payload to the frame sender 530, which adds network-specific information and sends the data packet.

[0061] The GET synthesizer function is used to obtain the value of a status or property from a node, endpoint, or other device. In some embodiments, the rules are specific to the type of property being queried. For example, the GET synthesizer functions for different endpoints of Node 03 to determine the value of BINARY_SWITCH_VALUE can be the same. However, the GET synthesizer function can be different from the GET synthesizer function used to obtain BINARY_SWITCH_VERSION. The GET synthesizer functions can be generated manually. In other embodiments, some or all of the synthesizer functions can be automatically generated from an XML file.

[0062] As shown above, the rules can have the following format:

[0063] <attribute_id, GET_synthesizer, SET_synthesizer>

[0064] In other words, for each property type, there is a GET synthesizer function that creates the payload of the frame required to obtain the value of that property from a network device; and a SET synthesizer function that creates the payload of the frame required to modify the value of that property from a network device.

[0065] In some embodiments, the above status tree representation can be used for Z-Wave wireless networks. In this embodiment, each command class can have a dedicated GET synthesizer function. In some further embodiments, each property associated with each command class can have a dedicated GET synthesizer function.

[0066] In each case, the parser engine 510 selects the appropriate GET synthesizer function to generate the payload for a data packet requesting the value of the property or status. In some embodiments, various parameters in the data packet can be populated based on the position of the property in the status tree representation, as explained in more detail below. The parser engine 510 can use other reported statuses to generate the frame. An example can be as follows: "What is the association group ID of endpoint 00 in Node 04". In this case, the frame transmitter 530 will use the information from the status tree representation, namely the NodeID and the endpoint number. Then, the parser engine 510 uses the appropriate GET synthesizer function to generate the payload of the data packet pointing to that endpoint, which has the specific command required to trigger the endpoint to return the value of the association group.

[0067] Figure 6Shows the steps for obtaining the value of an attribute in the attribute memory 500. First, as shown in block 600, the parser engine 510 can receive a callback or notification from the attribute memory 500 where the reported value of a certain attribute is now empty or unknown. In response, the parser engine 510 will scan the registered rules to find the rule associated with that attribute, as shown in block 610. The parser engine 510 will then call the GET synthesizer function in the frame processor 520 associated with that attribute, as shown in block 620. As shown in block 630, the frame processor 520 will create a payload for the data packet that will be used to obtain the value of the parameter and notify the parser engine 510 when done. The frame processor 520 can also return the status associated with that payload. The status can report success, indicating that the parser engine does not send a frame, or notify the parser engine 510 that additional frames are needed. Then, the parser engine 510 will call the send function (i.e., the frame transmitter 530) and pass the payload to the frame transmitter 530, as shown in block 640. Then, the frame transmitter 530 will parse the attribute memory 500 based on the position of the attribute in the tree, as shown in block 650. Once found, the frame transmitter 530 will navigate up to determine the endpoint and node that the data packet is to be used for. Then, the frame transmitter 530 will create the network-specific fields of the data packet such as the destination node, source node, encryption scheme, and other fields, and then send the completed data packet, as shown in block 660. Finally, the frame transmitter 530 will return a success status to the parser engine 510, as shown in block 670.

[0068] Note that the attribute memory 500 and the parser engine 510 do not need to have any knowledge of the network protocol being used. This information is only contained in the frame processor 520 and the frame transmitter 530.

[0069] At a later time, a data packet containing the value of the attribute can be received. As shown in block 680, the data packet is received by the frame receiver 540 and passed to the frame processor 520. Then, the frame processor 520 parses the data packet and updates the reported value of the attribute in the attribute memory 500, as shown in block 690. Then, the attribute memory 500 can send a notification or callback to the parser engine 510 indicating that the reported value of the attribute has been updated. Alternatively, the frame processor 520 can notify the parser engine 510 when the value of the attribute is received.

[0070] In addition to obtaining the current values of various states or attributes, it would be advantageous to change or set the value of one or more of these attributes or states. Thus, the SET synthesizer function can be used to modify the value of a state or attribute. For example, if the expected value of a state or attribute is different from the reported state, the SET synthesizer function can be called. Figure 7 Shows the sequence of steps for modifying the value of an attribute.

[0071] First, update the expected value of the attribute so that the expected value of the attribute is different from the reported value. For example, a user interface can be used to change the expected value. Additionally, operations of other network devices can cause the expected value of the attribute to change. When the expected value does not match the reported value, the attribute memory 500 can send a callback or notification to the parser engine 510, as shown in block 700. In response, the parser engine 510 scans the registered rules, as shown in block 710, and selects the SET synthesizer function to generate the payload of the data packet that instructs a node or endpoint to set a certain state or attribute to the expected value, as shown in block 720. An example might be as follows: "Change the associated group ID of endpoint 00 in node 04 to 05". In this case, the SET synthesizer function will use the information passed from the parser engine 510, i.e., the attribute and the expected value. Then, the SET synthesizer function will generate the payload for the data packet using the specific command required to trigger the endpoint to modify the value of the associated group ID. Then, the frame processor 520 notifies the parser engine 510 that the payload has been created, as shown in block 730.

[0072] Then, the parser engine 510 passes the payload to the send function (i.e., the frame transmitter 530), as shown in block 740.

[0073] Then, the frame transmitter 530 parses the attribute memory 500 based on the position of the attribute in the tree, as shown in block 750. Once found, the frame transmitter 530 will navigate upward to determine the endpoint and node that the data packet is intended for. Then, the frame transmitter 530 will create the network-specific fields of the data packet such as the destination node, source node, encryption scheme, and other fields, and then send the completed data packet, as shown in block 760. Finally, the frame transmitter 530 returns a success status to the parser engine 510, as shown in block 770. In some embodiments, the frame transmitter 530 can receive an immediate confirmation from the destination node that the attribute has been updated. In this case, the reported value of the attribute is now updated to the expected value, as shown in block 780. However, in other embodiments, the destination node may not provide a confirmation that the attribute has been modified. In this embodiment, the reported value of the attribute can be set to a null value, as shown in block 780. This operation will cause a notification to be sent to the parser engine 510, which will trigger Figure 6 the start of the process shown.

[0074] By using the GET and SET synthesizer functions, the parser engine 510 can collect and modify data in an Internet of Things (IoT) network using the following logic:

[0075] - If the reported value of the state is not found and there is a rule for that state, the request frame processor 520 constructs a frame using the relevant GET synthesizer function and sends the frame using the frame transmitter 530. When a "REPORT" frame is received from a network device, the reported state is updated in the state tree. In this way, the parser logic will not be executed again.

[0076] - If the expected value of the state is different from the reported value and there is a SET rule for that state, an appropriate payload is constructed for the data packet using the appropriate SET synthesizer function and sent using the frame transmitter 530. If the device supports application-level verification (such as Z-Wave supervision or a similar protocol), the reported value of the state can be updated upon receipt of the verification. However, if the device does not support application-level verification, the reported value and the expected value of the state can be cleared after the data packet is passed. Clearing the reported value will trigger the parser engine 510 to call the appropriate GET synthesizer function to verify the most recently reported state value, which is expected to verify that the previously sent expected value has been accepted. Clearing the expected value will ensure that the data packet created by the SET rule is not resent.

[0077] The following provides a detailed example using the state tree representation and the GET and SET synthesizer functions. In this example, it is assumed that the wireless protocol is Z-Wave, but other protocols can also be used. The configuration of a Z-Wave network can be represented by Figure 4 the state tree shown.

[0078] In Z-Wave, the state of a light will be controlled by three data frames:

[0079] - BINARY_SWITCH_SET

[0080] - BINARY_SWITCH_GET

[0081] - BINARY_SWITCH_REPORT

[0082] The command BINARY_SWITCH_SET is used to set the state of the light. The binary representation of this command is as follows:

[0083] [0x25, 0x01, <value>, where a value of value equal to 0 will turn off the light, while any other value will turn on the light.

[0084] The command BINARY_SWITCH_GET is used to trigger the light to send a BINARY_SWITCH_REPORT. The binary representation of the BINARY_SWITCH_REPORT command is [0x25, 0x02].

[0085] The command BINARY_SWITCH_REPORT is sent by the light as a response to the BINARY_SWITCH_GET command. The binary representation of the command is as follows:

[0086] [0x25, 0x03, <value>, where the value `value` is the current state of the light, and where 0 means the light is off and any other value means the light is on.

[0087] For lights that support the BINARY_SWITCH command, there is a state variable related to BINARY_SWITCH_VALUE. The light can also have many other states, but those states are not included in this example.

[0088] It is now obvious that two frame synthesizer functions can be registered for the BINARY_SWITCH_VALUE state; a GET synthesizer function that is used to construct the payload of a data packet to obtain the value of the BINARY_SWITCH_VALUE state from a network device, and a SET synthesizer function that is used to construct the payload of a data packet to modify the value of the BINARY_SWITCH_VALUE state.

[0089] The parser engine 510 will monitor all attributes of type BINARY_SWITCH_VALUE in the property memory 500 and call the registered frame synthesizer functions when needed. In some embodiments, the monitoring of the attributes is performed by setting a callback function within the property memory 500.

[0090] The parser engine 510 will locate the state variable in the state tree: {type:node,reported:3}->

[0091] {type:endpoint,reported:0}->

[0092] {type:binary_switch_value,desired:null,reported:null}.

[0093] Since the value of the light is unknown, the parser engine 510 needs to find the rule for the BINARY_SWITCH_VALUE attribute. The rules associated with the BINARY_SWITCH_VALUE attribute include two synthesizers: the GET synthesizer function and the SET synthesizer function. The GET synthesizer function is called and given {type:BINARY_SWITCH_VALUE,reported:null} as an argument. For this command, since the frame payload of the command is static, the parsed object is not actually used. Once the frame is synthesized, the frame is passed to the frame sender 530, which can build the rest of the frame data based on the path in the state tree. In this case, the node: 03, endpoint: 00. Then, the frame sender 530 sends the data packet to the desired destination node.

[0094] Now, the network device responds to the data packet sent from the gateway controller 150 by sending a BINARY_SWITCH_REPORT received by the frame receiver 540. In this example, it is assumed that the response value of the network device to the BINARY_SWITCH_VALUE attribute is 0xff. When the data packet is received from node: 03, endpoint: 00, the status variable:

[0095] {type:node,reported:3}->

[0096] {type:endpoint,reported:0}->

[0097] {type:BINARY_SWITCH_VALUE,reported:null}

[0098] is located in the tree.

[0099] Then the BINARY_SWITCH_VALUE is updated as follows:

[0100] {type:BINARY_SWITCH_VALUE,desired:null,reported:0xff}.

[0101] The parser engine 510 now knows that the BINARY_SWITCH_VALUE attribute has been fully parsed.

[0102] If it is now necessary to turn off the light, the status parameter is set as follows:

[0103] {type:node,reported:3}->

[0104] {type:endpoint,reported:0}->

[0105] {type:BINARY_SWITCH_VALUE,reported:0xff,desired:0x00}.

[0106] The parser engine 510 sees a mismatch between the expected value and the reported value. Alternatively, the callback function in the property memory 500 can detect this mismatch and send a notification or callback to the parser engine 510. Then, the parser engine 510 finds the rule associated with the BINARY_SWITCH_VALUE property and calls the SET frame synthesizer again with the object {type:BINARY_SWITCH_VALUE,reported:0xff,desired:0x00} as the parameter. The SET frame synthesizer will read the expected value of the state and generate the payload of the frame. The frame transmitter and the module used with the GET synthesizer function are the same module. If the device has positively confirmed that the set operation has been performed, the reported value and the expected value are set to the same value. If the device cannot verify this, the reported value is cleared to trigger a new GET rule. In Z-Wave, this depends on whether the device supports the SUPERVISION command class; other Radio Frequency (RF) technologies can have other ways to perform this verification.

[0107] In addition, the parser engine 510 can extend to the temporary exemption branch of the state tree to avoid being parsed. This feature can be used to handle nodes that are known to be temporarily offline, such as Z-Wave wake-up nodes or Zigbee sleeping devices. For example, the frame processor 520 can receive a packet from a specific node indicating that it is entering the sleep mode. The frame processor 520 can notify the parser engine 510 to pause all actions associated with a specific node or endpoint in the network because the specific node or endpoint is unavailable. This pause also includes all properties that are children of that node or endpoint. Later, the frame processor 520 can receive a message from that node indicating that the node is now in the wake-up state. In response, the frame processor 520 will notify the parser engine 510 to resume operations on that node or endpoint and all child properties associated with that node or endpoint.

[0108] Another feature of the state manager is that by leveraging a set of rules, it is easy to determine which state adjustments result in the same frame data. This system can be used to determine whether the state can be resolved by using multicast frames to multiple nodes simultaneously. Since each property has a unique SET synthesizer function, it can be inferred that the application frame data (i.e., the payload) of two state variables of the same type can be the same.

[0109] In other words, keeping all state information in the state tree can detect whether more than one state can be resolved using multicast frames. The algorithm to perform this operation can be as follows:

[0110] 1. Establish a set of all states that need to be resolved;

[0111] 2. Select the element to be parsed from the set;

[0112] 3. Check if there are other states in the set of the same type;

[0113] 4. If the frame synthesizer for the state generates the same payload and has an encryption class, the frame can be parsed via multicast.

[0114] This function can be incorporated into the frame transmitter 530 or the parser engine 510.

[0115] Accordingly, in one embodiment, a system for use with a network controller is disclosed. The system includes a plurality of software modules (including the attribute memory 500, the parser engine 510, the frame processor 520, the frame transmitter 530, and the frame receiver 540). As described above, the attribute memory 500 and the parser engine 510 can be configured such that they are available for any network protocol. The remaining modules are customized according to the specific network protocol used by the network controller.

[0116] In another embodiment, a gateway controller having the above software is disclosed. The controller includes a processing unit 20, a network interface 30, and at least one storage device 25 in communication with the processing unit 20. The storage device includes data structures and instructions that enable the processing unit to execute the above software modules.

[0117] In another embodiment, a method for obtaining and modifying attributes in a network is disclosed. The method includes populating an attribute memory with a state tree representation of nodes and their associated attributes. The method also includes using a set of rules, where each attribute type has a rule associated therewith, where the rules include a GET synthesizer function and a SET synthesizer function. The method also includes selecting an appropriate GET synthesizer function when the attribute in the attribute memory has an unknown reported value. The method also includes selecting an appropriate SET synthesizer function when the reported value of the attribute does not match the expected value of the attribute.

[0118] This system has many advantages. First, the parser engine 510 and the attribute memory 500 are independent of the network protocol. In other words, the same software can be used for Z-Wave, Bluetooth, Zigbee, or other network protocols. This can reduce future development time associated with creating controller software. Additionally, the architecture described herein is very flexible. In other words, there are no restrictions on what can be classified as an attribute. For example, if desired, an attribute named "Firmware update" can be created. The specific rule associated with this attribute can be a specific rule that enables the frame processor 520 to create a data packet for delivering a new firmware update to a desired node. This concept also applies to any other attributes that may be required.

[0119] The scope of the present invention is not limited by the specific embodiments described herein. In fact, various other embodiments and modifications of the present invention will be apparent to those of ordinary skill in the art in addition to the embodiments and modifications described herein, based on the foregoing description and the drawings. Accordingly, such other embodiments and modifications are intended to fall within the scope of the present invention. Further, although the present invention has been described herein for a particular purpose in a particular implementation in a particular environment, those of ordinary skill in the art will recognize that its use is not limited thereto, and that the present invention can be beneficially implemented in any number of environments for any number of purposes. Accordingly, the following claims should be construed in accordance with the full breadth and spirit of the present invention as described herein.

[0120] This application claims priority to U.S. Patent Application No. 17 / 410,258, filed on August 24, 2021, the disclosure of which is hereby incorporated by reference in its entirety.< / value> < / value>

Claims

1. A software system for use with a network controller, comprising: A plurality of software modules, provided on a non-transitory computer-readable storage medium, the plurality of software modules including: An attribute memory for storing information about each node in a network and attributes associated with each node; A parser engine for determining an action to be performed based on values of attributes in the attribute memory; A frame processor including a plurality of synthesizer functions to create a payload based on the action requested by the parser engine; A frame transmitter that combines the payload and network-specific information to form a data packet and transmits the data packet to a network device; and A frame receiver for receiving incoming data packets and forwarding the incoming data packets to the frame processor.

2. The software system according to claim 1, wherein, The parser engine and the attribute memory are configured to operate with a plurality of different network protocols without modification.

3. The software system according to claim 1, wherein, The attribute memory is configured as a state tree representation, wherein each attribute has a parent, a type, a reported value, and an expected value.

4. The software system according to claim 3, wherein, The frame processor registers rules with the parser engine such that for each attribute type the following rules are registered: a GET synthesizer function that defines creating a payload to obtain the value of the attribute and a SET synthesizer function that defines creating the payload to modify the value of the attribute.

5. The software system according to claim 4, wherein, If the expected value of the attribute is different from the reported value of the attribute, the parser engine invokes the SET synthesizer function associated with the attribute.

6. The software system according to claim 4, wherein, If the reported value of the attribute is a null value, the parser engine invokes the GET synthesizer function associated with the attribute.

7. The software system according to claim 4, wherein, The frame transmitter obtains the network-specific information from the attribute memory to form a data packet.

8. The software system according to claim 5, wherein, The frame transmitter returns a status to the parser engine and updates the attribute memory based on the status.

9. The software system according to claim 8, wherein, If the network device reports that the attribute has been successfully modified, the reported value of the attribute is updated to the expected value.

10. The software system according to claim 8, wherein, If the network device does not report that the attribute has been successfully modified, the reported value of the attribute is updated to a null value.

11. The software system according to claim 3, wherein, The parser engine receives a notification that a node is unavailable and is configured to suspend all operations related to the node and any child attributes related to the node.

12. The software system according to claim 3, wherein, The frame transmitter determines that a plurality of data packets are associated with an attribute and creates a multicast data packet to combine the plurality of data packets.

13. The software system according to claim 3, wherein, The frame receiver receives a data packet from a network device and updates the reported value of the attribute based on data in the data packet.

14. A network controller, comprising: A processing unit; A network interface; And A storage device, wherein the software system according to claim 1 is provided in the storage device.

15. A method of operating a network controller, comprising: Create an attribute memory in the network controller, wherein the attribute memory is configured as a state tree representation to store information about each node in a network and attributes associated with each node, wherein each attribute has a reported value and an expected value; Detect that the reported value of a first attribute does not match the expected value; Find a rule associated with the first attribute, wherein each rule includes a GET synthesizer function and a SET synthesizer function associated with the attribute; Create a payload of a data packet using the SET synthesizer function defined in the rule associated with the first attribute; Obtain network-specific information from the attribute memory; Merge the network-specific information and the payload into the data packet; and Send the data packet to a network device to modify the value of the first attribute.

16. According to the method of claim 15, wherein, If the network device reports that the first attribute has been successfully modified, update the reported value of the first attribute to the expected value.

17. According to the method of claim 15, wherein, If the network device does not report that the first attribute has been successfully modified, update the reported value of the first attribute to a null value.

18. A method of operating a network controller, comprising: Create an attribute memory in the network controller, where the attribute memory is configured in a state tree representation to store information about each node in the network and attributes associated with each node, and where each attribute has a reported value and an expected value; Detect that the reported value of the first attribute is a null value; Locate the rule associated with the first attribute, where each rule includes a GET synthesizer function and a SET synthesizer function associated with the attribute; Create a payload of a data packet using the GET synthesizer function defined in the rule associated with the first attribute; Obtain network-specific information from the attribute memory; Merge the network-specific information and the payload into the data packet; and Send the data packet to a network device to obtain the value of the first attribute.

19. According to the method of claim 18, further comprising: Receive a data packet from the network device, where the data packet contains the value of the first attribute; and Update the reported value of the first attribute to the value contained in the data packet.

Images