Following up on this, here is a proposal for the Agent/Thing asset model.
Assets form a tree structure, several assets can be grouped together under the same parent. The root of an asset tree is always a Tenant asset.
An asset can be of well-known type (which means we have specific functionality for that asset) or Custom user-defined type (which means it's a domain asset handled in a generic fashion). The Agent and Thing are well-known asset types:
Besides type, every asset has a few static properties such as asset name and geolocation coordinates. Furthermore, each asset can have a set of dynamic attributes. How the dynamic attributes are used depends on the asset type. For example, a Building asset might have a street and zip code, a Floor asset might have a floor plan, etc.
The value of a dynamic asset attribute must be one of the defined types:
Finally, each asset attribute can have additional metadata items. Examples are a pretty label and description of the attribute, or how a string attribute value should be formatted when shown to the user, or value constraints such as integer ranges and regex patterns.
Attribute meta items are a simple name/value list where duplicate names are allowed for multi-valued items. There are no restrictions on the value of a meta item, any JSON type is supported, and how the value is used depends on the meta item name. Again, we support some well-known meta items by URN but users can add arbitrary custom meta information to any attribute:
Given this asset model, how can we represent Agents and their Things? This is an example definition of an Agent and a Thing:
This Agent connects a Hue Bridge and a ZWave USB stick to the system. We may have many Agents and each Agent can have many of these protocol bindings. Protocol specific configuration, such as the Hue Bridge host and username or the ZWave USB port can be set at the Agent level. Other (global) Agent configuration including rulesets would also be configured as Agent attributes. Whether deployed in-process or on a remote gateway, each Agent instance has its own data context and therefore rule facts.
The Thing might be a child asset of an Agent, for example, if it's a device that is automatically discovered and added to the asset tree by the Agent. A user can however also create a Thing manually anywhere in the asset tree and configure it as desired.
The example Thing asset is a light fixture. The current, known state of the light is represented with asset attributes: Is it turned on, its dim level, color, and power consumption. To implement this, add an agent link meta item to the Thing's attribute. This is a marker for "bind this attribute to a device or service" using the identifier of the Agent and a protocol binding attribute name.
The linked protocol handles south-bound read and write of the attribute value: If the user writes a new value into the Thing asset attribute, the protocol translates this value change into a device (or service) action. If the actual state of the device (or service) changes, the linked protocol writes the new state into the attribute value and the user is notified of the change.
Protocol-specific meta items required for the link can be added to Thing attributes, such as the Hue light identifier or the ZWave node and command.
TBC...