Difference between revisions of "How to implement a new plugin"

From AMTech WikiDocs
Jump to: navigation, search
(v)
 
(5 intermediate revisions by the same user not shown)
Line 35: Line 35:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
== Implementing smoothing ==
+
== Smoothing observations ==
 +
In order to allow the plugin to reduce  the number of unnecessary observations, we propose a ''SmoothingHandler'' class. This class implements the smoothing process described [[here]] according to some given configurations.
  
 +
The main advantages of using this class would be:
 +
* New smoothing criteria could be included in the future according to the users needs.
 +
* Smoothing process can be done in a device-wise manner allowing to handle several devices with the same plugin instance (e.g. with beacon scanners)
 +
* It is possible to use several independent smoothing processes at the same time according to different models (for instance one model for ibeacons and one for eddystone ones)
 +
* Possibility to know which fields satisfied their configured smoothing criteria
 +
 +
=== Using smoothing in the plugins ===
 
In order to include the smoothing tool we propose, the nodejs code should :
 
In order to include the smoothing tool we propose, the nodejs code should :
 
*[[#Import_smoothing_handler|Import the code of the smoothing handler]]
 
*[[#Import_smoothing_handler|Import the code of the smoothing handler]]
Line 43: Line 51:
 
*[[#Verify_smoothing_criteria| Verify each observation by the smoothing handler before send it]]
 
*[[#Verify_smoothing_criteria| Verify each observation by the smoothing handler before send it]]
  
=== Import smoothing handler ===
+
==== Import smoothing handler ====
 
To import the smoothing handler class include the code belo at the beginning of the ''nodejs'' file
 
To import the smoothing handler class include the code belo at the beginning of the ''nodejs'' file
 
<syntaxhighlight>
 
<syntaxhighlight>
Line 49: Line 57:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
=== Initialize smoothing handler ===
+
==== Initialize smoothing handler ====
 
The smoothing handlers should be initialized on the '''start''' function of the plugin with the smoothing configuration to use (see [[#Smoothing_configuration|below]]).  
 
The smoothing handlers should be initialized on the '''start''' function of the plugin with the smoothing configuration to use (see [[#Smoothing_configuration|below]]).  
 
<syntaxhighlight>
 
<syntaxhighlight>
Line 56: Line 64:
 
where ''smoothingId'' is used only for logging purpose and ''smoothingConfig'' contains the smoothing configuration.
 
where ''smoothingId'' is used only for logging purpose and ''smoothingConfig'' contains the smoothing configuration.
  
=== Free memory ===
+
==== Free memory ====
 
To avoid issues upon restart of plugins and bridges, the smoothing memory should be freed on plugin '''stop''' function
 
To avoid issues upon restart of plugins and bridges, the smoothing memory should be freed on plugin '''stop''' function
 
<syntaxhighlight>
 
<syntaxhighlight>
Line 63: Line 71:
 
</syntaxhighlight>
 
</syntaxhighlight>
  
=== Verify smoothing criteria ===  
+
==== Verify smoothing criteria ====  
 
To verify if an observation satisfies or not the smoothing criteria use the '''smooth''' function of the smoothing handler, for instance:  
 
To verify if an observation satisfies or not the smoothing criteria use the '''smooth''' function of the smoothing handler, for instance:  
 
<syntaxhighlight>
 
<syntaxhighlight>
if (this.smoothingHandler.smooth(deviceId, observation)){
+
if (this.smoothingHandler.smooth(deviceId, observationInfo)){
 
   this.sendObservation(...);
 
   this.sendObservation(...);
 
}
 
}
 
</syntaxhighlight>
 
</syntaxhighlight>
  
If the observation does satisfy any of the smoothing criteria, then an object is returned with every field that satisfied its smoothing criteria
+
It is possible also to know which fields have satisfied the smoothing criteria by including a third parameter holding an array:
 +
<syntaxhighlight>
 +
  var changedFields = [];
 +
  var smoothingSatisfied=this.smoothingHandler.smooth(deviceId, observationInfo, changedFields));
 +
</syntaxhighlight>
 +
 
 +
 
 
=== Smoothing configuration ===
 
=== Smoothing configuration ===
 +
 +
== Managing observation delivery ==
 +
There exist another tool called ''ObservationDeliveryMgr''. This tool manage when the observations are sent. For instance, it can send the observations at a given frequency reducing the number of observations sent.
 +
 +
Using this class will allow, by instance configuration, to
 +
* say if all the observations should be sent or if the observations should be stored so they are only sent with some time interval.
 +
 +
Other features could be added to this class making them available for each plugin
 +
 +
=== How to use it  ===
 +
The plugin code should :
 +
*[[#Import_observationdeliverymgr_class|Import the code of the ''ObservationDeliveryMgr'' class]]
 +
*[[#Initialize_observation_delivery_mgr|Initialize the observation delivery manager with the given configuration]]
 +
*[[#Stop_observation_delivery_mgr| Stop the observation delivery manager]]
 +
*[[#Post_observations_delivery_mgr| Post the observations to the delivery manager]]
 +
   
 +
=== <span id="Import_observationdeliverymgr_class"> Import ObservationDeliveryMgr class ===
 +
  const ObservationDeliveryMgr = require("../../common/observationDeliveryMgr.js");
 +
=== <span id="Initialize_observation_delivery_mgr"> Initialize observation delivery manager ===
 +
  var observationDeliveryMgr = new ObservationDeliveryMgr(config);
 +
  observationDeliveryMgr.start(done)
 +
where ''done'' is the callback to call when the start process is finished and ''config'' is an object with
 +
  timeInterval: time interval to send observations. Set to 0 or undefined to send all observations
 +
  sendFunction: function to call each time an observation should be sent
 +
  logger: logger object
 +
 +
=== <span id="Stop_observation_delivery_mgr"> Stop observation delivery manager ===
 +
  observationDeliveryMgr.stop(done)
 +
when ''done'' is the callback to call when the manager has been stopped
 +
 +
=== <span id="Post_observations_delivery_mgr"> Post observations delivery manager ===
 +
Each time the plugin has an observation ready it should call the ''postObservation'' function
 +
  observationDeliveryMgr.postObservation(id, observation, ph)
 +
where ''observation'' is the observation object to be sent and ''ph'' is the list of placeholders
 +
 +
In this case, according to the given ''timeInterval'', the manager will
 +
; timeInterval= '''undefined''' or '''0'''
 +
: The ''sendFunction'' callback is called inmediately with the given ''observation'' and ''ph''
 +
; timeInterval>0
 +
: The ''observation'' and ''ph'' are cached associated to the given ''id''. If there was another observation, only the last will be kept for each ''id''. Then the ''sendFunction'' will be called with the ''observation'' and ''ph'' cached for each ''id''

Latest revision as of 10:11, 14 June 2018

  • Create a thing type XXXThing (See Thing types)
  • Create the observations type the thing XXXThing produces or consumes, example XXXThingObserv1 (See Observations and observation types)
  • Associate the observation XXXThingObserv1 type to the XXXThing
  • Implement a nodejs module with the following interface
    function XXXThing() {
    }

    XXXThing.prototype.start = function ( complete) {
        try {
            complete(null);
        } catch (e) {
            complete(e);
        }
    };

    XXXThing.prototype.stop = function (complete) {
        try {
            complete(null);
        } catch (e) {
            complete(e);
        }
    };

    XXXThing.prototype.command = function (observation, complete) {
        try {
            complete(null);
        } catch (e) {
            complete(e);
        }
    };

    module.exports.XXXThing = XXXThing;

Smoothing observations

In order to allow the plugin to reduce the number of unnecessary observations, we propose a SmoothingHandler class. This class implements the smoothing process described here according to some given configurations.

The main advantages of using this class would be:

  • New smoothing criteria could be included in the future according to the users needs.
  • Smoothing process can be done in a device-wise manner allowing to handle several devices with the same plugin instance (e.g. with beacon scanners)
  • It is possible to use several independent smoothing processes at the same time according to different models (for instance one model for ibeacons and one for eddystone ones)
  • Possibility to know which fields satisfied their configured smoothing criteria

Using smoothing in the plugins

In order to include the smoothing tool we propose, the nodejs code should :

Import smoothing handler

To import the smoothing handler class include the code belo at the beginning of the nodejs file

const SmoothingHandler = require("../../common/smoothingHandler.js");

Initialize smoothing handler

The smoothing handlers should be initialized on the start function of the plugin with the smoothing configuration to use (see below).

this.smoothingHandler = new SmoothingHandler(smoothingConfig, this.logger, smoothingId);

where smoothingId is used only for logging purpose and smoothingConfig contains the smoothing configuration.

Free memory

To avoid issues upon restart of plugins and bridges, the smoothing memory should be freed on plugin stop function

this.smoothingHandler.destroy();
this.smoothingHandler=undefined;

Verify smoothing criteria

To verify if an observation satisfies or not the smoothing criteria use the smooth function of the smoothing handler, for instance:

if (this.smoothingHandler.smooth(deviceId, observationInfo)){
   this.sendObservation(...);
}

It is possible also to know which fields have satisfied the smoothing criteria by including a third parameter holding an array:

  var changedFields = [];
  var smoothingSatisfied=this.smoothingHandler.smooth(deviceId, observationInfo, changedFields));


Smoothing configuration

Managing observation delivery

There exist another tool called ObservationDeliveryMgr. This tool manage when the observations are sent. For instance, it can send the observations at a given frequency reducing the number of observations sent.

Using this class will allow, by instance configuration, to

  • say if all the observations should be sent or if the observations should be stored so they are only sent with some time interval.

Other features could be added to this class making them available for each plugin

How to use it

The plugin code should :

Import ObservationDeliveryMgr class

 const ObservationDeliveryMgr = require("../../common/observationDeliveryMgr.js");

Initialize observation delivery manager

 var observationDeliveryMgr = new ObservationDeliveryMgr(config);
 observationDeliveryMgr.start(done)

where done is the callback to call when the start process is finished and config is an object with

 timeInterval: time interval to send observations. Set to 0 or undefined to send all observations
 sendFunction: function to call each time an observation should be sent
 logger: logger object

Stop observation delivery manager

 observationDeliveryMgr.stop(done)

when done is the callback to call when the manager has been stopped

Post observations delivery manager

Each time the plugin has an observation ready it should call the postObservation function

 observationDeliveryMgr.postObservation(id, observation, ph)

where observation is the observation object to be sent and ph is the list of placeholders

In this case, according to the given timeInterval, the manager will

timeInterval= undefined or 0
The sendFunction callback is called inmediately with the given observation and ph
timeInterval>0
The observation and ph are cached associated to the given id. If there was another observation, only the last will be kept for each id. Then the sendFunction will be called with the observation and ph cached for each id