Thing Concept in IoT Messaging Framework
1. Definition
A Thing represents any physical device or logical service that connects to the IoT network and exchanges messages. Things are the primary entities that generate and consume events within the system.
2. Thing Structure
{
"id": "018e7507-c547-7f43-9485-71c71b3b0446",
"code": "sens-temp-001",
"type": "sensor",
"subtype": "temperature",
"edge_id": "018e7507-c547-7f43-9485-71c71b3b0447",
"location_id": "018e7507-c547-7f43-9485-71c71b3b0449",
"status": "active",
"capabilities": ["measure", "report", "configure"],
"properties": {
"model": "TempSensor-2000",
"manufacturer": "SensorTech",
"protocol": "mqtt",
"measure_unit": "celsius"
},
"metadata": {
"firmware_version": "1.2.3",
"hardware_version": "A",
"description": "Temperature sensor for office room 101",
"installation_date": "2024-12-01"
}
}
3. Thing Code Pattern
Thing codes follow a standardized pattern:
{type}-{subtype}-{number}
Components: - type: 2-4 character code representing the thing type - subtype: identifier for the specific function or purpose - number: 3-4 digit sequential identifier
Examples:
- sens-temp-001: Temperature sensor #001
- ctrl-hvac-002: HVAC controller #002
- gtwy-edge-001: Edge gateway #001
- srv-auth-001: Authentication service #001
4. Thing Categories and Types
Things are organized into categories, each containing specific types:
Physical Devices
| Type Code | Description | Examples of Subtypes |
|---|---|---|
| sens | Sensor | temp, humd, press, motn |
| ctrl | Controller | hvac, lght, accs |
| gtwy | Gateway | edge, prot, mesh |
| acttr | Actuator | motr, valv, rlsy |
| disp | Display | scrn, indc, sign |
| term | Terminal | inpt, kiosk, tuch |
Logical Services
| Type Code | Description | Examples of Subtypes |
|---|---|---|
| srv | Service | auth, dbas, apis |
| proc | Process | data, anlz, trnf |
| strg | Storage | file, tsdb, cach |
| intg | Integration | thrd, hook, apic |
| anlyt | Analytics | dtan, mlmd, dagg |
| orch | Orchestrator | flow, sched, task |
5. Thing Relationships
Things exist within a well-defined hierarchical structure:
- Things belong to an Edge (defined by edge_id)
- Things exist at a specific Location (defined by location_id)
- Things can communicate with other Things
Edge (prd-eu-001)
├── Location (floor-1)
│ ├── Thing (sens-temp-001)
│ └── Thing (ctrl-hvac-001)
└── Location (floor-2)
└── Thing (sens-motn-001)
6. Thing in Message Context
In messages, thing information appears in the context:
"context": {
"thing_code": "sens-temp-001",
"thing_type": "sensor",
"edge": {
"code": "bld-eu-001",
"type": "office-building"
},
"location": {
"code": "room-101",
"path": "floor-1/north-wing/room-101",
"type": "office"
}
}
7. Thing Capabilities
Things can have multiple capabilities that define what they can do:
| Capability | Description |
|---|---|
| measure | Collect sensor readings |
| report | Send telemetry data |
| actuate | Perform physical actions |
| control | Manage other devices |
| configure | Accept configuration changes |
| process | Process data |
| store | Store data |
| connect | Provide connectivity |
| authenticate | Verify credentials |
| authorize | Control access |
8. Topic Structure with Things
Thing identifiers are incorporated into the topic structure:
{org_id}.{edge_code}.{thing_type}.{thing_code}.{message_type}
Example:
acme.prd-eu-001.sensor.sens-temp-001.telemetry
9. Extension Points
The thing concept can be extended through:
- Custom Thing Types: Register organization-specific types
- Custom Subtypes: Define specialized subtypes
- Thing Properties: Add domain-specific properties
- Custom Capabilities: Define specialized capabilities
- Domain-Specific Metadata: Add industry-specific attributes
10. Thing Registry Example
{
"things": [
{
"id": "018e7507-c547-7f43-9485-71c71b3b0446",
"code": "sens-temp-001",
"type": "sensor",
"subtype": "temperature",
"edge_id": "018e7507-c547-7f43-9485-71c71b3b0447",
"location_id": "018e7507-c547-7f43-9485-71c71b3b0449",
"status": "active",
"capabilities": ["measure", "report", "configure"]
},
{
"id": "018e7507-c547-7f43-9485-71c71b3b0452",
"code": "ctrl-hvac-001",
"type": "controller",
"subtype": "hvac",
"edge_id": "018e7507-c547-7f43-9485-71c71b3b0447",
"location_id": "018e7507-c547-7f43-9485-71c71b3b0448",
"status": "active",
"capabilities": ["control", "report", "configure"]
}
]
}
11. Best Practices
- Consistent Naming: Follow the code pattern consistently
- Meaningful Types and Subtypes: Choose appropriate types and subtypes based on function
- Location Association: Always associate things with a specific location when possible
- Capability Definition: Define capabilities based on actual functionality
- Complete Context: Include full thing context in messages
- Registry Maintenance: Keep the thing registry updated
- Status Tracking: Track and update thing status
- Metadata Updates: Update firmware and other metadata when changes occur
- Subtype Standardization: Maintain a registry of standard subtypes for consistency