Archives: Wikis

IoTSensor

An IoT Resource type used to describe a sensor, such as brightness, thermometer, humidity sensors etc. The IoT Sensor provides a common sensor service for presenting data.

Services

Sensor service

The SensorService provides a list of actions for accessing sensor data and setting sensor parameters.  Sensor data refers to: IoTProperty concerned, the Observations for this property, and, the values of these observations.


GetIoTProperty
Returns the IoT Property (IoT Property content model) with the latest observation


GetMaxObservation
Returns the maximum observation (highest value)


GetMinObservation
Returns the minimum observation (lowest value)


GetObservation,
Returns the latest IoT State Observation  (Observation content model)


GetObservationValue
Returns the value of the latest observation


GetReportingThreshold
Returns the reporting threshold set for the IoT Sensor


SetReportingThreshold
Argument:
Set the reporting threshold set for the IoT Sensor


 

IoTDevice

An IoT Resource type used to represent any physical device that can be accessed and controlled by some communication interface. Typical sub-resource types are metering devices like smart plugs, UPnP-based devices like TV:s, routers, media players in a local network, Zigbee-based devices and Bluetooth-based devices like health monitoring equipment.

The IoTDevice resource provides a common energy service for presenting data related to the device energy consumption, this  could either be derived from real measurementsor from energy profiles associated with the device.

Services

EnergyService

The EnergyService provides a list of actions for the energy usage and energy profiles of devices. Below is a short explanation of these  actions:


GetCurrentUsage
Returns the current effect for the device in its current operating mode


GetTotalUsage
Returns the total energy consumption for the device


GetDeviceEnergyPolicy
Returns the current energy policy assigned to the device


GetEnergyMode
Returns the current mode energy mode for the device


GetEnergyPolicyStatus
Returns the status for the different properties expressed in the energy policy


GetEnergyProfile
Returns the current energy profile assigned to the device


GetEnergyClass
Returns the current energy class for the device including the classification system


GetRemainingLifeTime
Returns the estimated current remaining lifetime for the device


GetMaxEffect
Returns the max effect value for the current operating mode of the device


GetMinEffect
Returns the min effect value for the current operating mode of the device


GetAverageEffect
Returns the average effect value for the current operating mode of the device


SetDeviceEnergyPolicy
Argument:
Sets the current energy policy to the device


SetDeviceEnergyPolicyFromURL
Argument:
Sets the current energy policy to the device from an URL


SetEnergyProfile
Argument:
Sets the current energy profile to the device


SetEnergyProfileFromURL
Argument:
Returns the current energy profile to the device from an URL


 

IoT Storage Manager

The Storage Manager is a LinkSmart .net component that acts as an adapter for different storage technologies (primarily time series data). By using the Storage Manager your applications will be future-proof and you can easily change the underlying database technology. It provides support for the OPC SensorThings Data Model and API. The OGC SensorThings API provides an open and unified way to interconnect the Internet of Things devices, data, and applications over the Web. The OGC SensorThings API is an open standard, and that means it is non-proprietary, platform-independent, and perpetual royalty-free.

The Data model supported by the Storage Manager is shown below:

ogcthings

The Storage Manager consists of the following three main components:

Storage Adapter
Linksmart.NET does not specify or implement a specific storage technology. Instead, it provides a set of APIs to integrate different storage solutions depending on the application needs. Relational databases, document databases or graph stores, deployed locally or in the cloud, may be used. When the amount of time-series data – Observations – is very large, specialized databases like InfluxDb, KariosDB or OpenTSDB may be necessary. (Often, SQL Server or MongoDB is sufficient.)
 
Query API
A REST interface is used to query the Storage Manager. This follows the OGC SensorThings API Sensing Profile specification, a subset of OData v4. Some extensions exist to facilitate integration with other data store. The Query API is implemented using the Storage Adapter.
 
Receiver and Archiver
The Receiver and Archiver components listens to events from the messaging components and stores them using the Storage Adapter. Format and messaging protocol conversion is implemented by these components. Queueing of messages allows the system to adapt to bursts of events or temporarily busy storage. (Storing Observations by using HTTP POST is also possible, but this is usually not a feasible for high volumes of observation data.)

Managing Subscriptions

The LinkSmart Event Manager provides publish/subscribe functionality, i.e., the ability for publishers to send a notification to multiple subscribers while being decoupled from them (in terms of, e.g., not holding direct references to subscribers). The Event Manager is used in any place where there is a potential many-to-many relationship between senders and receivers and where asynchronous communication is desirable.

The Event Manager routes events to subscribed clients and a EventSubscriber.zip assists in interfacing to the Network Manager (e.g., broadcast-, multicast-, or gossiping-based dissemination). It manages persistent subscriptions and publication to subscription matching etc. The Event Manager allows sending and receiving events through the LinkSmart P2P network.

An event message consists of a standardized header section including metadata for routing and management of event messages without requirements for reading the actual content, the payload, of the message. It includes topic definitions, identification etc. The payload of the message can now include any content.  See Events – Content Model for a full description of the event information model.

For set up a subscription, the receiver of events needs to:

  1. Add web service wsdl to Event Manager either by file or direct from the Event Manager.
  2. Implement the call back notification methods and,
  3. Register the subscription with the Event Manager providing the call back address.

For publication of events, the publisher needs to

  1. Add web service WSDL to the Event Manager either by file or direct from the Event Manager.
  2. call the publication methods of the Event Manager.

Add web service WSDL to Event Manager

In ordet to communicate with the Event Manager a web service needs to be added. Either using local WSDL that can be downloaded here: EventManagerWSDL.zip or direct from the Event Manager: http://127.0.0.1:8124/Service/Meta?wsdl, were url and port is set in the Event Manager configuration file.

Setting up Event Subscriptions

Three subscribe methods are available for setting up event subscriptions using XPath based selection mechanisms. They differ in how they express the call-back address of its notification method, it is either a local address (i.e. an endpoint) when a LinkSmart Network Manager is not used, or a persistent (the PID) or dynamic (the HID) address within a LinkSmart virtual network.

public bool subscribeXPath(string xpath, string endpoint, int priority)

public bool subscribeXPathWithHID(string xpath, string HID, int priority)

public bool subscribeXPathWithPID(string xpath, string PID, int priority)

The ‘xpath’ parameter is used to define a filter on which events that will be included in the subscription based on the content of the event, both in terms of event metadata and payload.

Examples:

  • .* wildcard subscription – result in a subscription of all events.
  • //[local-name()=’IoTEntity’ and @about=’000D6F0000D36116′]  – result in a subscription of all events including an IoTEntity element with an @about attribute taking the value ‘000D6F0000D36116′
  • //[local-name()=’IoTProperty’ and @typeof=’TEMPERATURE’])   – result in a subscription of all events including an IoTProperty element with a @typeof attribute taking the value ‘TEMPERATURE’

Note that namespaces are not currently supported in the XPath expression which requires somewhat clumsy XPath expressions using local-name() functions.

The ‘priority’ parameter is used to request higher priority in delivery of event messages where a higher number sets an higher priority. Normally, it can be set to ‘1’.

See Use case – Setting up an Event Subscription using the Network Manager and Event Manager for a detailed example of setting up a subscription in a LinkSmart network.

Unsubscribing

Subscriptions can be cancelled by calling unsubscribe() or clearSubscription() methods. Depending on how the subscription was set up, the corresponding unsubscribe() method should be used to cancel a particular subscription:

public bool unsubscribe(string selection, string endpoint)

public bool unsubscribeWithHID(string selection, string HID)

public bool unsubscribeWithPID(string selection, string PID)

For cancelling all subscriptions by a particular receiver, call the appropriate clearSubscription() methods:

public bool clearSubscriptions(string endpoint)

public bool clearSubscriptionsWithHID(string HID)

public bool clearSubscriptionsWithPID(string PID)

Call back notification method to be implemented by the subscriber

An entity that wants to receive events from the Event Manager must implement a notification method as a Web Service on the provided endpoint or virtual address.

The Web Service method that must be implemented is:

public bool notifyXmlEvent(string eventXmlString)

It is defined in a WSDL that can be downloaded here: EventSubscriber.zip. Note that it also include other legacy methods.

Event publishing method to be called by the publisher

The entity that wants to publish an event via the Event Manager must first create a Event Manager Port Client and call its publishXmlEvent() method. The port client can be found in the WSDL for the Event Manager.

public bool publishXmlEvent(string eventXmlString)

Event Content Model

Event message header Content Model

Event messages are XML documents. The content model for events consists of a generic metadata message header with a payload of data, such as IoTProperty state observations of IoTEntities. The content model is adapted to the semantic web standards from W3C, namely the RDFa Core 1.1 – Second Edition.

Figure: The top level of the generic Event Model

The Event content model is defined in the Event XML Schema and basically consists of three parts, a descriptive event metadata section (EventMeta), an event source description (Source) and a content body (Content) that includes the actual payload of the event, e.g. a temperature reading for a room entity.

The @about and @prefix attributes will be used to express a globally unique identifier and ontology reference definitions for the event message. Please see the RDFa section for further information on usage of these attributes.

Figure: The EventMeta content model

The EventMeta element is described above. The EventID includes a globally unique identifier of the event. It is provided for compatibility reasons and MUST be the same as the value expressed in the @about attribute of the Event element.

The TimeStamp element holds the datetime of when the event was first generated.

The EventType and Topic elements both provides means for tagging the event with descriptive metadata according to a predefined ontology referenced using the @typeof attribute (RDFa).

The Comment element can be used to provide human readable information about the event. The intention is that this element may used during development and testing.

Finally, the content of an EventMeta is open for extension by any other element provided that it is defined within an namespace that differs from the target namespace of the Event model schema.

[Describe the Source element]

Example

Figure: An example of an Event message

[add more details here]

Event data content – The message payload

The event payload as expressed within the Content element is expected to follow the IoTEntity XML Schema for IoT applications. Please see the IoTEntity section for further information about this model.

The event payload may however be any XML content that does not violate the Well-formed property of the XML document. The only constraint is that the Event XML Schema requires that the Content child elements are defined in another namespace than used as target namespace by the Event schema itself.

Event Manager

The Linksmart.net gateway also provide means to detect and act on events that takes place in the physical world, such as a  door was closed, furthermore observations and  state changes in the physical world can be logged  and reported to the cloud, thus providing the necessary  facilitities to create and make use of big data.

SCPD

The SCPD (Service Control Point Document) contains the description of the IoTResource. It is an XML document consisting of two blocks – the statevariables (or properties) of the IoTResource and a set of links to descriptions of the different services provided by the IoTResource.
iotresourceSCPD