NFC-sensor-reader is 7 cm. A simple touch of an NFC card on the sensor is enough to interact with the reader transmitting data with a maximum speed of 424kbps. Due to the short range of transmissions (from a touch to a few centimetres) the NFC is inherently secure. This new emerging technology of the NFC communications creates a new and universal interface to existing devices through simple touch interaction.
With both of the above identification systems, the unique ID of a user is being transmitted from the identification sensors to the base-station of the Waspmotes-WSN and afterwards to the Gateway of theSyndesiframework. There are two ways by which we can transmit the data to the gateway: the first one is via a USB serial connection and the other one is via a ZigBee communication by which the data are wirelessly transmitted to the Gateway.
3.6 WEB APIs and User Interaction
In order to manage and access the resources of the system we have build Web service APIs that adhere to the REST architectural constraints, called as RESTful APIs. Every service or resource provided by the sensors or the actuators is represented by a RESTful architecture via a form of a URI such as the one in Figure 3.5. By using the GET or POST methods and the appropriate attributes under the "fan?status=" service which in the case of a fan controller can bestatus=onorstatus=off, one can get the current value (status) of the actuator (GET method) or change its value (POST method). In the URI the unique IPv6 address of the node is used and on the nodes’ side we implemented CoAP handlers in order for the node to be able to receive such requests. Once a GET or a POST method has been invoked in the node, it sends back to the requester an acknowledgement of whether the request has been received and whether it was successfully executed. If there is no acknowledgement received it means that either the request packet or the ack packet was lost and a GET request should be invoked in order to control the status of the previous one.
Figure 3.5: CoAP GET/POST request using the IPv6 address of the node. Changing the status of the fan to "ON".
Since our buildings’s backbone networking infrastructure did not support global IPv6 addresses we could not use the unique IPv6 addresses of the nodes from Web locations outside the local area where the WSN was deployed. For this reason we implemented a proxy server named "ero2proxy" in the gateway, to support the translation from HTTP to CoAP requests and vice versa. An example of such a request is shown in Figure 3.6.
Instead of using the unique IPv6 address of the node that we want to interact with, we use the IPv4 address of theSyndesi’sgateway proxy and the unique location identifier e.g. C1S2A1. In this example we use the "Bulb" resource of this node and we set its status to "ON". After the request is made the node replies with an ack stating that the Bulb has been turned ON.
Figure 3.6: Mediate service for accessing a node’s services from the WEB.
3.6. WEB APIs and User Interaction
An other API that we have implemented in theSyndesiis a monitoring service in which a request can be made to a specific node using its location identifier in order to list all its available sensor resources together with their current values. An example is shown in Figure 3.7 where the node C1S7A2 has two sensor resources: one for temperature and one for luminosity. We note here that temperature is measured in °C and the luminosity in "lux" (where higher values of "lux" mean more light).
Figure 3.7: Monitor service for accessing the sensor resources of a node.
In the cases where an experiment or a user would need to monitor all the sensor resources from all the nodes that are connected to theSyndesi, we implemented the
"SensorValues" service which lists all the latest active sensor resources and measurements. This list of sensor values is in JSON format and their values are collected by the period heartbeats of the nodes to the gateway. An example of this service is shown in Figure 3.8.
Since some of the nodes are acting as sensors, some as actuators and some as both, we needed to implement a service which would provide the specifications of each node i.e. access port, protocol, hardware type, host-name, available resources, its URI, its IPv4 IP address and the unique location identifier "node_id". Through this API one can get the full specifications of all the active nodes currently connected to the WSN.
Figure 3.9 illustrates the service API.
Additionally to the "service" API we implemented an API which has similar function to the first one but the difference here is that the information provided for the testbed and its resources are following the XML RSpec format augmented and incorporated into the IPSO Application Framework. The Resource Specification (RSpec) is a schema standardized by the Global Environment for Network Innovations (GENI) [32] on XML
Figure 3.8: "SensorValues" service which lists all the active sensor resources of all the nodes connected toSyndesi.
Figure 3.9: Services and specifications of connected nodes toSyndesi.