Loading...
 
Skip to main content
1
Page actions
Refresh

Internet of Things (IoT)


"The Internet of Things (or IoT for short) refers to uniquely identifiable objects and their virtual representations in an Internet-like structure."

If data from these 'things' can make its way to Tiki, to be stored, analyzed, reported, and used to provide mass monitoring and improvement of plant and equipment processes etc., then Tiki becomes a powerful IoT data repository and overall IoT system management tool.

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:

Image

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

  • Local satellite devices: that are typically low-cost single board computers (SBCs), simpler microcontroller modules, or dedicated sensor devices e.g., with built-in RF comms – 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 which is usually a wireless method and could be 433MHz RF including LoRa RF, WiFi, or just 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 (SPI, I2C, 1-wire, etc.) or an ethernet connection could be used.
  • Local 'integrating' hub devices: 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, that via the internet, provides access to a central Tiki instance. This communication is enabled with ‘programming’ on the local integration hub device to control secure access, with the use of an access ‘token’, to the Tiki API that allows various simplified and fast data upload/download options.
  • Centralized Tiki: supporting business-process operational methods, often using specialized plugins. A Tiki deployment allows access in a secure manner by multiple distributed administrators and other users, with a hierarchy of access permissions. This can then support an extensive and complex IoT system providing 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:

  • 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.


Some projects already identified:


Tiki already has an extensive API (which has been further extended in Tiki27) and can support complex data analysis and reporting (using LIST etc. - although graphic presentation probably needs some more attention !!! ).

The development of local satellite devices (sensors etc.), their local communication, and hub device software is obviously outside the scope of the Tiki development community and is already supported by hundreds of different sensor developers and a more limited number of hub device developers.

So the key 'gap' to be addressed for the left-hand side of the schematic above has been the Remote communication layer from a local integration hub to a central Tiki where the local integration hub is typically a small single board computer (SBC) like a Raspberry Pi, an NVIDIA Jetson Nano or Orin as illustrated in the images below.

Image Image Image Image


Let's try and find a library?

Following an initial meeting (2023/08/22) it seems to me that we should try and find a library that will do the communications with all the different systems out there in a consistent way for us (would be nice, right?) - so let's start a list of ideas and references here:



Let's provide some example hub device Remote communication code ??

Also following the initial meeting (2023/08/22) instead of expecting there to be a 'ready to use' library out there somewhere, could we provide example code that uses the Tiki API and provides the developers of existing hub device software a documented and relatively simple path for them to provide Tiki integration in their software? It is important to note that this example code would not be considered part of the overall Tiki maintained system but is simply provided on an indicative/example basis.

Choice of language and method for the development of Tiki API communication functions has been considered critical and the approach discussed here is to use ‘C’ with cURL as the primary candidates since:

  • standard ‘C’ can be readily integrated with Python and is also natively supported on a wide range of SBCs and microcontroller platforms; plus
  • cURL and the associated libcurl library provide a comprehensive range of networking functionality.


A good working set of example code has now been developed (available for download from here).

More details on IoT are provided in the following pages of this Structure:


Related links
alias
History Source Comments
Show PHP error messages