The following download allows you to execute two IoTResources that simulates two appliances (IoTEntity). A simple  orchestration file which turns the appliances on and off at specified times using the IoTResource actions. The energy profiles tells how much energy the underlying appliance is consuming-. You can change those files  or add more files yourself. The IoTResource will be discovered by the IoTResourceCatalogue  and can be controlled through the REST interface or from a IoT Resource Catalogue Browser.

Download IoTResource

The StorageManagerSetup zip archive contains an installer that will setup all components including MongoDB.

MSMQ must be setup on the machine.

.NET Framework 4.5 must be set up on the machine.

The installer will deploy storagemanager components to “c:\storagemanager” and MongoDB to “c:\mongodb”.

The components in folders MSMQ_SM, Archiver and REST_API are configured to use the same database. If this is changed, the “.config” files must
be changed so that the setting “DatabaseName” points to the same database.

The component in MQTT_MSMQ listens to an MQTT broker at 130.192.86.227 and topic /federation1/trn/v2/observation/#. This may be changed in the
“.config” file.

To avoid editing the config files in MQTT_MSMQ and MSMQ_SM folders, two private transactional MSMQ queues must be setup called:

1) storagemanagerqueue

2) storagemanagerqueuemetadata

The components may be run by runall.bat, which also starts MongoDB.

The Archiver will archive old observation data (default 3 days) and is best run by setting up a basic task in Windows Task Scheduler.

StorageManagerSetup including MongoDB

Download Storage Manager for MongoDB ver 2.4

Download Storage Manager for MongoDB ver 2.6

You can download the IoTResourceCatalogue here. After downloading unzip and start IoTResourceCatalogue.exe “As Adminstrator”. You can also download an example IoTResource to test the catalogue as well as an IoT Catalogue Browser for Windows, iOS  or Android which will allow you to view the content of the catalogue in user-friendly way.

Note: If you are installing under Linux/Mono, put a copy of “System.Device.dll” from a Windows machine into the root of the Resource Catalogue (next to “IoTResourceCatalogue.exe”)

Download IoT Resource Catalogue 20151013 (latest version)

Download IoT Resource Catalogue 20151001

The IoT Resource Catalogue Browser is a tool that allows you to quickly browser throught the content of an IoT Resource Catalogue.

Download IoT Resource Catalogue Browser for Windows

MQTT

In some scenarios, e.g. to handle a lot of updates, Storage Manager may use an MQTT client to listen to events and store data from these instead of using HTTP POST to update the database. A message queue (MSMQ) may be used as a buffer to handle rapid bursts of events.

Event Topic Structure

The event topic structure is  /[PROJECT]/[EVENTTYPE]/[PAYLOAD]/[ENTITYID] /[PROPERTYID]/, e.g. “/test1/observations/iotentity/CNetOffice-3308/3308Occupancy/“.

PROJECT

We start the topic with the project name (“/TEST1/”) in case we have other applications on the same LinkSmart nodes or start re-using existing sensor installations that publish with different topic structures to the same event broker

EVENTTYPE

The “purpose” of the event within the system, suggested values are “observations”, “metadata”, “DF”, “SYSTEM”. Sensor proxies will send measurement data (“observations”) and IoT entity definitions (“metadata”) when new sensors are discovered or updated.

PAYLOAD

This is used to distinguish between different payloads ; e.g “iotentity” for events using the IoTEntity (JSON) format like measurements (“observations”) and entity definitions (“metadata”). This classification depends on the selected “EVENTYPE”, and is currently 1:1, but it’s included for extensibility and to allow migration to alternative formats should the need arise. The current set of values are “iotentity” for EVENTTYPE=”observations” or EVENTTYPE=”metadata”.

ENTITYID/PROPERTYID

For the event types “observations” and “metadata”, the entity and property id will follow the PAYLOAD classification. Subscriptions to observations for a  specific property from a specific sensor will look like “test1/observations/iotentity/CNetOffice-3308/3308Occupancy/#”, and all observations from a specific sensor like “test1/observations/iotentity/CNetOffice-3308/#”.

OTHER

Other (sub) classifications may be added to the topic as needed, depending on the event type.

Examples

/[PROJECT]/[EVENTTYPE]/[PAYLOAD]/[ENTITYID] /[PROPERTYID]/

/test1/observation/iotentity/WasteBin_843582/843582_FillLevel/

/test1/observation/iotentity/CNetOffice-3308/3308Occupancy/

/(test1/observation/senml/CNetOffice-3308/3308Occupancy/)

/test1/metadata/iotentity/CNetOffice-3308/3308Occupancy//

(TEST1/metadata/json-ld/CNetOffice-3308/3308Occupancy/)

/TEST1/query/dfl/[TARGET_DFM=instance_id?]

/TEST1/query/dfl/water-plant

Payload examples

The topic is just to enable filtering and subscriptions to different levels/dimensions – we should not depend on parsing the topic to find out which property the value belongs to, so id:s for sensors or system components (“SYSTEM”) should included be in the payload. In the Iot Entity JSON format the payload would look like this for an observation:

{    "About": "CNetOffice-3308",    "Properties": [        {  "About": "3308Occupancy ",            "IoTStateObservation": [                {                    "Value": "0.69",                    "PhenomenonTime": "2014-06-09T18:08:40.968Z",                    "ResultTime": "2014-06-09T18:08:40.968Z"                }            ]        },    ]}

One could also send several observations in one message (and several properties as well):

{

“About”: “CNetOffice-3308”,

“Properties”: [

{

“About”: “cddf5b70e8c711e3ac100800200c9a66”,

“IoTStateObservation”: [

{

“Value”: “3.000000 7.000000”,

“PhenomenonTime”: “2014-06-09T18:08:40.968Z”,

“ResultTime”: “2014-06-09T18:08:40.968Z”

},

{

“Value”: “2.999996 7.000000”,

“PhenomenonTime”: “2014-05-09T18:08:40.968Z”,

“ResultTime”: “2014-05-09T18:08:40.968Z”

}

]

},

{

“About”: “3308Occupancy”,

“IoTStateObservation”: [

{

“Value”: “0.69”,

“PhenomenonTime”: “2014-06-05T15:33:35.058Z”,

“ResultTime”: “2014-06-05T15:33:35.058Z”

}

]

},

{

“About”: “3308Number of vehicle”,

“IoTStateObservation”: [

{

“Value”: “1.0”,

“PhenomenonTime”: “2014-06-05T15:33:35.058Z”,

“ResultTime”: “2014-06-05T15:33:35.058Z”

}

]

}

]

}

Adding data – POST to Collections

Posting a single element (IoTEntity, IoTProperty or IoTStateObservation) to the respective collection will result in a new element being added to the collection or, if the @about attribute identifies an already existing entity, updating the existing entity.

{base}/IoTEntities

{base}/IoTEntities/{IoTEntityID}/properties

{base}/IoTEntities/{IoTEntityID}/properties/{IoTPropertyID}/observations

Setting data – The PUT method

To be implemented.

Posting an element (IoTEntity, IoTProperty or IoTStateObservation) to the URI identifying the resource will result in the resource being replaced with the contents of the posted representation. E.g., if previously existing IoTProperties in an IoTEntity are not included in the posted representation, these will be deleted from the IoTEntity. To add or merge data, use POST.

{base}/IoTEntities/{IoTEntityID}{base}/IoTEntities/{IoTEntityID}/properties/{IoTPropertyID}

Removing data – The DELETE method

The DELETE method will remove the resource identified by the URI.

{base}/IoTEntities/{IoTEntityID}

{base}/IoTEntities/{IoTEntityID}/properties/{IoTPropertyID}

IoT Settings for the Discovery process

wsport
The port that is used for creating the IoT web services
<add key=”wsport” value=”:80″/>
Default :8080

WSEndPointAlwayLocalHost
Always bind the published WebServices to 127.0.0.1
<add key=”WSEndPointAlwayLocalHost” value=”no”/>
Default: no

IoTCreateWSImmediately
Set to yes when the IoT device is to be used without any discovery process
<add key=”IoTCreateWSImmediately” value=”yes”/>
Default: no

gateway
The name of the hardware gateway (normal a computer) where the IoTResource is executing.
<add key=”gateway” value=””/>
Default:

DeviceDBPath
Path to device databases. A database with the same name as the friendlyName of the IoTResource wiill be created in  the directory specified  by DeviceDBPath. Default is the same directory as the executable.
<add key=”DeviceDBPath” value=”.”/>
Default: .

The IoTResource uses a local database (sqlLite) to store Changes in statevariables, events, logs and errormessages. It is possible to configure which statevariables/properties should be logged into the local database. This is done by changing the property logvariables by using the GetProperty and SetProperty actions in the IoTService of IoTResource.

By default  the local database is created in the same directory as the IoTResource executable, but this could be changed in the appconfig-file.

• LinkSmartEventModel.xsd – Schema for the LinkSmart Events
• LinkSmartIoTEntityModel.xsd – Schema for the LinkSmart IoTEntity model used as payload in events, and in the RESTful API.
• LinkSmartTypeLibrary.xsd – A set of common schema types and components imported by other schemas such as Event and IoTEntity models.
• RDFaTypeDefinitions.xsd – Definitions of basic schema types from the RDFa Core 1.1 specification. These schema types are used for definitions of RDFa attributes in other importing schemas.
• xml.xsd – Definitions of basic XML attributes (xml:base, xml:space, xml:lang) form the W3C for usage in importing schemas.

An  IoT Resource type for any digitally identifiable physical object in the IoT World (possibly associated with an IoTDevice or IoTSensor).