Challenges

IoThon has a hackathon-wide main hacking grand prize and a few challenges with challenge-specific prizes.

The following were 2018 challenges. 

General hacking award

The overall goal of IoThon is to pursue forward the cross sections of IoT and blockchains as well as IoT and ICN, with the wish that we would find something interesting in the cross-section of all three: IoT, blockchains, and ICN. The baselines for the blockchains and IoT as well as ICN and IoT have already been established and will be partically covered by the tutorials.  However, the focal point of all three areas is something where — as far as we know — nobody has really gone to.

All works produced during the hackathon are eligible for the general main hacking prize: 1000€.

The tentative judging criteria for the general hacking are the following:

  • Overall coolness and awe.
  • Applying of IoT, blockchain, and/or ICN technologies in a novel and previously unseen way.
  • Quality of the code and other solution components produced during the hackathon.
  • Contributions to open source.

Best collaborator award

We want to foster open source and open collaboration! In the open source world, the value of the software increases the more it is used. We want this to happen also at IoThon.

The best collaborator prize will be awarded to the individual or team that has most helped others during the hackathon. While other prizes are awarded based on the jury judgement, for the best collaborator award we will arranged as a web poll, where the participants vote for the person or team that they think have been most helping others during the hackathon.

Home automation challenge

The Ell-i open source collaborative have developed a Node RED and CoAP based proof-of-concept system for controlling the heating (and cooling) of a residential building. The main focus of this work is in the still thousands of old apartments and houses in Finland that are heated partially with wood, partially with electricity. In these cases, it is possible to make large savings by following the electricity market prices, which are announced up to 24 hours beforehand, and to adjust the electrical heating to avoid the highest prices. To some extend, it is possible also to predict the price fluctiations and the amount of required heating based on weather forecasts and historical data.

The goal of this challenge is push forward with optimising electricity consumption in smart buildings that are (partially) heated or cooled with electricity. In the spirit of the IoThon, the solution should use, in addition to traditional IoT, also ICN, blockchains, or both.

Ruuvi Challenge

RuuviTag is an nRF52 based open-source sensor beacon platform, with built-in temperature, relative air humidity, air pressure and acceleration sensors. Ruuvi communicates with the external world with the nRF52 BlueTooth software radio, supporting a few different software solutions at Ruuvi Lab.  The goal of this challenge is to provide native IPv6 and/or ICN communications to the RuuviTag, e.g. using RIOT, the nRF52 IPv6 SDK, or something similar.

Kaspar Schleisser of RIOT-OS has created instructions on how to setup IPv6 over BLE on nRF52 development board: https://devzone.nordicsemi.com/blogs/981/setting-up-ipv6-over-ble-using-nrf52-series-and-ri/

Alternatively, nRF52 SDK 14.2 has some degree of IPv6 / CoAP support: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v14.2.0/iot_intro.html?cp=4_0_0_1_7

Ruuvi has drivers built on top of Nordic SDK for sensors onboard, though they might require porting to be used with RIOT.  Ruuvi firmware can be found at GitHub.  Ruuvi DevKit does not provide UART connection to RuuviTag, but the SWD connection is used.
Instructions on DevKit usage can be found at Ruuvi Lab. Contact @ojousima at the IoThon slack if you need assistance with the DevKit.

RAPstore Challenge

Develop IoT Apps, for eventual deployment on the RIOT App Store

Develop a RIOT-based firmware build which is organized as several independent, interacting applications. Your firmware should do the following three tasks, with three separate applications. It should automatically discover and adapt to the sensors of the current board; it should process the sensor values; and it should publish computed results using CoAP. Sensor interactions should be handled using SAUL.

Apps should be designed around the idea that they can be separately re-used in another context. So, the development of a novel inter-app interaction mechanism, an implementation agnostic API, or a flexible method of configuration of the final multi-app build would be a significant bonus.

ICN-IoT to Cloud Challenge

The RIOT operating system provides ICN support based on CCN-lite. Taking a central component of most IoT platforms - the cloud - into account, connecting an ICN to existing cloud platforms in the IP-based Internet serves as an interesting challenge.

As such, the goal of this challenge is to connect a sensor node via ICN and a gateway to the cloud platform EVRYTHNG. EVRYTHNG has the advantage that for testing purposes the access is free of charge and that it provides support for common IoT protocols such as CoAP and MQTT. Furthermore, it supports secure transport via DTLS.

Basel ICN challenges

  1. 1) Challenge: Build CRDT (conflict-free replicated data types) over IOTA.

    Goal is to add high-level Abstract Data Types to low level tangles. Python preferred.
    Profile: intersection of IOTA, cloud computing and Information Centric Networking

  2. 2) Challenge: give IoT devices access to Named Function Networking and serverless computing in Amazon Lambda

    Profile: Information Centric Networking, cloud computing

  3. 3) Challenge: Establishing trust through Escrowed Service Level Agreements in Named Function Networking (using Ethereum’s smart contracts)

    Profile: Named Function Networking and Ethereum