#openiotchallenge

Competitors Tracking for Activ-IoTy

Update of the ActivIoTy project for the Eclipse Open IoT Challenge.

We are on the last mile of the challenge, and I’m exploring new ways to enrich the user experience of the platform, adding new features. The system is based on fixed checkpoints that informs organisers and the public about the status of the competition. In between of these points there is no information. The general public standing at the finish line of a competition is interested in having a constant feedback. So the system should offer information in real time about certain competitors —for instance, the first male and female in the competition.

Tracking the position of an athlete is really simple nowadays. Indeed, you can do it with mobile apps such as Strava. Carrying the smartphone is not a solution in this case, due to competitors try to avoid unnecessary overweights. Also, in case of runners that want to use this solution, in rainy days and on muddy trail courses is not a good idea. Also in ultra-distance races is not feasible due to battery lifetime.

The solution I propose is to create an active transponder that broadcast real-time notifications with the GPS location of the competitor on a GPRS connection. The aim of this component is informing in real time about the status of the race. It will be attached (e.g., sewed to a vest) to the official or volunteer that leads the race (on car, or bike).

For this, I chose the Adafruit FONA 3G Cellular Module. The European Version of this module provides WCDMA + HSDPA support, with GSM backwards-compatibility, and a built-in GPS module for geolocation. It was controlled by a lightweight Arduino Lilypad board, and powered by a 3.7v LiPo Battery.

Assembly is really easy with this Adafruit tutorial. This tutorial also offers a library and examples for Arduino. The implementation for my Lilypad was easy to adapt, just power connections and configuration of RX, TX and RTSin (flow control). If you use another Arduino model, and other pin configuration, you'll have to check its interrupt pins that are required for TX/RX.

I've experienced problems with the code, specially with the responses to the FONA3G commands. After introducing several delays in the execution of the sketch, it runs the basic tasks we need:

Connect to the module and detect the version (European Version);

Identify the SIM IMEI;

Detect and connect the network;

Configure (APN, username and password) and establish a GPRS connection (for a Vodafone Spain SIM card);

Connect and fix the GPS;

Read the GPS location and submit coordinates to a web server;

(Repeat from 5)

The location collected will be sent to a script that stores and processes the information. Since the purpose of this is just testing, those coordinates will be forwarded to a variable called 'First Competitor' within Ubidots. I chose this platform because it provides an easy way to represent lat/log tracking of devices.

This is the main code of the sketch I used (trimmed for better legibility):

#include "Adafruit_FONA.h" #define FONA_RX 2 #define FONA_TX 3 #define FONA_RST 5 #include <softwareserial.h> SoftwareSerial fonaSS = SoftwareSerial(FONA_TX, FONA_RX); SoftwareSerial *fonaSerial = &fonaSS; Adafruit_FONA_3G fona = Adafruit_FONA_3G(FONA_RST); void setup() { while (!Serial); Serial.begin(115200); Serial.println(F("Initializing FONA 3G...")); fonaSerial->begin(4800); if (! fona.begin(*fonaSerial)) { Serial.println(F("Couldn't find FONA")); while (1); } type = fona.type(); Serial.println(F("FONA is OK")); // Print module IMEI number. char imei[16] = {0}; uint8_t imeiLen = fona.getIMEI(imei); if (imeiLen > 0) { Serial.print("Module IMEI: "); Serial.println(imei); } fona.setGPRSNetworkSettings(F("airtelwap.es"), F("wap@wap"), F("wap125")); fona.setHTTPSRedirect(true); printBatteryLevel(); waitForNetworkConnection(); delay(2000); printRSSI(); delay(2000); turnGPRSOn(); delay(5000); turnGPSOn(); delay(5000); while (!isGPRSEnabled()) { delay(2000); } } void turnGPRSOn() { Serial.println(F("Enabling GPRS...")); fona.enableGPRS(true); } void turnGPSOn() { Serial.println(F("Enabling GPS...")); fona.enableGPS(true); } uint16_t isGPRSEnabled() { uint16_t status = fona.GPRSstate(); Serial.println(F("GPRS status:")); Serial.println(status); return status; } void waitForNetworkConnection() { // read the network/cellular status uint8_t n = 0; while (n!=1) { Serial.println(F("Checking network connection")); n = fona.getNetworkStatus(); delay(500); } Serial.println(F("Registered (home)")); } void printBatteryLevel() { uint16_t vbat; while (! fona.getBattPercent(&vbat)) { Serial.println(F("Failed to read Battery")); } Serial.print(F("Battery level = ")); Serial.print(vbat); Serial.println(F("%")); } void updateValues(float lat, float lng) { // read website URL uint16_t statuscode; int16_t length; String latitudeStr = String(lat); String longitudeStr = String(lng); String url = String("activioty.ddns.net/tracker/update?bibId=1&lat=" + latitudeStr + "&lng=" + longitudeStr); Serial.println(F("GET...")); Serial.println(url); Serial.println(F("****")); if (!fona.HTTP_GET_start(url.c_str(), &statuscode, (uint16_t *)&length)) { Serial.println("Failed!"); return; } while (length > 0) { while (fona.available()) { char c = fona.read(); Serial.write(c); length--; if (! length) return; } } Serial.println(F("\n****")); fona.HTTP_GET_end(); } void gpsFix() { // check GPS fix fona.GPSstatus(); } void checkGPSLocation() { char gpsdata[120]; fona.getGPS(0, gpsdata, 120); Serial.println(F("Reply in format: mode,fixstatus,utctime(yyyymmddHHMMSS),latitude,longitude,altitude,speed,course,fixmode,reserved1,HDOP,PDOP,VDOP,reserved2,view_satellites,used_satellites,reserved3,C/N0max,HPA,VPA")); Serial.println(gpsdata); } void loop() { printBatteryLevel(); Serial.println(F("GPS Status...")); gpsFix(); delay(5000); Serial.println(F("GPS Location...")); float latitude, longitude, speed_kph, heading, altitude; // if you ask for an altitude reading, getGPS will return false if there isn't a 3D fix boolean gps_success = fona.getGPS(&latitude, &longitude, &speed_kph, &heading, &altitude); delay(1000); if (gps_success) { Serial.print("GPS lat:"); Serial.println(latitude, 6); Serial.print("GPS long:"); Serial.println(longitude, 6); Serial.print("GPS speed KPH:"); Serial.println(speed_kph); Serial.print("GPS heading:"); Serial.println(heading); Serial.print("GPS altitude:"); Serial.println(altitude); Serial.println(F("Updating values...")); updateValues(latitude, longitude); } else { Serial.println("Waiting for FONA GPS 3D fix..."); } delay(30000); }

You can check the full code on Github.

Yes, you realized of something weird up there. The updateValues function makes a HTTP GET call to update values. I have some problems to use the POST method with that FONA library. Anyway, for testing purposes I created a script that posts the information from activioty.ddns.net to Ubidots.com.

Update of the ActivIoTy project for the Eclipse Open IoT Challenge.

This is a cheap option to implement an Activ-IoTy compatible checkpoint.

Athletics events are usually controlled by officials with different roles such as: judges, timekeepers and starters. Other competitions must rely on officials with other roles, even volunteers or marshals. This solution enables officials and volunteers to register athletes at checkpoints using a simple physical keypad to type athlete's bib numbers.

Since all athletes must wear a visible bib identifier, this implementation is compatible with the existing rules of official competitions. Keypad may be substituted by a complete keyboard. Of course, the keypad could be a capacitive screen (i.e., tablet, smartphone, etc.) but it is probed that data input operators are more efficient with physical typing devices. Also they may be robust, even waterproof.

This solution only needs a bluetooth input device connected to a Raspberry Pi, or similar.

The official located nearby the checkpoint type the bib number and press enter to register athletes' checkinw. The system will send the information (bib number + timestamp) of this checkin automatically.

The implementation is based on the module I developed to implement the Checkpoint based on a RFID Reader.

Both approaches implement a generic Reader that performs two main tasks: initialization (setup of the checkpoint) and doInventory.

class Reader(object): def __init__(self): pass def initialize(self): pass def doInventory(self): pass

They also use a common class Checkpoint that implements all the basic functionality of a checkpoint:

Get reliable timestamps from a common NTP server;

Establish a connection with the MQTT server (once it is connected and set-up sends a {checkpointId}/ready message);

Through a Reader, read either bib numbers or RFID EPCs that are related to each competitor (once they are read, they are sent to the MQTT queue under the topic {checkpointId}/checkin);

This is executed in an infinite loop. The controller will be in charge of deal with the messages and do the business logic.

The Checkpoint is implemented using ntplib and paho.mqtt. This is a summary of the code:

# ... imports ... import ntplib import paho.mqtt.publish as publish class Checkpoint(object): TOPIC_READY = 'ready' TOPIC_CHECKIN = 'checkin' def __init__(self, id, reader, mqttBrokerHost, mqttBrokerPort=1883): ''' :param id: String with the identifier of the Checkpoint :param reader: Ind903Reader object (or other Reader) that will do the inventory :param mqttBrokerHost: String with the hostname of the MQTT broker :param mqttBrokerPort: (int) with the port of the MQTT broker (1883 by default) ''' self.id = id self.reader = reader self.mqttBrokerHost = mqttBrokerHost self.mqttBrokerPort = mqttBrokerPort self.timestampOffset = self.getOffsetNTPTime() def checkinCompetitor(self, idCompetitorEPC, idCompetitorBibNumber): ''' Method to be called once a competitor do a check-in. This is a callback method to be send to the reader. It sends a MQTT message to the broker :param idCompetitor: String with the ID of the competitor that the reader detected. ''' competitor = {} if (idCompetitorEPC != None): competitor["epc"] = idCompetitorEPC; if (idCompetitorBibNumber != None): competitor["bib"] = idCompetitorBibNumber; messageCheckin = { "checkpoint" : self.id , "timestamp" : self.getTimestamp(), "competitor" : competitor } topic = self.id + "/" + self.TOPIC_CHECKIN publish.single(topic, json.dumps(messageCheckin), hostname=self.mqttBrokerHost) print(topic + " topic to MQTT:") print(json.dumps(messageCheckin)) def execute(self): messageReady = { "checkpoint" : self.id , "timestamp" : self.getTimestamp() } topic = self.id + "/" + self.TOPIC_READY publish.single(topic, json.dumps(messageReady), hostname=self.mqttBrokerHost) print(topic + " topic to MQTT:") print(json.dumps(messageReady)) self.reader.initialize() self.reader.doInventory(self.checkinCompetitor) def getOffsetNTPTime(self): ''' Get timestamp from a NTP server and stores the offset with the internal clock. :return: (float) with the difference between the local clock and the NTP time (in seconds) ''' c = ntplib.NTPClient() response = c.request('europe.pool.ntp.org', version=3) # convert from seconds since 1900 to seconds since 1970 ntpUnixtime = response.tx_timestamp - 2208988800 timestampOffset = time.time() - ntpUnixtime; return timestampOffset def getTimestamp(self): ''' Returns the local time plus the offset registered at the beginning. :return: long with the current timestamp (unix time) ''' return int(time.time() + self.timestampOffset)

The key part of this code is the execution itself:

def execute(self): ... self.reader.doInventory(self.checkinCompetitor)

When the checkpoint is correctly setup, the reader is asked to start the inventory of runners. Once either a bibNumber (from a keyboard input) or a EPC (from the RFID reader) is detected the checkinCompetitor callback is executed. This method creates the message for the MQTT receivers that will contains the information about the competitor id.

The functionality of this specific checkpoint is implemented using the following main method:

# ... imports if __name__ == '__main__': reader = usb_keypad_reader.USBKeypadReader() checkpoint = checkpoint.Checkpoint('Keypad-1', reader, 'activioty.ddns.net') checkpoint.execute()

Update of the ActivIoTy project for the Eclipse Open IoT Challenge.

Having in mind a less optimistic scenario –low budget, few resources–, I've implemented another checkpoint using a different solution. This option would cost less than $50 and it's really easy to use. It can be developed with a components from a basic Arduino-like kit.

A system based on Infrared (IR) remote control, is not very reliable for our purpose since there must be a direct visual line between transmitter and receiver –likely TV remote controls. More than a real solution, this is a proof of concept.

This checkpoint would help a person from the staff (volunteer, official, marshal, whoever) register the bib number of competitors at specific points along the race course. Bib numbers will be introduced through a numeric keypad. The official would type the bib number and press enter. The system will send the information (bib number + timestamp) of this checkin automatically.

This module uses typical components available in most of the basic prototyping kits. So this could be implemented easily by anyone. In this case I've used components I bought years ago in my first Arduino kit:

Arduino One rev 3

CC3000 WiFi Shield. This could be changed for an Ethernet or 3G breakout, depending on the type of connection we will have).

SFH5110 Infrared Receiver. (Other models such as the TSOP312 are also welcome)

Generic remote IR control. (I used a generic IR remote control, but you can recycle your old TV remote control).

2 × LEDs. To provide feedback when a key is pressed and a bib number is sent (or delete the current one if mistaken).

2 × 220 ohms resistors.

The checkpoint would work in the same way as the rest of checkpoints:

Connect to the Internet (using the WiFi shield or any other method you need)

Get the official time from a NTP server in Unix time format.

In this case, the Arduino stores the offset between the internal clock and the NTP time. So it will calculate the synchronized time using the internal clock and the offset.

Send a MQTT ready message to the MQTT broker indicating the timestamp and the own ID.

Enter in a loop waiting for entries.

In this case, the Arduino enters in an infinite loop to read bib numbers read more.

The script will enter in a loop waiting for keys pressed (numbers). Once a 'number' is detected, it is included in a buffer. Two special keys will control when the bib number must be sent or deleted from the buffer. Keys in the keypad and their functions are configurable in the sketch.

IR Receiver and IRLIB2

The transmitter in the remote control sends out a stream of pulses of infrared light (humans cannot see) when a button is pressed. A transmitter is often a light emitting diode (LED) which is built into the pointing end of the remote control handset. The infrared light pulses form a pattern unique to that button.

The Arduino sketch uses the IRLib2 library to perform all the management of the IR receiver. If you are interested in in-depth information about this, you can refer to this tutorial from Adafruit, explaining all details about IR and how to use commercial remotes within your sketch.

I used the SFH5110 IR receiver directly connected to the Arduino's digital pin #2. You have to take into account that several digital pins are used by the CC3000 WiFi shield.

The sketch enters in a loop waiting for the receiver to read a signal (number or control key).

The receiver will read a unique 32-bit hexadecimal data that represents the key pressed by the user. If the receiver finds something weird (e.g., several buttons pressed at the same time), returns the 0 value. The interesting thing is we can use any remote control, we can map the keys we need and run the script.

The sketch used:

High level explanation of the objectives of Activ-IoTy, a personal project being developed for the Open IoT Challenge.

Update of the ActivIoTy project for the Eclipse Open IoT Challenge.

Activ-IoTy is based on the pub-sub paradigm. This means that some components (publishers or senders) send messages to a central point, called broker, that delivers the messages to other components (subscribers or receivers) interested in receiving the information send by the publishers.

Just as a reminder of what the system does:

Checkpoints registers { competitor's ID + timestamp }. So, these are the publishers

Controller(s) collect the information sent by Checkpoints and process the information. So, this is one of the subscribers.

Other subscribers may perform other activities (i.e., visualizations, integration with third party services, etc.)

MQTT

> It's a good choice for systems where we need to share small code messages, and the network bandwidth may be limited

This mechanism is implemented using MQTT 3.1.1, an OASIS standard that is widely adopted by industries and IoT solutions. MQTT is a light-weight protocol suitable for Activity, due to the flexibility requirements regarding the conditions where Checkpoints operates. MQTT guarantees connections with remote locations. It's a good choice for systems where we need to share small code messages, and the network bandwidth may be limited. So, it's a perfect choice for ActivIoTy.

MQTT ensures the data is delivered properly to subscribers. The broker is in charge of delivers messages, according to three Quality of Service (QoS) levels:

QoS 0: At most once delivery. No response is sent by the receiver and no retry is performed by the sender. This means that the message arrives at the receiver either once or not at all.

QoS 1: At least once delivery. This quality of service ensures that the message arrives at the receiver at least once.

QoS 2: Exactly once delivery. This is the highest quality of service, for use when neither loss nor duplication of messages are acceptable.

Since ActivIoTy needs to satisfy completeness and integrity of data gathered by Checkpoints, the chosen QoS level is QoS 1 (At least once delivery). QoS 2 would be also adequate but it increases the overhead of communications. There may be duplicates, that will be filtered by receivers without too much cost associated.

Topics and Messages

Application messages within the MQTT queue are related to topics. So, both sender and receivers may work with messages organized by topics. Topics follow a hierarchical structure (e.g. bedroom to indicate all messages related to a bedroom; bedroom/temperature and bedroom/humidity for specific messages sent by sensors in the bedroom). This that is useful for subscribers to filter and receive only the information they need. Forward slash (‘/’ U+002F) is used to separate each level within a topic tree structure.

Checkpoints generate two kind of application messages:

1- Readiness messages (topic ready). They are sent once the Checkpoint is initialized and connected to the network. 2- Check-in messages (topic checkin). They are sent after the check-in of a competitor.

The definition of topics may be as complex as we want, In my case, the schema of topic names is based on the id of the checkpoint and the type of message. This is: {checkpointID}/ready and {checkpointID}/checkin.

Receivers may be subscribed to topics in a flexible way, using wildcards. For instance, +/ready to subscribe to all ready topics from all senders.

Messages will be encoded as UTF-8 in JSON format as follows:

Topic +/ready:

{ "checkpoint" : { // ID required "id" : "…", // Optional metadata "name" : "…", "description" : "…", "geo" : { "lat" : 0.000, "lng" : 0.000, "elevation" : 0.000 }, }, "timestamp" : 0000000 }

Readiness messages only require checkpoint identifier and timestamp (the Unix time of the device after synchronizing with a NTP server).

Topic +/checkpoint:

{ "checkpoint" : { "id" : "…", // Required "geo" : { "…" } // (Optional) It can be included in case the checkpoint is on the move }, "bib" : "…", // Either 'bib' or 'epc' are required "epc" : "…", "timestamp" : 0000000, // Required }

For check-in messages, it is required the checkpoint identifier (some information may be added, such as coordinates in case the checkpoint is on the move), the unique identifier of the competitor (we can have several, such as bib number and RFID tag), and the timestamp of the check-in.

Implementation with Mosquitto and Paho

Eclipse Mosquitto is an open source message broker that implements the MQTT protocol versions 3.1 and 3.1.1. This server is really stable and lightweight so it can be installed in any kind of computer, even on your Raspberry Pi.

Installation and configuration of the Mosquitto Broker is really easy (check official page for instructions). For this pilot, I installed the Mosquitto Broker on a UP² Squared I received for this challenge –thanks, it's great!

I installed it from the Mosquitto Debian Repository with apt just in a few steps:

After connecting via SSH with the UP² Squared.

wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key sudo apt-key add mosquitto-repo.gpg.key

Repository available to apt:

cd /etc/apt/sources.list.d/ sudo wget http://repo.mosquitto.org/debian/mosquitto-wheezy.list

Update apt information and install Mosquitto

apt-get update apt-get install mosquitto

As a summary of the configuration of this broker:

Configuration file: /etc/mosquitto/mosquitto.conf

Logs: /var/log/mosquitto/mosquitto.log

Mosquito service can be managed with this command:

sudo service mosquitto [start|stop|restart]

The listener by default will open the 1883 port. Through the configuration file, we can set up the server. There is a sample file with all options listed and documented at /usr/share/doc/mosquitto/examples/mosquitto.conf.

There, we can configure all the security specifications of our broker (user/password files, SSL/TLS support, bridges, etc.).

For this pilot we don't include security measures but communications should be private and secured in the production environment.

In case we want to test the broker, we can also install the pub-sub clients anywhere.

apt-get install mosquitto-clients

Opening several terminal sessions, we can simulate subscribers (mosquitto_sub) and publishers (mosquitto_pub) with just these options: * -h (hostname) * -t (topic) * -m (message)

Do not forget to open that port on your firewall to make it available from outside your network.

Paho

Checkpoints are implemented using Eclipse Paho. Paho provides open-source client implementations of MQTT protocols for any platform. Paho implementations may be deployed on all checkpoint modules of ActivIoTy: Raspberry + Python; UP2 Squared + Python/embedded C; Arduino + embedded C).

Update of the ActivIoTy project for the Eclipse Open IoT Challenge.

ActivIoTy is based on recognized standard protocols. Since the platform is designed to allow different and heterogeneous devices and implementations, standard technologies are crucial for scalability, enhancement of the system, and also to preserve integrity of data.

Likely the rest of IoT solutions, protocols and technologies may be represented in a logic way, structured in different layers, from the physical to the application layer. Although there are many other protocols involved in the communications of the devices and sub-systems, this is a simplified summary of the standards used in the project:

Obviously, everything will run on the Internet. There are various underlying protocols since ActivIoTy aims to be flexible in terms of physical connectivity. Controllers and Checkpoints may be installed in locations with strong WiFi signal (city or, town center), even with access to wired Ethernet routers, but also in the middle of the forest where we would need establish cellular GSM or 3G connections. Thus, the physical layer includes: IEEE 802.3 (Ethernet), IEEE 802.11 (WiFi) and WCDMA/HSDPA (3G) protocols.

On top of the Internet, the transport layer is composed mainly by TCP or Transmission Control Protocol. UDP or User Datagram Protocol is used for specific applications such as time synchronization through external NTP (Network Time Protocol) servers.

MQTT is King

Checkpoints, controllers and the rest of the modules of ActivIoTy are based on the Pub/Sub (Publication/Subscription) paradigm. Since the distributed system needs reliability and there is a potential lack of quality of communications, the solution uses MQTT (Message Queuing Telemetry Transport) as messaging protocol. MQTT allows Checkpoints (publishers) to send messages to the Controllers (subscribers). A broker, up and running in a reliable environment, will be in charge of delivering those messages effectively.

MQTT implements different levels of Quality of service (QoS). Since integrity of data and rapidity is key for ActivIoTy and intermediate Checkpoints may be weak in terms of connectivity, the system will implement QoS 1 (at least once). Using QoS level 1, it is guaranteed that a message will be delivered at least once to the receiver. Messages can be delivered more than once but this will be taken into account and solved by the Controller.

The Web Standards

In order to control, visualize, and provide services on top of ActivIoT, the platform will provide HTTP (Hypertext Transfer Protocol) RESTful services to access the information and platform services (e.g. control the system from external software, integration with social networks, etc.).

The final design may be complemented by other specific top level standards that will guarantee interoperability among similar systems around the world. The Thing Description mechanisms recommended by the W3C Web of Things Working Group help us to achieve this semantic interoperability.

Update of the ActivIoTy project for the Eclipse Open IoT Challenge.

Checkpoints and Controller

These are the main pieces of ActivIoTy. The Controller is a server that manages and controls the timekeeping system. It stores basic information about each race such as startDateTime (timestamp with the official starting time) and the configuration of the itinerary of the running course. The itinerary is a sequence of one or more Checkpoints where runners must go to and check-in in order to complete the race.

Thus, Checkpoints are virtual gates located along the course of the race where runners must go through. Checkpoints register the competitor's ID and a timestamp that marks the official check time at that point of the race. Checkpoints must indicate the Controller that are in operation and they will send all the information to the Controller.

The check process at Checkpoints may vary depending on the features of the device in use. For instance, some Checkpoints may read UHF RFID tags; others may be based on physical keyboards where marshals type the bib numbers when competitors go through the virtual gate.

In terms of arquitecture, both Controller and Checkpoint(s) are MQTT Clients. These clients will be implemented using the specific Eclipse Paho distribution, that provides solutions for all device platforms the project has.

MQTT Broker

Apart from these MQTT pubsub clients there is a MQTT Broker in charge of delivering messages. It is not repesented in the image to simplify the model.

Eclipse Mosquitto is the implementation selected for the MQTT Broker. This Open Source MQTT v3.1/v3.1.1 Broker will be installed on a reliable device with a strong internet connection.

Personae

Three main roles will operate ActivIoTy:

Admin: The person in charge of setting up the system (i.e., definition of checkpoints itinerary, assigning IDs to competitors, and others).

Official: The person that will control the race, acting as starter of the race (e.g., setting startDateTime).

Competitors: Runners/cyclists/… that take part in the competition. They are part of the checkpoint registration event.

NTP Timing Accuracy

Synchronization of both Checkpoints and Controller is the cornerstone of the platform. Because of this, one first initialization tasks of every device is to set the 'official' time and date. This is done by using NTP (Network Time Protocol) external servers (e.g., pool.ntp.org or time.google.com).

MQTT Reliability

Reliability is more important than efficiency in this project. Some checkpoints may have a poor internet connection and suffer interruptions, so ActivIoTy uses the MQTT protocol to guarantee the completeness of data. The system will implement QoS 1 (at least once). Using QoS level 1, it is guaranteed that a message will be delivered at least once to the receiver. Messages can be delivered more than once but this will be taken into account and solved by the Controller.

HTTP Server

There is a public HTTP server that publish information about the system and enable the full configuration of ActivIoTy. This is the main interface either for public users and administrators. This server may deploy subsequent services built on top of ActivIoTy (e.g., social network integration, direct publication to media agencies, etc.).

ActivIoTy at a Glance