The Internet of Things (IoT)

 

The internet of Things, or more simply "IoT", is a technology that was once much 'hyped' but can now be considered a mainstream activity. At its most general it is a network of devices connected through a network (usually the public Internet) that allows data to be collected from multiple locations for simple monitoring purposes or for more detailed control and analysis. 

This combination of sensors, processing capability, software and other technologies can be used for a very wide range of purposes from the monitoring of complex engineering systems through to the collection of usage data from consumer products.

The purpose of this evolving set of web pages is to describe how the open source Tiki software, an all-in-one Wiki+CMS+Groupware system, can be used as a central data repository and management capability for an IoT deployment.

The schematic below illustrates a generic IoT system with Tiki at its centre, where the left-hand side shows the different types of field deployed devices and their communications, and the right-hand side segments the different types of Tiki user so their requirements can be focused upon separately:

The individual field deployed devices and their communication layers, briefly, are:

• Local satellite devices: i.e., local data collection devices that are usually multiple low-cost single board computers (SBCs), or simpler microcontroller modules, or dedicated sensor devices e.g., with built-in RF communications – all typically, with low power consumption and/or ‘deep sleep’ modes to facilitate long operational duration when just battery powered.
• Local communication: i.e., communication from a satellite device to a local hub that is usually a wireless method that could be 433MHz RF including LoRa RF, ethernet over WiFi, or Bluetooth for close proximity. Directly wired connections from a satellite to a hub are of course possible and could use any of the usual ‘bus’ protocols (I²C, SPI , etc.) or an ethernet connection.
• Local ‘integrating’ hub device(s): there would usually be just one hub device at a location, but multiple hub devices may be needed, and they are all usually low-cost single board computers (SBCs), but in some exceptional circumstances they could be simpler microcontroller modules. These hub devices gather data from defined sets of multiple satellite devices - although sensors could also be directly attached to the hub device which directly manages the sensor and the data collection – to distinguish this from a satellite being directly connected which simply passes a ‘result’ to the hub.
• Remote communication: i.e., from a local integration hub via the internet or a private network, providing access to a central Tiki instance. This communication is enabled with ‘programming’ on the local integration hub device to control secure access to Tiki with the use of an access ‘token’ to the Tiki API that allows various simplified but secure and fast data upload/download options.
• Centralized Tiki: Tiki supports many business-process operational methods, often using specialized plugins. A central Tiki system, accessible in a secure manner by multiple distributed administrators and other users, with a hierarchy of access permissions, can support IoT system and remote device management, as well as collected data storage, management reporting, and analysis that can initiate Tiki user notifications when specific events are ‘seen’.

The different Tiki user segments and their needs are:

• Business operation management: these users are responsible for what is being controlled and monitored at each remote site and are therefore interested in the detailed measurement data that is being collected and then analyzed and reported by Tiki.
• Local device management: these users are responsible for the field deployed equipment and software that is collecting and aggregating the field data i.e. sensors and integration hubs, and are therefore interested in the Tiki tools and methods that can support this.
• Tiki communication management: these users are responsible for the software/interface between hub devices and the Tiki API and are therefore interested in API functionality, the associated local device code for connecting to and exchanging data through the API, and the performance/success (or otherwise!) of the data exchanges with Tiki.
• General Tiki administration: typical Tiki admin(s) responsible for the more complex configuration of Tiki functions and the smooth running of the overall central Tiki system.

The following pages provide further detail about a 'Tiki IoT' deployment:

 

All the currently available maker project information: