Concepts & Terminology

Beebotte uses the following terminology and concepts:

Channel - Resource

Channel

A Channel is a logical entity that can be (1) a physical object as a domotic sensor connected to an Arduino or a RaspBerry Pi, or, (2) a virtual object as a Blog, Twitter account, web service, etc.

A channel belongs to one and a unique account, it is expected to connect to Beebotte to write data. It can also connect to read data from the platform. A channel can be created by the user; it has a unique name that will be used to identify it, a description, an array of resources (see below) and an access level indicating if it is public or private.

The channel concept in Beebotte is rather abstract. It is required to be connected to the Internet (through Ethernet, WiFi, 3G, ZigBee, etc.) and expected to read and write to the Beebotte Cloud platform.

Resource

Resources are the most elementary part of Beebotte. A resource belongs to a channel; it provides the data to record in the platform. For example, a temperature sensor of a weather station (channel) will emit a temperature event (resource) to record in the platform. A resource can be an attribute like the temperature, the humidity level, etc. It can also be an event like to indicate low battery level. It can also be a function like a face identification service where the user sends an image and expects the number of human faces in return.

The simple hierarchy of channels offering one or multiple resources provides a way to describe plenty of things of everyday's use.

The state of the art does not necessarly use the same terminology as the one we use in Beebotte. You might find in the SOTA different terms to address the same concept. To eliminate the confusion we provide in the following figure a mapping between Beebotte's terminology and the common ones employed elsewhere.


Publish Subscribe architecture

Publish subscribe functionality in Beebotte is the key enabler for real-time applications. PubSub involves three parties:

  • The backend server application uses the REST API to write and publish messages to Beebotte
  • The Beebotte cloud platform routes messages to online subscribers (clients of the server application). It also manages presence notifications of these clients
  • The application's clients (Web browsers) use Websockets to subscribe to defined resources. They can be authenticated by the server application to publish messages as well.

Messages in Beebotte

Persistent Messages

A persistent message is a data container associated to an existing resource and sent to Beebotte through the API. Data of a persistent message will be stored into the resources database and will be available for future read request. It can also trigger some statistical analysis depending on the resource type (exemple: a temperature resource will trigger statistical functions to calculate average, minimum and maximum over one or different periods of time). Data of a persistent message will also be routed to users subscribed to that resource.

Transient Messages

A transient message is a data container that is not necessarly associated to an existing resource. Data of a transient message will only be routed to subscribed users before being lost. Except a broad usage statistics, Beebotte will store no data relative to transient messages.