Topic updated on September 24, 2021
When a Thing connects to the IoT Portal it establishes a session with a unique session ID. In case of bound things, a proxy acts as an intermediate Thing which acts as a virtual representation of all the Things connected through it. Bound things are connected to the IoT Portal through an intermediate thing (proxy) that has established a direct connection to the IoT Portal. Bound things share the same session (and hence session ID) of the intermediate thing they are bound to.
When the proxy establishes a connection with the IoT Portal all things that are bound to the proxy thing will receive data from the IoT Portal through the proxy's connection. The Proxy initiates the session binding by sending a thing.bind to bind the things to the current session. For example, in the diagram below when a mail is sent to Thing A (using either method.exec or mailbox.send), a session gets established with a valid session ID. Using this session the IoT Portal sends the mail to Thing Y (Proxy) which is a virtual representation of Thing A, Thing B, and Thing C. Thing Y then delivers the mail to Thing A using an established communication path.
A proxy thing communicates with the IoT Portal instead of the bound things since the bound things do not use the same protocol for communication. Hence the proxy is used as a translator and sends the thing.bind command to bind the things.
The Thing binding concept allows you to create a ordered logical hierarchy of Things within a given organization. Effectively, there will be a parent Thing to which multiple child Things are bound using the thing.bind command within a current session. The diagram below illustrates this concept of logical hierarchy.
The diagram shows the ability to create child Things using a different Thing definitions and Thing Keys.
The properties, attributes and alarms associated with a downstream sensor or actuator device can be segmented and separated from the properties, attributes and alarms associated with the parent device. This is a common model where a number of sensors and actuators are connected to the IoT Portal using a single gateway or aggregation device. Rather than the parent device bearing the bulk and complexity of all of the combined properties, attributes and alarms of the connected devices, it need only represent the details associated with an instance of itself. Similarly, the child devices need only represent the details associated with the instance of each sensor or actuator.
| During runtime, the IoT Portalshows that a child Thing is connected to the IoT Portal through the parent” thing in the following manner:
When child Things are bound to a parent Thing, the parent Thing displays Bound Things tab and it lists all the Things that are bounded to it. Things connected to the IoT Portal through the parent. The figure below shows the cars connected through the Xirgo Proxy.