Tiki management, analysis & reporting

The schematic above illustrates a generic IoT system with Tiki at its centre, where the right-hand side segments the interests/focus of different types of Tiki user into the following three sets of activity so that each of these specific needs can be separately addressed:

• Business operation management;
• Local device management; and
• Tiki communication management.

Business operation management

The users in this focus area 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 analysed and reported by Tiki, as illustrated in the schematic on the right.

Some example analysis and reporting processes: for "Business operation management" that can be supported by Tiki are:

• Test each measured/sensor item from each uploaded data set from a specific local IoT device for an 'out of bounds' value. If an alarm condition is detected the process will then send an email notification to designated recipients. This type of process can be configured for any sort of complex 'if else what then' alarm logic and either run as an occasional 'manual' process from a Tiki web page, or more usefully it would be automatically run a short interval after each new upload is received by the central Tiki system. Technically this process would typically use the LIST Tiki plugin with a custom server-side .tpl template and could be run as a 'cron' using the Tiki Scheduler.
• As an ad hoc manual process, using a Tiki web page for a particular local IoT hub device, where all the uploaded data over a set period of time can be selected and a table of results displayed for a designated number of measured/sensor data items and a simple bar chart produced for a selected parameter. Technically this process would typically use the CUSTOMSEARCH Tiki plugin with a custom server-side .tpl template. With the Tiki PDF generation option enabled, the resultant display page could also be produced as a downloadable PDF document that could then be more widely distributed by conventional email methods.

Local device management

The users in this focus area are responsible for the performance and smooth running of 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, as illustrated in the schematic on the right.

Some example control, analysis and reporting processes: for "Local device management" that can be supported by Tiki are:

• An ad hoc manual process can use a Tiki web page that reports details from system log/device health .TXT files uploaded to a Tiki File gallery. The process could select an upload time period and a specific local IoT device to produce a report on the file details that could include not only the file name, size, description, etc., but could also display the contents of the file in its entirety or a selected start/end line range. Technically this process would typically use the CUSTOMSEARCH Tiki plugin with a custom server-side .tpl template that further invokes a LIST plus a specialised Tiki plugin to list the file contents. With the Tiki PDF generation option enabled, this resultant display page could also be produced as a downloadable PDF document that could then be more widely distributed by conventional email methods.
• As a variant on the process above if the .TXT system log/health file is uploaded as an item to a Tiki Tracker, that also captures further information, a similar ad hoc manual process could produce a similar type of report.
• In a manner similar to that used for 'alarm testing' of the measured sensor data to support "Business operation management", detailed local IoT device system parameters, e.g. CPU temperature, local storage % used, current RAM usage, etc., could be tested for 'out of bounds' conditions that might indicate a local device issue. As above, if a worrying condition is detected, using any sort of complex 'if else what then' analysis, the process could then send an email notification to designated recipients. As before this type of process could be run as an occasional 'manual' process from a Tiki web page, or run automatically at set times that match the upload of new data.
• When local IoT devices use XML-like control files to define their use of a range of operational parameters, these files could be managed centrally and very conveniently updated through a Tiki web page. Then when a more secure operational mode is used for local device management, i.e., the local device cannot be directly accessed from the internet, but it can only 'talk out' - each local device could then periodically check the 'timestamp' of the last modification of the file and download it for use if it is 'newer' than the current version held locally.
• Another more sophisticated operation control process, that could be used in that more secure operational mode where the local devices can only 'talk out', is to use a central Tiki Tracker to hold what might be called 'opcodes'. These could easily be updated/changed to specific values in a centralised/secure manner using Tiki selective access control, and each local IoT device could then periodically download 'their opcode' and check its value. In this manner specific opcodes could be used to 'instruct' a local device to carry out a particular operation - which could be a simple reboot, or to upload a particular file, or even to run a process to update parts of the local code.

Tiki communication management

The users in this focus area 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, as illustrated in the schematic on the right.

Some example analysis and reporting processes: for "Tiki communication management" that could be supported by Tiki are:

• A set of processes for each of the local IoT devices and a specific data upload, that could each be scheduled to run automatically, and could be used to access the details of just the last received upload and to check its upload timestamp. The expected time cycle for the designated upload will be known, so the last upload timestamp could be compared with the expected timing and hence a missed upload could be detected and a notification email sent if appropriate. Technically these processes would typically use the LIST Tiki plugin with custom server-side .tpl templates and could be run as a 'cron' using the Tiki Scheduler.

General Tiki administration

The users in this focus area are typically the main Tiki admin(s) who would be responsible for the more complex configuration of IoT specific Tiki functions and the smooth running of the overall central Tiki IoT system.

Some example usage by Tiki admins: for IoT specific "General Tiki administration" are.

• detailed configuration of the various custom server-side .tpl templates
• testing and finalising of the various process web pages with their use of the specialised LIST or CUSTOMSEARCH plugins to match the analysis and reporting needs of the individual operational user groups