Things

Things represent the entities in your world. They store information about real world objects like assets, rooms or buildings, as well as information about concepts like Tasks or processes.

Things are defined through JSON formatting, in a standard schema called Web of Things "Thing Descriptions". This standard schema allows you to be very prescriptive about what kind of information you expect to populate these Things, validate that the data matches what you expect, and even create user experiences that adjust based on the schema of the data.

Based on the Web of Things (WoT) Things can be defined based on properties, actions, and events.


Figure 1.
Properties
Describe the Thing's attributes (e.g., sensor values, configuration parameters, status, results of an analysis)
Actions
Determine how you can interact with your Thing (e.g., change a property, turn on/off)
Events
Monitor the changes that can modify a Thing’s property (e.g., fire alarm, door open, data streams)
Similar to categories, include steps about how to create a thing (upload schema should be inside ski to schema option) and how to add properties, actions and event by clicking the + symbol

These Things have two faces: the Thing itself and the schema which defines it.

The Thing represents the state of the real-world object. For example, a Thing might look something like this:
{
    "uid": "01EYVA8TJR9GN04ETC864HM3PR",
    "title": "Office 211b Stereo",
    "space": "my-space",
    "category": "my-category",
    "properties": {
        "status" : "operational",
        "volume" : 35
    }
}
Conversely, a schema defines everything that makes up those real-world objects and all the interfaces for interacting with those objects. For example, the schema for the above Thing might look something like:
{
	"actions": {
		"toggleOn": {
			"input": {
				"type": "boolean"
			}
		},
		"volumeChange": {
			"description": "Change the volume of the Sound Stereo System",
			"input": {
				"properties": {
					"Volumelevelduration": {
						"minimum": 0,
						"type": "integer",
						"unit": "seconds"
					},
					"level": {
						"maximum": 100,
						"minimum": 0,
						"type": "integer"
					}
				},
				"type": "object"
			},
			"title": "Change the Volume"
		}
	},
	"base": "https://api.swx.altairone.com",
	"category": "my-category",
	"created": "2021-10-11T14:05:56+00:00",
	"description": "",
	"events": {
		"overheating": {
			"data": {
				"description": "The roof. The roof.",
				"title": "Stereo Overheating",
				"type": "string"
			}
		}
	},
	"href": "/spaces/my-space/categories/my-category/things/01FHQTS842GDVVVSSGER1HSTE1",
	"id": "https://api.swx.altairone.com/spaces/my-space/categories/my-category/things/01FHQTS842GDVVVSSGER1HSTE1",
	"model": {
		"name": "",
		"version": 0
	},
	"modified": "2021-10-11T14:09:05+00:00",
	"properties": {
		"status": {
			"type": "string"
		},
		"volume": {
			"description": "The volume of the Sound Stereo System",
			"maximum": 100,
			"minimum": 0,
			"title": "Volume",
			"type": "integer"
		}
	},
	"space": "my-space",
	"title": "Office 211b Stereo",
	"uid": "01FHQTS842GDVVVSSGER1HSTE1"
}

You can see the schema is much more descriptive and even defines Things which are not immediately apparent in the Thing, like the events that might come from the real-world object or the actions one can take on that real-world object.

Therefore, both are needed. In your applications you want to know the state of a real-world object certainly, but you also want to know how you should describe those objects in the user experience. AnythingDB always provides both and gives you easy interfaces for getting only the data you need.

Also in this Section