Home

1. What is OpenChirp?
2. What Problem Does OpenChirp Solve?
3. How does OpenChirp Accomplish Its Goals?
4. Quick Links
5. OpenChirp Architecture
6. Get Started
7. Getting Help

What is OpenChirp?

OpenChirp is a management framework on top of LoRaWAN that provides data context, storage, visualization, and access control over the web. LoRaWAN is an emerging Low-Power Wide-Area Networking (LP-WAN) protocol designed to support battery-operated devices that want to send just a few bytes of data but over long distances. Devices typically transmit 1-2km in urban areas and up to 15km in open space. OpenChirp is currently powering a LoRaWAN Network that started at Carnegie Mellon University but has spread to the City of Pittsburgh and beyond.

What Problem Does OpenChirp Solve?

OpenChirp solves a few key problems in how people use LP-WANs:

1. It provides an open and free interface to a hosted LoRaWAN server
2. It translates compressed binary byte-streams into JSON for applications
3. It provides time series storage for transducer data
4. It allows users to share data streams
5. It allows users to securely connect their own gateways to help grow the network
6. It provides a single cohesive representation for multiple field-bus and LPWAN interfaces

How Does OpenChirp Accomplish Its Goals?

OpenChirp accomplishes the above goals by providing an infrastructure that sits above the LoRaWAN server with a set of APIs that allow users to register and describe LoRa gateways, devices and data flows. The system provides services that can be attached to data streams that can perform operations ranging from basic data storage to binary-to-json packing and unpack. A RESTful interface is used to configure meta-information about devices and set access control privileges that define how other users can interact with data streams. OpenChirp currently provides a simple way to link user-owned LoRa gateways into the system making it easy to create a LoRa Hotspot in your area. We are developing services that can integrate other types of field-bus devices to work under a uniform framework. To facilitate community involvement we are developing a set of online tutorials for how to create gateways and clients using commercially available devices.

Quick Links

• REST API Documentation
• Overview Presentation
• Simple Device Tutorial
• Tutorial for adding a LoRa Device
• Tutorial for adding a LoRa Gateway to the network
• PubSub Overview
• Time Series Data

Get Started

Get started by trying the Simple Device Tutorial that you can complete entirely using the web portal.

Getting Help

Post on our Forum: http://community.openchirp.io

OpenChirp Architecture

The OpenChirp Architecture is split into two main components: a control plane and a data plane. The control plane is exposed through a REST interface and is used to create devices, define their properties, and to manage who or what has access to them. The data plane uses MQTT to allow access to real-time data streams using a publish subscriber model. Each device created by the control plane has a corresponding MQTT end-point. The system currently uses OAuth 2 with Google's authorization server. Access Control Lists (ACLs) are uniform across the REST and MQTT frameworks using a common database. All meta-data is stored using MongoDB and time series data is currently using InfluxDB. For LoRa support, we are leveraging the excellent Open Source LoRaServer developed by Broocar.

Devices

Devices are defined as a set of Transducers and Commands. Each devices has an MQTT end-point (openchirp/devices/UID) and a set of key / value pair properties. These properties can be used to keep track of additional information that might be used to describe a device. Transducers are used to represent each sensor or actuator associated with the device and can be found inside each device within the MQTT tree. They are have a few properties such as Name, Unit, Actuation Flag, Value and a server timestamp for when they were last updated. The Unit is a human readable tag that defines that unit for the transducer. Whenever possible, we suggest using a standard SI value. Sometimes units can be described as types like "binary" or "enumeration". The Actuation Flag describes if the transducers is a sensor or actuator, since only actuators can be connected with a Command. A Command is a simple macro used to link a common actuation value with a transducer. For example, "Light On" might be an alias for passing the value 1 to a binary light actuator. In a more complex example, "Light On" could capture an arbitrarily complex JSON message that needs to be published to a device's transducer. Commands are useful within the OpenChirp web portal for performing quick actuations and can also be represented by a public URL link to share with outside applications.

Device Templates capture the Transducers and Commands of commonly used devices. It is possible to create a template from any existing device. This device template can then be used when creating a new device to populate all of the transducers, commands and any attached services. These templates represent the golden standard of how a device should be represented which helps provide users typical unit and transducer names. Users must be in the "Developer" role to create publicly viewable templates.

Services

TBA

Security

TBA