General architecture
The main goal of creating a Patchwok Tookit was to easily connect various devices into a network and expose their capabilities via a common API (RESTful, SOAP, CoAP, MQTT, etc) that would be easy consume by applications and services. Creating a proper infrastructure of interconnected things is the first step towards creating a ubiquitous environment for your needs: smart home, smart office, or any other hacking project.
We avoid using the term Internet of Things (IoT) in respect to Patchwork Toolkit on purpose, as we do not solve the global problem of interconnecting isolated distributed environments. Although you can use Patchwork Toolkit on the WAN by running its components on the publicly available machines.
In the Figure below you can see an overview of a Patchwork-based Network of Things.
There are 4 major components required to create a network of things using Patchwork Toolkit:
- Device Gateway (DGW)
- Device Catalog (DC)
- Service Catalog (SC)
- MQTT Broker (MQTT-B)
The DGW represents the so-called Device Integration Layer in IoT terminology. It is used as a gateway between the low-level hardware access protocol and a TCP/IP network. For now, DGW can expose sensors and actuators via two interfaces: RESTful-like API and MQTT publications to a given MQTT-B (will be described below). There are 4 DGWs in the Figure above. One has a Light Switch (actuator), Light Sensor (sensor) and a PIR Motion Sensor (sensor) connected to it. This is a common setup you can find at the Adafruit website. Another DGW has a Wall Display and Audio Speakers connected, which enables to submit audio or visual content to those devices from the LAN. The other two DGWs have other kinds of sensors attached for the illustration purpose. The DGW can optionally announce itself on the LAN using the DNS-SD (Bonjour) mechanism.
The DC is a directory of devices and their resources in the environment that provides a RESTful-like API for querying and searching for a specific device or resource. In our model, an attached device can expose several resources (please, don't mistake it for RESTful resource). You can imagine a device as a group of sensors/actuators (resources). Each DGW registers itself and its configured devices/resources in the central DC. Applications and services developed on top of the Patchwork Toolkit can use the DC for finding a certain data source or an actuator depending on their logic. The central DC can optionally announce itself in the LAN using the DNS-SD (Bonjour) mechanism.
The MQTT-B is a component offering a Pub/Sub functionality to the components in the environment using MQTT protocol. There are many MQTT broker implementations available that are suitable for different needs, but our recommendation would be Mosquitto - an Open Source MQTT v3.1/v3.1.1 Broker. The MQTT-B component is optionally used by DGWs and can be also used by developed services and applications.
The SC is a directory of services in the environment. The two mains services registered in the SC are DC and MQTT-B. The central DC can optionally announce itself on the LAN using the DNS-SD (Bonjour) mechanism.
Having such an infrastructure in place, a custom service or an application can resolve a required data source or an actuator using the following steps (there are alternative paths as well!):
- Discover a SC via DNS-SD (Bonjour) and use a hardcoded network name or address
- Query SC for endpoint of the central DC
- Query the central DC for an endpoint of DGW that has the device or resource with certain type/name or other meta information attached
- Consume DGW API related to the desired device/resource
This is just a general architectural overview. You can now proceed by reading more about each of the Patchwork Toolkit components in details: