Overview
Zetta is an API-first platform for the Internet of Things. This is a general overview of core concepts Zetta developers need to know.
The Zetta server is the highest level of abstraction in Zetta. The Zetta server contains Drivers, Scouts, Apps, and Server Extensions. A Zetta server will typically run on a hardware hub such as a BeagleBone Black, Intel Edison, or Raspberry Pi. The server itself coordinates interactions between all of the contained components to communicate with devices, and generate HTTP APIs that an API consumer can interact with.
Zetta scouts serve as a discovery mechanism for devices that may be on the network, or require system resources to speak a specific protocol. Scouts will search for devices on a particular protocol, and report back to Zetta when they've been found. Scouts can also use identifying information about devices (e.g. a device's MAC address) to identify whether or not Zetta has interacted with the device before, and ensure any relevant data or security credentials are maintained when interacting with that device an additional time.
Zetta drivers are state machine representations of devices. Drivers are primarily responsible for modeling devices, and interacting with the device on the physical level. These device models are then used to generate HTTP and JavaScript APIs for use in Zetta.
Zetta follows a pluggable model for extending functionality. Most of these will be server extensions. Server extensions will deal with API management, defining addtional APIs, or even adding security to your API.
The registry is a persistence layer for Zetta. It's a small database that lives in the server context, and holds information about devices connected to the server itself.
Zetta servers allow for establishing a secure tunneled link between two servers. This connection takes care of network configurations, and firewalls that make cloud connected IoT solutions difficult to maintain.
Apps are interactions between devices written in JavaScript. Zetta allows developers to create local interactions based on sensor streams, or changes in devices. These apps will function regardless of inter-Zetta connectivity, and allow for quick response times to certain events in the system.
This section describes a typical Zetta deployment.
- One Zetta server runs on a hardware hub. This hub is typically something like a BeagleBone Black, Intel Edison, or Raspberry Pi.
- The Zetta hub connects to devices. Zetta mediates from HTTP to the particular protocols used in a deployment.
- Another Zetta server runs in the Cloud. This server uses the exact same Node.js packages as Zetta running on the hub.
- The Zetta server on the hardware hub connets to the server in the Cloud.
- Zetta then exposes an API at the Cloud endpoint for developers to consume.
APIs exist on each instance of a Zetta server. Zetta uses hypermedia to expose a walkable set of links for navigating the API from a response, and affordances for streaming and interacting with devices. Zetta APIs conform to the Siren specification. Zetta APIs allow:
- Querying for devices on a particular server
- Setting up links between servers
- Interacting with devices
- Streaming sensor data with websockets
- Registering hubless devices