• Trackers for IoT data : use Tiki Trackers to store physical object–related data and event logs.

• Visual interface for event handling : decide what happens when new data is created in a tracker through an interactive drawing canvas.

Click to expand

• Realtime dashboard : monitor your physical device in real time with dashboards that display changes as they occur. The dashboard is designed by you, drag in widget as you wish and build the dashboard in the way you want it to look

Click to expand

If you are familiar with Arduino you can quickly follow the steps explained in this snippet to build a remote temperature monitor tool : https://gitlab.com/-/snippets/3759981

First of all you need to install latest version of Tiki or upgrade to Tiki 28 or later.

Then you need to enable the feature in the admin panel. From the admin panel you can search "feature_internet_of_things" in the preferences or visit "/tiki-admin.php?page=features#contentadmin_features-programmer" then activate the feature. If prompted to activated the Realtime please go ahead, it is required for the IoT feature to work.

Click to expand

The last thing is to enable the API access feature, please follow this link on how to do it https://doc.tiki.org/API

If all above is done, you can start by opening /tiki-iot_dashboard.php. Note that you need to have 'tiki_p_manage_iot_apps' permission which you configure in the admin panel (by default all admins have this permission)

Click to expand

Create a Tracker to hold your IoT devices data and define the fields depending on your requirements : This is crucial, think of the tracker your database (and it is a powerful no-code database built-in Tiki, not familiar with it? check https://doc.tiki.org/Trackers).

Click to expand

When your tracker is ready, go back to /tiki-iot_dashboard.php and from there you can create a new IoT app and tie it to the tracker you just created.

Moving forward, any change that happens into your tracker will also trigger the execution of your IoT defined flow.

Click to expand

Once the app is created and linked with a Tracker, you can now decide what the app actually does. By flow design we give you ability to configure (without writing code) what happen when new entries are created or updated inside the tracker.

Click to expand

Nodes encapsulate logic that happen when data arrives. Current nodes :

• Email Send : It takes text as input, use it as email body, send the email using your existing instance settings then pass the same input text to the next node as is (if any)
• Hardware I/O State : More related to physical devices. You configure the pin number (can be virtual) and decide to change it state when the node is executed. We will take later about the endpoint you can use to read this I/O state.
• File logger : This takes input as text, logs it into a file located at lib/iot_tiki/logs/ then pass the input as is to the next node
• Math Comparison : Get input, pass it to the condition and if condition passes, the flow will continue, if not the flow will stop. The syntax written here follows the calculation syntax https://doc.tiki.org/Calculations and $input represent the input within your formula. The output of your formula SHOULD evaluate to true or false at the end otherwise some unexpected behavior may happen
• String Template : This node is used to rewrite string from input and output whatever is supplied in the config of the node with every occurrence of ==input== being replaced by the input value.
• Sensor Input : This is where we can get data that was inserted into the Tracker. It output the value exactly as supplied
• Webhook Send : Get input and send it as request body via a POST request to the webhook URL is configured

  
  

Click to expand

Click to expand

You can quickly test your flow by inserting new entry in the tracker tied to your IoT app of edit an existing item.

Known issues

* Some setting from the drawing canvas may not take effect untill you have changed that manually. For example you insert a String template node, make sure you type in something before saving, the default value may not be pulled correctly if you don't change at least once before saving. You can keep the same default value but just make sure you changed it manually

After saving data to the Tracker and defining what actions should be performed when new data arrives, you may want to monitor events in real time.

For example, from your mobile device, you could check the current state of your smoke detector. Depending on your setup, you might even see the live smoke levels in your kitchen — without needing to refresh the page.

In industrial applications, the real-time dashboard can be used to monitor the state of multiple sensors simultaneously.

The dashboard is built with widgets that you give different look and pair them with in data source of your choice.

From above screenshot :

1. Choose type of widget :
   1. Sensor input : This widget help visualize data directly from a Tracker field
   2. Led (IO State) : This widget display an "LED" https://en.wikipedia.org/wiki/Light-emitting_diode like design and it's purpose is display state of virtual or real hardware input/output (ON OR OFF).
   3. Gauge : This widget can pull data from any source and display it in a 360 circle, mapping the actual value on a scale of 0-100, so better use the gauge on percentage like value
   4. Half Gauge : similar to the gauge but this one is a half and a moving indicator. This half gauge is also suitable for data in between 0-100
   5. Map : coming soon This will show a map position in a street view using open source map libraries like open street map
   6. Chart : coming soon This will pull data from available source then display in a real time chart
   7. App flow console : This widget display all logs related to your IoT app and past execution logs from the app

2. Choose data source : Here we have your tracker fields, app flow logs and virtually created Hardware IO.
3. Widget icon : This will determine the icon to display in the widget card
4. Widget background color : Color picker to choose the background color of the widget card. For gauges, this is used as the background of the gauge, not the card
5. Widget Text color : Color for text written in the widget card
6. Widget border color : The border color for the widget card
7. Data Unit : The data unit displayed after the value. eg.°C
8. Widget label : The label to display below the value

Click to expand

Click to expand

If your real-time setup was correctly done, stay on the dashboard and submit some data, you will see the change immediately reflecting on the dashboard.

Known issues

* For a hardware I/O node to appear in the I/O dropdown as a data source, you must first configure the I/O in the flow design and log data into the tracker at least once. This limitation exists due to the current detection method for configured I/O in your flow design. Improvements to this behavior are planned in a future update.

Click to expand

Now that we have our IoT app linked with a tiki tracker, we have designed the dashboard to monitor in real time the data that come in and have defined what happen after the data is received via the flow design we need to know how to actually save data into the tracker programmatically.

The first thing to do is to generate an access token.

Click to expand

The combination of the access token and app_id will be used to authenticate our programmatical calls.

We have 3 operations actually implemented and all to be called via a single endpoint {{Base-URL}}/tiki-ajax_services.php?controller=iotapps&action=iot_api_middleware . In the request we need two headers for authentication :

• X-AUTH-TOKEN : The access token previously generated
  • X-APP-UUID : The app id

• set_io_state : this can be used to sync input/ouput state (HIGH, LOW, analog value, etc...) from our physical object to the backend. This state can later be used by another physical object remotely and hence the setter will be controlling the getter remotely.

Eg. of request :

{
    "api_action": "set_io_state",
    "io_ids": {
        "LED#25" : "ON",
    }
}

Supplied io_ids here can be anything depending on your choice. This is a virtual IO, just be sure to use the same io_id when you want to get the state.

• get_io_state : this can be used to get input/ouput state saved to the backend.

Eg. of request :

{
    "api_action": "get_io_state",
    "io_ids": [
        "LED#25",
    ]
}

• record_data : this can be used save data into tracker

Eg. of request :

{
    "api_action": "record_data",
    "payload": {
        "homeairqualitymonitorTemperature": "28",
        "homeairqualitymonitorAirQuality": 48
    }
}

Supplied object keys in the payload are field permanent names https://doc.tiki.org/Permanent-Names

https://youtu.be/hw5FQZ_5wFU?si=oQpxqegv3I9jIi26&t=666