Moreover, fixing SmartAPI search method to call the correct backend function.

A search API has been created.
The Backend and the SmartAPI has been modified to support the search functionalities.
A search recieves a series as a parameter, one that do not necessarily specifies a unit. Similar to a workflow, a search type is defined per domain. Moreover, a 'options' parameter is also expected, specifying which type of search will be performed. If options is not presented, search of index 0 will be executed.
A search returns a multi-unit series, ordered by timestamp.

An example for tutorial domain is provided, where through search0 anomalous temperature values are detected in the space-time range specified by the series parameter.

on mu_put.php and mv_put.php we changed instantiation of Backend to support requests with certificate.
on put.php the extra newline that php was complaining about was removed.
on Backend.php was changed to adjust create series (fix algorithm that merge series),
and some bug fixes on multi SmartData insertion.
on Series.php throw exception if invalid values of t0, t1 and r was changed to include the values of these parameters.
on MultiSmartData.php: bug fix on verifying existance of ->uncertainty and adding a parseJson method.
Also, files Backend.php and SmartAPI.php were changed to support get_activity.

Aggregators were changed to remove dependency of range and reflect the documentation at: https://epos.lisha.ufsc.br/IoT+Platform#Data_Aggregation.

Reorganizing the repo structure to match the plan. Apparently, git filter-branch was not necessary to remove certificate's private key because someone had already run it. At least, git log --diff-filter=D --summary | grep delete does not show any private key.

Removing print used for tests. This can cause errors to the workflow output recognition by the API.

Removing importer logs.

Removing private workflows.

This should be on a private repository.

Removing junk files: old code files, python cache files, log folders.

Now, when creating a series, we compare the new series with the already existent ones and if they share space-time and the other attributes (e.g., unit and domain) we only update the existent series and the necessary rows so that it encompasses the new series being inserted. If there is no space-time intersection, the new series is inserted on the data-base.

A whole response json can be too large to be handled as an argument to a workflow call. Thus we decided to inform the parameters with a buffer file to be read by the workflow.
Also, as previously discussed, the series workflow is not used as a filter during data querying. It is used to process the data before responding to the client.

Backend now controls workflow daemon execution;
Workflows are placed directly on /smartdata/bin/;
Workflow names are inN and outN for input and output workflows, respectively;
S-curve workflow (in3) added to aqtech domain;
Workflows are able to make notifications via the returned JSON.

Most of the differences were related to the fact that aggregators are not already available on sv3.
The Backend differences were innocuous (spaces, indentation, and blank lines).
Config changes consists on email and log address.

Updating bin/smartdata/Aggregators.php to add Aggregators to developed on 2019-2.
Updating lib files to include those aggregators.
Uploading the smartdata_grafana_plugin, with the code that when compiled generates the lib folder.
Lib folder's content is the one we put on the server. This content is generated using the plugin code, that was originally placed at https://epos.lisha.ufsc.br/svn/makers/smartdata_grafana_plugin/.
A tutorial of how to do this process is available at https://epos.lisha.ufsc.br/IoT+Internals#Grafana_Integration. However, it is a bit outdated. Should I update the page at epos site or create a README inside the plugin folder on gitlab?