IoT usage scenarios

Set out below are a number of usage scenarios that are envisaged for an overall IoT system deployment that uses Tiki as a central management tool and data repository.

These are purely descriptions about the aims of each usage scenario and the general processes involved, but they represent what could be considered a 'minimum viable product' (MVP) capability that Tiki needs to support for IoT usage.

Later Wiki pages in this Structure provide more technical details about the API functionality to be used in each scenario, the detailed software needed for an 'integrating' hub device to connect to the Tiki API and the return responses that are relevant to these scenarios, the testing carried out, and any bugs/issues that have arisen.

(1) Collecting sensor data and storing it in a Tiki tracker

This is the first and possibly the most useful IoT usage scenario that will arise for the following reasons:

• Data, once collected from a local sensor, and as appropriate forwarded to a local 'integrating' hub device, will be managed and controlled by that local hub device. The data will typically be stored locally, however being able to immediately 'post' the data to a remote repository provides additional data security, i.e. by using Tiki as an immediate and up-to-date off-site storage capability.
• Also, using a Tiki tracker allows data to be stored in a structured manner (that can be easily 'evolved'!) facilitating routine analysis and review. Graphical presentation of the data will however be an important analysis technique that is required.
• The data can also be continually reviewed and analysed by different/remote groups of users with access control to the data by these users controlled down to an individual tracker field level.
• Finally, sensor data can come in a variety of formats (text, date/time, numeric, logical, a file, etc.) - all of which can be accommodated in a specific tracker field type.

So typically an 'integrating' hub device, like a Raspberry PI or similar single board computer (SBC), will manage a network of local sensors collecting data on a periodic basis or triggered by a specific event such as a sensor detecting movement or a temperature threshold being exceeded. The hub device then needs to upload each set of new data, as quickly as possible to Tiki.

Given this most common usage scenario a number of particular requirements arise for the data transfer and how it is managed by Tiki;

• As new sets of data can arrive very frequently, the Tiki upload process needs to be very fast and the Tiki date/time resolution/display needs to be at the level of seconds
• For good general management and data validation/tracking purpose, the sensor data storage tracker on the Tiki system should be configured to allow the following to be recorded:
  • the time/date of the data set upload;
  • the Tiki userId for which the API access token is authorised;
  • the details of the specific 'integrating' hub device doing the data set upload;
  • the details/versions of all the software doing the upload from the 'integrating' hub device; and
  • any relevant operational details/updates/status of the local hardware and attached sensors used in the IoT network, e.g. the % full of any local storage media.

 

(2) Accumulating other types of information and storing it in / retrieving it from a Tiki File gallery

For several more detailed usage situations, the ability to archive or just make available remotely, a simple file rather than an explicit structured data set, may make the use of a Tiki File gallery preferable to the use of Tiki trackers. It should be noted however that since a Tiki tracker also has a 'Files' field a tracker could still be used to add structured data to an individual file upload!

Some more detailed situation examples are as follows:

• Images captured locally either on a periodic basis, e.g., perhaps for time lapse video creation purposes, or on an event basis, e.g., triggered by movement detection in a security/surveillance system context.
• Routine upload of various types of 'log' file that are tracking the performance and/or 'health' of local sensors or other local hardware; this could either be needed on a periodic basis or on an event basis, e.g., the upload of a system 'log' file, along with the generation of an email notification, if a local storage medium (USB stick etc.) reaches a designated capacity used level.

 

(3) Using an XML formatted control file for 'integrating' hub device software management

To make the day-to-day control of a local 'integrating' hub device as simple as possible, a number of key software system parameters may be defined in a control file where the parameter values may need to be varied depending on the deployment situation or periodic environment changes.

This control file could of course be updated by direct local access to the local hub device, but this is not always possible e.g., if the site is remote. Also, in many situations to avoid security issues, direct access to a local hub device either from a local intranet or direct from the internet may need to be avoided i.e., the hub device should only be allowed to ‘talk out’ to the internet.

The hub device could therefore be programmed to retrieve a control file from Tiki on a periodic basis but only if that central Tiki file is ‘newer’ than the locally held version of the file.

Tiki already has some features that are complementary to the core file storage feature (File galleries) that support this scenario, namely:

• the FILES Plugin can display in a wiki page the latest modification timestamp for a file in a File gallery - so the wiki page can be downloaded by the hub device and the date 'parsed' and compared to the timestamp of the local version ; 
  • an example date could look like this: 

    Last modified
    29 Dec 23 09:55 GMT-0000

     
• the XMLUPDATE Plugin allows an XML-structured file in a File gallery to be updated using a simple form process presented in a Tiki wiki page.

 

(4) Remotely initiating the execution of a designated operation on a designated 'integrating' hub device

In the context, as described above, where direct access to a local hub device either from a local intranet or direct from the internet may need to be avoided - a safe and secure method of executing system level operations on the hub device, either on an occasional, or perhaps on an exceptional, basis is needed.

This can be accomplished by a specialised routine running periodically on the hub device that checks the value of a designated Tiki tracker item, that is only accessible by designated 'device users' using the Tiki API access token security. The tracker item would define an "operation instruction": i.e. where the item value is some specific text, or some private code, or is just a reference number.

In this way a remote user with the appropriate permission to access (and edit) the Tiki tracker item can 'use' any one of a potential and confidential 'list' of possible 'operation instructions'. Each 'operation instruction', once correctly identified by the remote IoT hub device, could initiate just a one-line system command or a more complex series of commands - some example commands might be:

• do a simple system reboot;
• upload to Tiki the latest version of a particular system log;
• backup/archive a local storage medium, e.g. a USB stick, to an off-site storage facility; or
• a particularly complex operation would be to update one of the local hub software programs to a new version, which would typically need a series of steps that would be specific to that software program, such as:
  • copying the current software code to a temporary location, so that a roll-back process could be done if necessary
  • downloading the new software, to another temporary location
  • during a designated time window, overwrite the existing software with the new version or if using a new file name place the new software in the 'production' software folder and as appropriate update any crontab used to run the program
  • on completion of all the key steps, do a remote edit of the Tiki tracker item to change the 'operation instruction' to text that 'says' the instruction has been completed, so that the next periodic cycle does not repeat the command
  • as necessary, reboot the system

For all such detailed situations the code development and all its complexity is primarily centred upon the 'integrating' hub device where the Tiki API related hub code just has to be able to:

1. 'detect' a recognised instruction from the interpretation of a tracker item and to
2. update the tracker item to 'report' operation completion or perhaps some other status

 

All the current pages in this Structure: