...

Since this information is configured as fugitivetransient, it is not necessary to reset the piloting it to 0. This implies that the Status Point plugin must be placed before the transient plugin in the sequence of south plugins.

...

 {
	"label" :"GAMBS_0_TS-SYST_ACCESPRT.INFA",
	"pivot_id" :"xxx",
	"pivot_type" :"SpsTyp",
	"pivot_subtypes" : ["prt.inf"],
	"protocols" :[
	   {
		  "name" :"hnzip",
		  "typeid":"yyy",
		  "address":"zzz"
	   }
	]
 }

...

• PIVOT.GTIS.Cause.stVal = 3
• PIVOT.GTIS.Identifier = Identifier from the configuration
• PIVOT.GTIS.<TypeDataInExchangedData>.stVal = True
• PIVOT.GTIS.<TypeDataInExchangedData>.t.SecondSinceEpoch (Timestamp of the gateway)
• PIVOT.GTIS.<TypeDataInExchangedData>.t.FractionOfSecond (Timestamp of the gateway)
• PIVOT.GTIS.<TypeDataInExchangedData>.q.Source = substituted
• PIVOT.GTIS.TmOrg.stVal = substituted

...

• For a Simple type data:
  • PIVOT.GTIS.Cause.stVal = 3
  • PIVOT.GTIS.Identifier = Identifier from the configuration
  • PIVOT.GTIS.<TypeDataInExchangedData>.stVal = True
  • PIVOT.GTIS.<TypeDataInExchangedData>.t.SecondSinceEpoch (gateway timestamp)
  • PIVOT.GTIS.<TypeDataInExchangedData>.t.FractionOfSecond (gateway timestamp)
  • PIVOT.GTIS.<TypeExchnagedData>.q.Source = substituted
  • PIVOT.GTIS.TmOrg.stVal = substituted

The type of the status point is read directly from the exchanged_data configuration.

Implementation

Fledge plugins

In order to implement the features above, a plugin with the following features needs to be created:

• Ability to read the Reading data sent by the south plugin.
• Ability to create and send new Readings in the system at will (eg: when a timer expires).

Currently the plugin types available in Fledge (Filter, Notification Rule and Notification Delivery) do not offer these functionalities in a single plugin:

Filter plugins allow to read, edit, add and/or remove Readings passing through Fledge, but only when at least one Reading was published by a south plugin.

Notification Rule plugins allow to send Notification messages (not Readings) when an asset was modified and a predefined set of rules is matched by this asset (so no free Reading creation).

Notification Delivery plugins allow to receive Notifications and act accordingly by producing external API calls to other services (logging, DB, etc...) or internal Fledge API calls (including the creation of Readings).

Design choices

In order to achieve the features needed here, two plugins are created:

• A Notification Rule plugin (fledgepower-rule-systemsp) responsible of scanning the Readings flowing through Fledge and generate a Notification when a relevant event occured.
• A Notification Delivery plugin (fledgepower-notify-systemsp) responsible of:
  • Receiving the Notifications from the other plugin, create new Readings based on the data they contain if necessary, and send those through Fledge.
  • Run cyclic task that will send a Reading through Fledge at regular intervals.

Here the Notification Rule plugin is used to detect changes in readings of type "south_event" and send a notification when a Connection Loss Status Point should be created containing the type of event it represents ("connected" / "connection lost").

The Notification Delivery plugin is used to send Access Status Point Readings periodically based on the exchanged_data configuration and to send Connection Loss Status Point Readings when receiving a notification from the Notification Rule plugin.

Notification structure:

 {
	"asset": "prt.inf",
	"reason": "connected" // or "connection lost"
 }